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: [PATCH] aarch64: Check PIC instead of SHARED in start.S


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.


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