This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <> 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 <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]