[fpc-devel] patch for rtl/linux/aarch64/cprt0.as

Sergei Gorelkin sergei_gorelkin at mail.ru
Tue Oct 6 01:59:07 CEST 2015



06.10.2015 1:08, Edmund Grimley Evans пишет:
> Clearly I don't really know what I'm doing with these start-up
> files... but I found I needed this patch to build the Debian package
> on arm64, so it's probably something for the AArch64 fixes branch.
>
> I tried running the test suite with and without this patch, and it
> appeared that webtbs/tw28089 went into an infinite loop without the
> patch and passed with it, but I've never seen that test fail before,
> and I don't see any connection with the patch, so I suspect there was
> some kind of random race and this patch does not really make any
> difference for the test suite.
>
> By the way, the failures on powerpc and ppc64 look rather as if they
> might be start-up-file-related:
>
> https://buildd.debian.org/status/package.php?p=fpc&suite=experimental
>
> Edmund
>
> --- a/rtl/linux/aarch64/cprt0.as
> +++ b/rtl/linux/aarch64/cprt0.as
> @@ -41,23 +41,23 @@ _start:
>   	                     init, fini, rtld_fini, stack_end) */
>   	adrp	x0,:got:PASCALMAIN
>   	ldr	x0,[x0,#:got_lo12:PASCALMAIN]
> -	adrp	x3,:got:__libc_csu_init
> -	ldr	x3,[x3,#:got_lo12:__libc_csu_init]
> -	adrp	x4,:got:__libc_csu_fini
> -	ldr	x4,[x4,#:got_lo12:__libc_csu_fini]
> +	adrp	x3,:got:_init_dummy
> +	ldr	x3,[x3,#:got_lo12:_init_dummy]
> +	adrp	x4,:got:_fini_dummy
> +	ldr	x4,[x4,#:got_lo12:_fini_dummy]
>   	bl	__libc_start_main
>
>   	/* This should never happen */
>   	b	abort
>
> -	.globl	_init
> -	.type	_init,#function
> -_init:
> +	.globl	_init_dummy
> +	.type	_init_dummy,#function
> +_init_dummy:
>   	ret
>
> -	.globl	_fini
> -	.type	_fini,#function
> -_fini:
> +	.globl	_fini_dummy
> +	.type	_fini_dummy,#function
> +_fini_dummy:
>   	ret
>
>   	.globl	_haltproc

This is absolutely wrong thing to do. Replacing __libc_csu_init with a dummy routine effectively 
defeats the entire libc/ELF startup. While doing so can make simple fpc-only programs linked with 
libc appear as working, any more complex programs will experience very obscure and hard to debug 
errors as soon as they touch the stuff that is normally initialized at startup.

The inability to find symbol "_init" during linking is typically caused by missing gcc (_init comes 
from crtbegin.o which belongs to gcc package, while another startup file crti.o belongs to libc 
package, or vice versa - I don't remember exactly), or by improperly installed fpc (it cannot find 
the crtbegin.o and other startup files).
I don't know exactly why FPC had chosen such dirty hack to hide this issue early in its history, but 
once it was used for one target, it became copy-pasted to many other targets as well. But stopping 
this practice is the good thing to do.

Regards,
Sergei



More information about the fpc-devel mailing list