Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Jonas Maebe wrote on Thu, 08 Oct 2015: On 06/10/15 20:50, Edmund Grimley Evans wrote: (So if you've already applied the patch from Debian bug #800811 there will be a conflict.) Apart from the i386 part, this patch could perhaps go into fixes_3_0_ios as it clearly (I hope) only affects AArch64-Linux so can't break anything that used to work. Yes, I'll do that. I merged it in the fixes_3_0_ios branch last weekend. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
On 06/10/15 20:50, Edmund Grimley Evans wrote: But perhaps you'll want to consider fpc-x86_64-cprt0.patch (attached) for the trunk. I can confirm that it doesn't break Debian's build. Perhaps someone else can test it in some other way. I've run the testsuite and didn't see any regressions on RHEL 5.5 either. And here's an improved patch for AArch64: fpc-aarch64-cprt0.patch. AArch64 seems to need a corresponding version of the change that was needed for i386, so I've included both changes here. Thanks, all committed. (So if you've already applied the patch from Debian bug #800811 there will be a conflict.) Apart from the i386 part, this patch could perhaps go into fixes_3_0_ios as it clearly (I hope) only affects AArch64-Linux so can't break anything that used to work. Yes, I'll do that. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Op 06-10-15 om 08:47 schreef Jonas Maebe: As Sergei mentioned, this is definitely not the right approach. The difficulty with finding these files automatically is that they're often in non-standard locations. Normally, fpcmkcfg (utils/fpcmkcfg/fpcmkcfg.pp, executed to create /etc/fpc.cfg) will ask GCC for the path to these object files by extracting the path from the output of "gcc --print-libgcc-file-name". It will then prepend -Fl to that path and add the result to fpc.cfg There has been a patch to fix the extraction of the libgcc-path in trunk very recently. There was a problem with non-English versions of gcc. (using set language) Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Jonas:
> Anyway, you're right, the startup code for Linux/x86-64 does not
> pass the libc init/fini routines and hence is broken. And that's
> indeed not something to still change right before the release.
But perhaps you'll want to consider fpc-x86_64-cprt0.patch (attached)
for the trunk. I can confirm that it doesn't break Debian's build.
Perhaps someone else can test it in some other way.
And here's an improved patch for AArch64: fpc-aarch64-cprt0.patch.
AArch64 seems to need a corresponding version of the change that was
needed for i386, so I've included both changes here. (So if you've
already applied the patch from Debian bug #800811 there will be a
conflict.) Apart from the i386 part, this patch could perhaps go into
fixes_3_0_ios as it clearly (I hope) only affects AArch64-Linux so
can't break anything that used to work.
Edmund
--- a/rtl/linux/x86_64/cprt0.as
+++ b/rtl/linux/x86_64/cprt0.as
@@ -63,8 +63,8 @@
pushq %rsp
/* Pass address of our own entry points to .fini and .init. */
- movq _init_dummy@GOTPCREL(%rip), %rcx
- movq _fini_dummy@GOTPCREL(%rip), %r8
+ movq __libc_csu_init@GOTPCREL(%rip), %rcx
+ movq __libc_csu_fini@GOTPCREL(%rip), %r8
movq main_stub@GOTPCREL(%rip), %rdi
@@ -116,18 +116,6 @@
ret
.size _haltproc,.-_haltproc
- .globl _init_dummy
-.type _init_dummy, @function
-_init_dummy:
-ret
- .size _init_dummy,.-_init_dummy
-
- .globl _fini_dummy
-.type _fini_dummy, @function
-_fini_dummy:
-ret
- .size _fini_dummy,.-_fini_dummy
-
/* Define a symbol for the first piece of initialized data. */
.data
.globl __data_start
--- a/fpcsrc/compiler/systems/t_linux.pas
+++ b/fpcsrc/compiler/systems/t_linux.pas
@@ -149,6 +149,14 @@
if not Dontlinkstdlibpath Then
LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/x86_64-linux-gnu',true);
{$endif x86_64}
+{$ifdef i386}
+ if not Dontlinkstdlibpath Then
+LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/i386-linux-gnu',true);
+{$endif i386}
+{$ifdef aarch64}
+ if not Dontlinkstdlibpath Then
+LibrarySearchPath.AddPath(sysrootpath,'/usr/lib/aarch64-linux-gnu',true);
+{$endif aarch64}
end;
{$ifdef m68k}
--- a/fpcsrc/rtl/linux/aarch64/cprt0.as
+++ b/fpcsrc/rtl/linux/aarch64/cprt0.as
@@ -50,16 +50,6 @@
/* This should never happen */
b abort
- .globl _init
- .type _init,#function
-_init:
- ret
-
- .globl _fini
- .type _fini,#function
-_fini:
- ret
-
.globl _haltproc
.type _haltproc,#function
_haltproc:
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Edmund Grimley Evans wrote on Tue, 06 Oct 2015: 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. As Sergei mentioned, this is definitely not the right approach. The difficulty with finding these files automatically is that they're often in non-standard locations. Normally, fpcmkcfg (utils/fpcmkcfg/fpcmkcfg.pp, executed to create /etc/fpc.cfg) will ask GCC for the path to these object files by extracting the path from the output of "gcc --print-libgcc-file-name". It will then prepend -Fl to that path and add the result to fpc.cfg Now, for some reason, it seems that right now on Linux we only do this for x86 and PowerPC (32 and 64 bit). It seems there's an "else result := '-Fl'+GetDefaultLibGCCDir(CPU, OS, S);" missing for Linux. That would explain why you have those problems on AArch64, but not for PowerPC. Unless those machines don't have the libc-devel package installed, or no gcc when the system fpc was installed? (although that's hard to imagine) Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Jonas: > Now, for some reason, it seems that right now on Linux we only do this for > x86 and PowerPC (32 and 64 bit). So x86_64 does this the wrong way. So perhaps I should try to fix this on x86_64 (amd64) first because then there will be more people who can test any proposed patch. But it's a bit late for 3.0.0, isn't it? Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Edmund Grimley Evans wrote on Tue, 06 Oct 2015: Jonas: So x86_64 does this the wrong way. No, with "x86" I meant "i386 and x86_64". Sorry for not being clear. What you wrote was ambiguous, but I interpreted it as just 32-bit because my aarch64 patch, above, makes rtl/linux/aarch64/cprt0.as more similar to rtl/linux/x86_64/cprt0.as. Isn't the x86_64 file doing exactly what Sergei says is wrong? Oh, I thought you were referring to the problem regarding the inability to find the crt* files, possibly due to failing to locate their directory (although I've just realised that while building FPC itself, the code in packages/fpmkunit/src/fpmkunit.pp is called directly by fpmake since the global configuration file is ignored in that case, so that shouldn't matter). Anyway, you're right, the startup code for Linux/x86-64 does not pass the libc init/fini routines and hence is broken. And that's indeed not something to still change right before the release. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Edmund Grimley Evans wrote on Tue, 06 Oct 2015: Jonas: Now, for some reason, it seems that right now on Linux we only do this for x86 and PowerPC (32 and 64 bit). So x86_64 does this the wrong way. No, with "x86" I meant "i386 and x86_64". Sorry for not being clear. But it's a bit late for 3.0.0, isn't it? Due to Apple's Xcode 7 release breaking a bunch of things and some late found bugs in the resource string support, we will have an RC2 before the final release. In addition, problems related to the generation of the configuration file are generally only discovered while building a release, so fixed for that are definitely good candidates to still include. I think the current plan is to tag RC2 tomorrow night, so if possible it would be good to have your proposed changes before then. Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
Jonas: >> So x86_64 does this the wrong way. > No, with "x86" I meant "i386 and x86_64". Sorry for not being clear. What you wrote was ambiguous, but I interpreted it as just 32-bit because my aarch64 patch, above, makes rtl/linux/aarch64/cprt0.as more similar to rtl/linux/x86_64/cprt0.as. Isn't the x86_64 file doing exactly what Sergei says is wrong? Edmund ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] patch for rtl/linux/aarch64/cprt0.as
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=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) */ adrpx0,:got:PASCALMAIN ldr x0,[x0,#:got_lo12:PASCALMAIN] - adrpx3,:got:__libc_csu_init - ldr x3,[x3,#:got_lo12:__libc_csu_init] - adrpx4,:got:__libc_csu_fini - ldr x4,[x4,#:got_lo12:__libc_csu_fini] + adrpx3,:got:_init_dummy + ldr x3,[x3,#:got_lo12:_init_dummy] + adrpx4,: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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] patch for rtl/linux/aarch64/cprt0.as
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=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) */ adrpx0,:got:PASCALMAIN ldr x0,[x0,#:got_lo12:PASCALMAIN] - adrpx3,:got:__libc_csu_init - ldr x3,[x3,#:got_lo12:__libc_csu_init] - adrpx4,:got:__libc_csu_fini - ldr x4,[x4,#:got_lo12:__libc_csu_fini] + adrpx3,:got:_init_dummy + ldr x3,[x3,#:got_lo12:_init_dummy] + adrpx4,: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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
