On Thu, Mar 9, 2023 at 8:26 PM Andreas Schwab <sch...@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
