Re: x86_64-gnu port -- help needed

[Jessica Clarke <jrtc27@jrtc27.com>]

On 9 Mar 2023, at 19:44, Sergey Bugaev <bugaevc@gmail.com> wrote:
> 
> On Thu, Mar 9, 2023 at 8:26 PM Andreas Schwab <schwab@linux-m68k.org> wrote:
>> Similarily, something is pulling in strtoul.os because it references a
>> symbol from there not defined by ../sysdeps/mach/hurd/dl-sysdep.c.
>> 
>> elf/librtld.mapT should tell you where the references come from.
> 
> Thank you!!!
> 
> Apparently I'm misunderstanding how static linking works. I have
> always assumed that linking a static library works just like linking
> in all of its object files -- i.e. conceptually *all* object files are
> linked in, but the linker could optimize some away if they are not
> referenced by anything else. But what you're saying seems to indicate
> that object files are only pulled in by something referencing a symbol
> that they define, i.e. this is done lazily, not eagerly.

Object files listed explicitly on the command line are eagerly added.
Object files from libraries are lazily added. With --gc-sections some
parts of the resulting binary may also later be deleted, but that is
opt-in and limited in scope (and there are ways to override that).

Jess

> In my mental
> model, it is fully expected that you do get all the errors like
> duplicate symbols and undefined symbol references from the static
> library, even if you don't actually use much of it, because
> conceptually you're linking all of it in. That's why I was so
> surprised to see this work for i686-gnu.
> 
> That also explains why it's seemingly linking all of glibc into ld.so:
> it's only supposed to pull in some (hopefully very few) objects that
> it needs, and not all of it.
> 
> And by inspecting elf/librtld.mapT, I see that the reason it's pulling
> _exit.os in is that ld.so needs __libc_tls_initialized in a bunch of
> places, and that starts a chain of dependencies that ultimately leads
> to _exit.os. And that also explains that difference between i686-gnu
> and x86_64-gnu: i686-gnu just kind of looks at %gs to figure out if
> TLS has been initialized, but on x86_64 I had to add
> __libc_tls_initialized as an explicit flag.
> 
> I recall that ldsodefs.h/GL is the way to share some piece of data
> between ld.so and glibc proper? Should I put __libc_tls_initialized in
> there? How do I access GL() values from assembler, do I need to add it
> to some xxx-offsets.sym file? In fact, I see that there is already a
> sysdeps/x86_64/rtld-offsets.sym, that contains offsetof (struct
> rtld_global, _dl_tls_generation), so likely yes.
> 
> Alternatively, what if I made a separate weak declaration of
> __libc_tls_initialized in dl-sysdep.c, would that work & get
> automatically upgraded to the "real" one once glibc is loaded? Do I
> understand it correctly that the downside of this approach is that
> this will generate another GLIBC_PRIVATE symbol reference (or will
> it?), and that's not nice, whereas rtld_global is one symbol
> multiplexing many useful pieces of data?
> 
> Sergey
>