Hi linted,
thanks for your review.
On Thu, Sep 1, 2022 at 11:12 PM linted <linte...@gmail.com> wrote:
> the original decision of placing it in reloc_static_pie.c was to ensure
> that when reloc_static_pie() accessed _dl_load_base it would do so
> without relying on relocations.
I don't see how placing the variable definition in the source code changes
that: the linker will move it to the .bss section anyway and the function will
have to have code to access it there. Also by the time _dl_load_base is
used all relative relocations are done, so that shouldn't be the issue at all?
> Do you mind letting me know which architecture you are building on?
I'm adding static pie support to a new architecture: xtensa. It has a couple
of quirks here and there, so there will be more follow-up patches. I just
thought that this issue is rather non-arch specific to deal with it separately.
> On one or two architectures I do make use of _DYNAMIC in _start()
> and I wonder if maybe that is leaking into static builds?
I'm looking at the linker-generated map of the failing build and see the
following lines in the list of archive members included to satisfy symbol
reference:
.../usr/lib/libc.a(reloc_static_pie.os)
.../usr/lib/libc.a(libc-tls.os) (_dl_load_base)
so clearly in my case it's the libc-tls.c reference to the _dl_load_base
that pulls reloc_static_pie.o in. Even if it didn't produce the build error
decoupling them is the right thing to do, because reloc_static_pie.o
has nothing to do in the PDE.
> Also it doesn't look like you are 0 initializing _dl_load_base in its new
> location.
I don't. With zero-initializer it goes into the .bss section, without it it
goes to the common section. Either way it will be zero-initialized by
the kernel ELF loader.
--
Thanks.
-- Max
_______________________________________________
devel mailing list -- devel@uclibc-ng.org
To unsubscribe send an email to devel-le...@uclibc-ng.org
