[PATCH] Gold: Treat symbols with version index 0 as unversioned
Michael Matz
matz@suse.de
Tue Nov 18 13:46:26 GMT 2025
More information about the Binutils mailing list
Tue Nov 18 13:46:26 GMT 2025
- Previous message (by thread): [PATCH] Gold: Treat symbols with version index 0 as unversioned
- Next message (by thread): [COMMITTED, PATCH] shared.exp: Use pr14862.map to build libpr14862.so
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hello, On Tue, 18 Nov 2025, H.J. Lu wrote: > > they then can used for resolving. If they could, then there'd be an > > internal inconsistency in the above two items: symbols defined in an > > object (and that don't have a version otherwise), are to use index 1. So, > > for index 0 to be used the symbol in question must be (a) unversioned and > > (b) not be defined (in the sense of being available to resolve against) > > by the object (lest it had index 1). > > > > So, no, I don't think you should resolve against defined symbols with > > NDX_LOCAL. They have, as stated everywhere, local scope. > > > > The key point is that VER_NDX_LOCAL doesn't change symbol > binding which is determined by the st_other field Repeating this point doesn't make it more true. The specs from the beginning of their existence always said something else, so this: > as implemented > by ld and ld.so in glibc. ... is a bug, strictly speak. Now, I don't say we should change glibc. Nor do I think we should change ld.bfd in the way it deals with NDX_LOCAL undefined symbols. But I do think that ld.bfd should _not_ produce NDX_LOCAL defined symbols, for the time being. What you are proposing is a change in the spec (the linux one, not the Sun one), one I can go along with. But as any such change we can't just do that when we feel like it. Ciao, Michael.
- Previous message (by thread): [PATCH] Gold: Treat symbols with version index 0 as unversioned
- Next message (by thread): [COMMITTED, PATCH] shared.exp: Use pr14862.map to build libpr14862.so
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list