This is the mail archive of the
mailing list for the binutils project.
Re: PATCH: PR ld/14323: Linker fails to handle weak alias with __start_SECNAME symbol
On Sat, Jul 7, 2012 at 6:24 AM, Alan Modra <firstname.lastname@example.org> wrote:
> On Wed, Jul 04, 2012 at 06:46:59AM -0700, H.J. Lu wrote:
>> On Tue, Jul 3, 2012 at 5:46 PM, Alan Modra <email@example.com> wrote:
>> > On Mon, Jul 02, 2012 at 02:16:57PM -0700, H.J. Lu wrote:
>> >> When we check symbol alias in a dynamic object, we should also check
>> >> symbol size.
>> > Always? How does this play with cases where _bfd_elf_merge_symbol
>> > returns size_change_ok.
>> Here we are matching a symbol to a weak alias. Their
>> sizes must match.
> Two problems. The first one is that your testsuite addition doesn't
> fail for me on x64_64-linux without your elflink.c change. So the
> testcase isn't very useful. Binary search for a given key when
> multiple entries match the key gives you one of the matching entries
> but which one depends on exactly how the binary search went, ie. it
> depends on other entries in the array. So when I linked your testcase
> I happened to get foo_alias matching foo rather than the failure mode
> of foo_alias matching __start__data_foo.
That is true:
int x1 = 1;
int x2 = 2;
is added to pr14323-2.c to make it fail for me. I am using GCC 4.7
if it matters.
> Second problem is that I'm uncertain you can claim "sizes must
> match". If they do match, fine, go with the match. However if no
> size matches exactly, I think it would be better to match the largest
> size symbol at the given address. That way you at least get a match,
> and the largest .dynbss/copy reloc. Maybe I'm fussing a little here.
> Aliases generated by gcc with "__attribute__ ((weak, alias (...)))"
> require the target be defined in the same compilation unit, so they
> will be the same size. What about __attribute__ ((weakref (..)))?
I don't think it should make a difference since weakref alias isn't
in symbol table.
> I don't want to break some existing code that has only two symbols at
> one address, a weak and a global, but their sizes don't match. HJ,
> have you built glibc with your patch?
Yes, I used it to build GCC, glibc and Linux kernel. All work fine.