On 9 Mar 2023, at 19:44, Sergey Bugaev <buga...@gmail.com> wrote: > > 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.
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 >
