This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PING^N: [PATCH] Add --enable-static-pie to build static PIE [BZ #19574]


On Fri, Nov 24, 2017 at 5:06 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 23/11/17 13:59, H.J. Lu wrote:
>> On Mon, Nov 20, 2017 at 4:16 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>> On 19/11/17 02:40, H.J. Lu wrote:
>>>> 3. Linker should resolve undefined weak symbols to 0 in static PIE:
>>>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=22269
>>>>
>>>> 4. Many ELF backend linkers incorrectly check bfd_link_pic for TLS
>>>> relocations, which should check bfd_link_executable instead:
>>>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=22263
>>>>
>>>> Tested on i686 and x86-64.
>>>>
>>>> Build results of build-many-glibcs.py with --enable-static-pie with all
>>>> patches for static PIE applied are
>>>>
>>>> PASS: glibcs-aarch64_be-linux-gnu build
>>>> PASS: glibcs-aarch64-linux-gnu build
>>>
>>> i'd expect these to fail on current binutils master
>>>
>>> (linking with undefweak symbol fails now because of the issues
>>> listed above, i'll try to prepare a binutils patch)
>>>
>>
>> Do you think you can fix arm64 for glibc 2.27?
>>
>
> the aarch64 glibc tests pass with the pie patches and
> the start code fix i posted (and with a fixed bfd linker).

Great.  Linker changes look quite straight forward.  I will
update my commit message.

> the bfd linker cannot turn GOT load into pc relative address
> computation when the symbol is defined in the same module,
> so 3 variant of the start asm is needed (in principle the
> linker could do it if the pie code is smaller than 4G).
> this might affect other targets too.

I don't think the default glibc build supports large model
on x86-64 either.

> i find the dummy _dl_relocate_static_pie in crt1.o a bit
> ugly, such symbol is not reserved for extern linkage,
> but it is added to every static linked executable, and
> apart from the namespace issue it is new internal abi
> between libc and crt code, fortunately only the abi
> between Scrt1.o and libc.so needs to be fixed across
> libc versions and that is not affected, so this
> design is probably ok for now.
>

We can revisit it later when we find a better approach.


-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]