I installed FreeBSD-CURRENT on a FreeBSD Seagate Dockstar. When compiling lang/perl5.12 the generated miniperl dumps core with signal 11 and the following backtrace: #0 0x000fe86c in Perl_new_collate () #1 0x000ff2c8 in Perl_init_i18nl10n () #2 0x00126884 in perl_construct () #3 0x0010b930 in main () I guess that's the same issue as with 5.10 in http://lists.freebsd.org/pipermail/freebsd-arm/2010-February/002174.html Perl 5.8 builds fine on the same system. How-To-Repeat: Build lang/perl5.12 on arm
I have built miniperl that runs by removing "-DPIC -fPIC" from the c flags everywhere. After "make build" fails at miniperl core dump, I removed the *.o, and removed "-DPIC -fPIC" from make files, cflags, etc. Then, I restarted the build in the work/perl-5-12.4 directory with gmake. This builds miniperl that runs. miniperl crashes regardless of debug or optimized build. So, this is not a compiler optimization problem. From those two, the reason of miniperl core dump may be because the objects compiled with -fPIC is not compatible with static-linked miniperl, or miniperl thinking it's statically linked. I suspect that the register for PIC is not either properly set, or the it's using wrong register for PIC access. On Intel machine, the objects compiled with -fPIC links fine with miniperl. Someone with the knowledge of ARM linkage model should be able to at least diag the issue more precisely, or suggest appropriate compile/link options. Another possible work around is to build the perl as statically linked binary and not create libperl.so. -- Tai
After spending some more time on this, I can reasonably conclude that this is a compiler bug. First off, the build succeeds if "-fstack-protector" is not used. Here is the locale.s from locale.s of perl5-10.1, without stack protector. (Sorry I'm using perl5.10.1 for this example, but 5.10 and 5.12 crashes same way.) Perl_new_collate: @ args = 0, pretend = 0, frame = 104 @ frame_needed = 1, uses_anonymous_args = 0 mov ip, sp stmfd sp!, {r4, r5, r6, fp, ip, lr, pc} sub fp, ip, #4 sub sp, sp, #104 ldr r6, .L48 .LPIC2: add r6, pc, r6 subs r5, r0, #0 bne .L31 ldr r3, .L48+4 And the data segment .L48 is L48: .word _GLOBAL_OFFSET_TABLE_-(.LPIC2+8) .word PL_collation_name(GOT) Here is the assembler output of locale.c with the -fstack-protector. Perl_new_collate: @ args = 0, pretend = 0, frame = 104 @ frame_needed = 1, uses_anonymous_args = 0 mov ip, sp stmfd sp!, {r4, r5, r6, fp, ip, lr, pc} sub fp, ip, #4 sub sp, sp, #104 ldr r6, .L49 .LPIC2: add r6, pc, r6 ldr r3, .L49+4 And the data segment is .L49: .word _GLOBAL_OFFSET_TABLE_-(.LPIC2+8) .word __stack_chk_guard(GOT) .word PL_collation_name(GOT) Notice the last "ldr r3, .L49+4". It is loading r3 register from __stack_chk_guard(GOT) instead of PL_collation_name(GOT). So, I think that the arm backend has a bug that it is producing wrong offsets in the data segment when the stack protector is used. After noticing this, I took out the "-fstack-protector" from build and the build succeeds. It may be the problem that the combination of -fPIC and -fstack-protector is used. In any case, it is clear that the GCC's arm backend has a bug. cc --version cc (GCC) 4.2.1 20070719 [FreeBSD] Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Tai
This should be resolved by arm/161128. -- Tai
State Changed From-To: open->feedback Did the compiler fix committed in arm/161128 fix this problem?
Responsible Changed From-To: freebsd-arm->linimon
Hi, On Fri, May 18, 2012 at 12:07:41PM +0000, linimon@FreeBSD.org wrote: > Did the compiler fix committed in arm/161128 fix this problem? My ARM-hardware went out of order, so I can't test it. However, someone on freebsd-arm could maybe? Best Regards -- Michael Moll e-mail : kvedulv@kvedulv.de WWW : http://www.kvedulv.de/
On Fri, May 18, 2012 at 02:13:18PM +0200, Michael Moll wrote: > My ARM-hardware went out of order, so I can't test it. However, someone > on freebsd-arm could maybe? Responses to this PR gets automatically copied over to freebsd-arm, so let's see if there are any responses. mcl
On 2012-05-18 14:13:18 (+0200), Michael Moll <kvedulv@kvedulv.de> wrote: > On Fri, May 18, 2012 at 12:07:41PM +0000, linimon@FreeBSD.org wrote: > > Did the compiler fix committed in arm/161128 fix this problem? > > My ARM-hardware went out of order, so I can't test it. However, someone > on freebsd-arm could maybe? > lang/perl5.12 builds and runs on my OpenRD. Regards, Kristof
State Changed From-To: feedback->closed I was recently able to build perl on a SheevaPlug.