This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] aarch64: Check PIC instead of SHARED in start.S
On 10/3/17, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> On 03/10/17 11:52, H.J. Lu wrote:
>> On 10/3/17, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>> On 02/10/17 12:20, H.J. Lu wrote:
>>>> On 10/2/17, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>>>>> On 29/09/17 22:32, H.J. Lu wrote:
>>>>>> Since start.o may be compiled as PIC, we should check PIC instead of
>>>>>> SHARED.
>>>>>>
>>>>>> OK for master?
>>>>>>
>>>>>
>>>>> i believe that the compile/link tests worked..
>>>>
>>>> Does static PIE of hjl/pie/static branch run on arm and aarch64?
>>>>
>>>
>>> no, if i build with --enable-static-pie the install step
>>> fails when the static linked sln runs.
>>>
>>> there are relative relocs against the func ptrs that are
>>> loaded from GOT in the startup code, but execution fails
>>> even before those are used because there are R*_JUMP_SLOT
>>> and R*_GLOB_DAT relocs which are not processed correctly.
>>>
>>> in particular in
>>> if (__pthread_initialize_minimal != NULL)
>>> __pthread_initialize_minimal ();
>>> the symbol value loaded from GOT is non-NULL even though
>>> there is no pthread linked in, that is probably a linker bug.
>>>
>>>>> ..but i still don't understand how the GOT entries
>>>>> of the startup code get initialized in PIE executable
>>>>> at runtime.
>>>>
>>>> You just avoid GOT entries in start.S for static PIE by using
>>>> PC relative relocations.
>>>>
>>>
>>> i don't see how can you do that when you have to pass
>>> absolute addresses as arguments to __libc_start_main
>>> and the base address is not yet computed.
>>
>> Does ARM support PC relative relocation for local function address?
>> All functions are local in static PIE. In i386/start.S, there are
>>
>> /* Load PIC register. */
>> call 1f
>> addl $_GLOBAL_OFFSET_TABLE_, %ebx
>>
>> /* Push address of our own entry points to .fini and .init. */
>> leal __libc_csu_fini@GOTOFF(%ebx), %eax
>> pushl %eax
>> leal __libc_csu_init@GOTOFF(%ebx), %eax
>> pushl %eax
>>
>> pushl %ecx /* Push second argument: argv. */
>> pushl %esi /* Push first argument: argc. */
>>
>> # ifdef SHARED
>> pushl main@GOT(%ebx)
>> # else
>> /* Avoid relocation in static PIE since _start is called before
>> it is relocated. */
>> leal main@GOTOFF(%ebx), %eax
>> pushl %eax
>> # endif
>>
>> GOTOFF can be resolved by linker to avoid dynamic relocations.
>>
>> [hjl@gnu-efi-2 gcc]$ cat x.c
>> extern void foo (void) __attribute__ ((visibility("hidden")));
>> extern void bar (void*);
>>
>> void
>> xxx (void)
>> {
>> bar (foo);
>> }
>> [hjl@gnu-efi-2 gcc]$ cat x.s
>> .arch armv8-a
>> .file "x.c"
>> .text
>> .align 2
>> .align 3
>> .global xxx
>> .type xxx, %function
>> xxx:
>> adrp x0, foo
>> add x0, x0, :lo12:foo
>> b bar
>> .size xxx, .-xxx
>> .hidden foo
>> .ident "GCC: (GNU) 8.0.0 20171002 (experimental)"
>> .section .note.GNU-stack,"",@progbits
>> [hjl@gnu-efi-2 gcc]$
>>
>> Does this need GOT?
>>
>
> ok, this works (for binaries < 4G), but i assumed the symbols
> can come from external module (in case of non-static linking)
> and thus crt1.o will need GOT entries anyway, but now i see
> that all of __libc_csu_init, __libc_csu_fini and main will
> be in the same module as crt1.o
>
> i can update start.S, but i wonder if there might be code
> where main is not in the executable for some reason, but
> comes from a shared lib.
>
That won't happen with static PIE :-).
--
H.J.