Re: x86_64-gnu port -- help needed

[Sergey Bugaev]

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