[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210318163640.5u6rucdk66aodun7@treble>
Date: Thu, 18 Mar 2021 11:36:40 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: x86@...nel.org, jgross@...e.com, mbenes@...e.cz,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/9] objtool: Rework rebuild_reloc logic
On Thu, Mar 18, 2021 at 01:57:03PM +0100, Peter Zijlstra wrote:
> On Wed, Mar 17, 2021 at 07:49:17PM -0500, Josh Poimboeuf wrote:
> > On Wed, Mar 17, 2021 at 09:12:15AM +0100, Peter Zijlstra wrote:
> > > On Tue, Mar 16, 2021 at 10:34:17PM -0500, Josh Poimboeuf wrote:
> > > > On Fri, Mar 12, 2021 at 06:16:18PM +0100, Peter Zijlstra wrote:
> > > > > --- a/tools/objtool/elf.c
> > > > > +++ b/tools/objtool/elf.c
> > > > > @@ -479,6 +479,8 @@ void elf_add_reloc(struct elf *elf, stru
> > > > >
> > > > > list_add_tail(&reloc->list, &sec->reloc_list);
> > > > > elf_hash_add(elf->reloc_hash, &reloc->hash, reloc_hash(reloc));
> > > > > +
> > > > > + sec->rereloc = true;
> > > > > }
> > > >
> > > > Can we just reuse sec->changed for this? Something like this on top
> > > > (untested of course):
> > >
> > > I think my worry was that we'd dirty too much and slow down the write,
> > > but I haven't done any actual performance measurements on this.
> >
> > Really? I thought my proposal was purely aesthetic, no functional
> > change, but my brain is toasty this week due to other distractions so
> > who knows.
>
> I was thinking you could get a section changed without touching
> relocations, but while that is theoretically possible, it is exceedingly
> unlikely (and objtool doesn't do that).
Hm? This is a *relocation* section, not a normal one. So by
definition, it only changes when its relocations change.
--
Josh
Powered by blists - more mailing lists