Re: The trouble with __weak and objtool got worse

["H.J. Lu" <hjl.tools@gmail.com>]

On Sat, Apr 16, 2022 at 4:25 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Fri, Apr 15, 2022 at 02:04:32PM -0700, H.J. Lu wrote:
> > On Fri, Apr 15, 2022 at 4:19 AM Peter Zijlstra <peterz@infradead.org> wrote:
>
> > > *HOWEVER*, sometimes it generates things like this (using new enough
> > > binutils):
> > >
> > > foo-weak.o:
> > >
> > > Relocation section '.rela.static_call_sites' at offset 0x2c8 contains 1 entry:
> > >     Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
> > > 0000000000000000  0000000200000002 R_X86_64_PC32          0000000000000000 foo + 0
> > > 0000000000000004  0000000d00000002 R_X86_64_PC32          0000000000000000 __SCT__foo + 1
> > >
> > > foo.o:
> > >
> > > Relocation section '.rela.static_call_sites' at offset 0x310 contains 2 entries:
> > >     Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
> > > 0000000000000000  0000000200000002 R_X86_64_PC32          0000000000000000 foo + d
> > > 0000000000000004  0000000d00000002 R_X86_64_PC32          0000000000000000 __SCT__foo + 1
> > >
> > > foos.o:
> > >
> > > Relocation section '.rela.static_call_sites' at offset 0x430 contains 4 entries:
> > >     Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
> > > 0000000000000000  0000000100000002 R_X86_64_PC32          0000000000000000 foo + 0
> > > 0000000000000004  0000000d00000002 R_X86_64_PC32          0000000000000000 __SCT__foo + 1
> > > 0000000000000008  0000000100000002 R_X86_64_PC32          0000000000000000 foo + d
> > > 000000000000000c  0000000d00000002 R_X86_64_PC32          0000000000000000 __SCT__foo + 1
> > >
> > > And now we can see how that foos.o .static_call_sites goes side-ways, we
> > > now have _two_ patch sites in foo. One for the weak symbol at foo+0
> > > (which is no longer a static_call site!) and one at foo+d which is in
> > > fact the right location.
> >
> > This can't be right.  "foo" must point to the non-weak function.
> > Please file a linker bug report.
>
> It does point to the non-weak symbol; they both do, even the relocs that
> started out as pointing to the weak symbol.

The relocation is against the symbol, foo, and linker will decide where
foo is defined.   We only know what the final foo definition is at link-time.
You can't tell the final foo definition is weak or non-weak before link-time.

> Are you saying the linker *should* have removed the relocs that were
> based on the weak symbol?

No, relocations aren't removed.  Linker ignores the weak definition of
foo if there is a non-weak definition of foo when resolving relocations
against symbol foo.

-- 
H.J.