[PATCH v2] elf: Treat undefined version as hidden

[H.J. Lu]

On Tue, Aug 3, 2021 at 7:57 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Mon, Aug 02, 2021 at 04:38:48PM -0700, H.J. Lu wrote:
> > The versioned symbol from copy relocation in the executable can change
> > over time.  Today, foo@VER is used to resolve the unversioned reference
> > in another shared library.  When foo@VER becomes hidden in the shared
> > library tomorrow,  the executable runs normally.  But foo@VER in the
> > executable will no longer be used to resolve the unversioned reference.
>
> OK, that's true, but there are some weird cases handled by glibc's
> ld.so.  For example, a reference to foo@VER can be satisfied by an
> unversioned foo definition in some cases.  You can see this by
> building a shared library with script "VER { global: foo; };",
> linking an executable against that library, then building a new
> version of that library with script "VER { };".  The new library foo
> satisfies foo@VER in the executable.

I think it may be done on purpose.

> (The reverse case is true too.  An unversioned reference to foo can be
> satisfied by a foo@VER hidden definition, if there is only one
> versioned definition of foo!)

This is done on purpose.

> > It is all because foo@VER in the executable is actually undefined.  I
> > prefer readelf's behavior.
>
> "actually undefined" is complicated.  Yes, if a definition for foo@VER
> (or the weird unversioned foo case I mention) is not found, then the
> dynamic linker will complain (I think, when resolving the copy reloc).
> But once that copy reloc has done its dirty work, then as far as the
> program is concerned we really do have a definition in the executable
> that overrides other definitions according to normal ELF rules.  I
> know you know this.  I'm just trying to make it clear to anyone else
> who might be reading this thread.
>
> As far as readelf/nm are concerned you have convinced me that readelf
> is more correct, so the patch to make nm agree with readelf is OK.

I will check it in.   Thanks.

> What are we to do about the gdb failure though?  I'd say it is clear
> that what gdb was doing was incorrect, but on the other hand it likely
> worked in 99% of cases.

Agreed.  Gdb should be fixed.

-- 
H.J.