Hi,

I was looking into the latest fpc to see if there were updates about arm-embedded since my last version. Indeed there are ! So I downloaded it (svn 23505) and tried to compile it, following the wiki (http://wiki.freepascal.org/TARGET_Embedded). It crashes at 'ppcrossarm system.pp', message : segmentation-fault. Just that. I tried running the last line, and adding -vv. In the fpcdebug.txt I can't see much, but I don't know what I'm looking for. I could show that, but it's big, about 240k.

Any suggestions how to try to resolve this ? How do you keep debugging symbols in the compiler ?

gdb --args ../../compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur

-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FE. -FU/home/koenraad/Documenten/fpc-20130123/rtl/units/arm-embedded -darm -dRELEASE -Us -Sg system.pp
GNU gdb (GDB) SUSE (7.3-41.1.2)
...
Reading symbols from
/home/koenraad/Documenten/fpc-20130123/compiler/ppcrossarm...(no debugging symbols found)...done.
(gdb) run
Starting program:
/home/koenraad/Documenten/fpc-20130123/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur -Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FE.
-FU/home/koenraad/Documenten/fpc-20130123/rtl/units/arm-embedded -darm -dRELEASE -Us -Sg system.pp

Program received signal SIGSEGV, Segmentation fault. 0x0000000000416a66 in ?? ()
(gdb) bt
#0 0x0000000000416a66 in ?? ()
#1 0x0000000000000020 in ?? ()
#2 0x0000000000000020 in ?? ()
#3 0x00000000008dcb90 in ?? ()
#4 0x0000000000000009 in ?? ()
#5 0x00007ffff7b161c0 in ?? ()
#6 0x00007ffff7415c80 in ?? ()
#7 0x00007ffff7b161c0 in ?? ()
#8 0x0000000000416ca0 in ?? ()
#9 0x00007fffffffca40 in ?? ()
#10 0x00000000008dcb90 in ?? ()
#11 0x0018000100000115 in ?? ()
#12 0x0000000000415bc7 in ?? ()
#13 0x00000000008dcb90 in ?? ()
#14 0x000000000040ff5a in ?? ()
#15 0x00007ffff74521c0 in ?? ()
#16 0x0000000000000000 in ?? ()
(gdb)

Regards,

Koenraad Lelong

On Wed, January 23, 2013 14:38, Koenraad Lelong wrote:

Hi,

.
.

Normally, "OPT=-gl -Xs-" (possibly extended also with -O-) added to the make command does it.

Tomas

Tomas Hajny wrote

OPT=-gl -Xs-

Thanks, I comiled this way :

make clean buildbase installbase "OPT=-gl -Xs- -O-" CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7

That gives this :

gdb --args ../../compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur

-Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FE. -FU/home/koenraad/Documenten/fpc-20130123/rtl/units/arm-embedded -darm -dRELEASE -Us -Sg system.pp
...
Reading symbols from
/home/koenraad/Documenten/fpc-20130123/compiler/ppcrossarm...done. (gdb) run
Starting program:
/home/koenraad/Documenten/fpc-20130123/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur -Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FE.
-FU/home/koenraad/Documenten/fpc-20130123/rtl/units/arm-embedded -darm -dRELEASE -Us -Sg system.pp

Program received signal SIGSEGV, Segmentation fault. 0x0000000000419bb0 in SYSGETMEM_FIXED (CHUNKSIZE=32) at ../inc/heap.inc:977 977 pmc_next^.prev_fixed := nil;
(gdb) bt
#0 0x0000000000419bb0 in SYSGETMEM_FIXED (CHUNKSIZE=32) at ../inc/heap.inc:977
#1 0x0000000000419e38 in SYSGETMEM (SIZE=32) at ../inc/heap.inc:1072 #2 0x000000000041877d in GETMEM (P=0x7ffff74521c0, SIZE=24) at ../inc/heap.inc:276
#3 0x0000000000411f1c in NEWINSTANCE (self=0x900180) at ../inc/objpas.inc:355
warning: Range for type (null) has invalid bounds 0..-107 warning: Range for type (null) has invalid bounds 0..-2 warning: Range for type (null) has invalid bounds 1..-127 #4 0x000000000045f9da in CREATE (this=0x0, vmt=0x900180, INITSIZE=9) at cclasses.pas:2985
#5 0x00000000004daf33 in SET_LIVE_RANGE_DIRECTION (this=0x7ffff755d300, DIR=RAD_BACKWARDS) at rgobj.pas:723
#6 0x00000000004d3fa3 in SET_REGALLOC_LIVE_RANGE_DIRECTION (this=0x7ffff741a000, DIR=RAD_BACKWARDS) at cgobj.pas:775 #7 0x000000000056d830 in GENERATE_CODE (this=0x7ffff7b161c0) at psub.pas:1325
#8 0x000000000056cc95 in GENERATE_CODE_TREE (this=0x7ffff7b161c0) at psub.pas:1023
#9 0x000000000056ed82 in READ_PROC_BODY
(OLD_CURRENT_PROCINFO=0x7ffff7b16040, PD=0x7ffff7fcedb0) at psub.pas:1865 #10 0x000000000056f297 in READ_PROC (ISCLASSMETHOD=false, USEFWPD=0x0) at psub.pas:1996
#11 0x000000000056f79d in READ_DECLARATIONS (ISLIBRARY=false) at psub.pas:2120
#12 0x000000000056a6b5 in BLOCK (ISLIBRARY=false) at psub.pas:279 #13 0x000000000056e6c7 in PARSE_BODY (this=0x7ffff7b16040) at psub.pas:1693 #14 0x00000000005e477b in PROC_UNIT () at pmodules.pas:944 #15 0x00000000005c8cf9 in COMPILE (FILENAME=...) at parser.pas:347 #16 0x000000000042a3d8 in COMPILE (CMD=0x0) at compiler.pas:255 #17 0x000000000040041a in main () at pp.pas:239
(gdb)

Anyone can help ?

Regards,

Koenraad Lelong

Looks like a memory corruption problem. I just tried to compile trunk with 2.6.0 as a starting compiler on win32 and had no problems(apart from the broken RTL).

What starting compiler and what os/cpu are you on?

Hi,

What do you mean with memory corruption ? Is the memory of my PC broken, or is the compiler messing with the memory and then corrupts it ? As far as I see it's not possible to compile the RTL. That's my problem. The crosscompiler seems OK, when I run "ppcrossarm -i" I see the output I expect.
I'm trying to be as clear as possible, but sometimes I presume too much and the reader does not understand what I want to say :-( What I was trying to do is pinpointing where it goes wrong. So I manualy tried running the last line before the compilation (how to do that : see the wiki) stopped with the segmentation fault. And I did this with gdb to get a backtrace. That's what I sent to the list.

You say you can't compile the RTL, what error do you get ?

I'm compiling this with FPC 2.6.0, on Opensuse 12.1 64 bit.

Anyway, thanks for your reply.

Regards,

Koenraad Lelong.

What I mean is that I think the crash you experience means there's a bug in the compiler because your backtrace showed it crashed inside the heap manager. A typical sign after someone is using deallocated memory, or having buffer overflows.

I have fixed the issue with the RTL and submitted a patch: http://bugs.freepascal.org/view.php?id=23738
It was the same you wrote about some time ago.

I could reproduce the problem on Fedora 18 x86_64. The error shows up in revision 23457, the only file changed in this revision is compiler/arm/aoptcpu.pas.

Checkin comment for file was:

Revision *23457*
<http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revision&revision=23457>
- (view
<http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/arm/aoptcpu.pas?revision=23457&view=markup>) (annotate
<http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/arm/aoptcpu.pas?annotate=23457>)
- [select for diffs]
<http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/arm/aoptcpu.pas?r1=23457&view=log>

Modified /Sun Jan 20 14:57:43 2013 UTC/ (4 days, 6 hours ago) by /florian/ File length: 108993 byte(s)
Diff to previous 23456
<http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/arm/aoptcpu.pas?r1=23456&r2=23457>

* improve ShiftShiftShift2ShiftShift to look further ahead
* check register usage so the destination register can be differen

On a mac the problem does not exist, there i can build latest revision in svn without problems after applying Jeppe's patch for the IT problem (Thank you for that one, Jeppe!!)

So, Koenraad, perhaps you can do a svn update -r 23456 (or 23455) and retry the build, then you should hopefully have a very recent version of arm-embedded compiler+rtl.

The compiler segfaults when trying to compile rtl:

make -C embedded all
make[3]: Entering directory `/home/ring/devel/fpc/rtl/embedded' /usr/bin/mkdir -p /home/ring/devel/fpc/rtl/units/arm-embedded /home/ring/devel/fpc/compiler/ppcrossarm -Cparmv7m @rtl.cfg -Ur -Tembedded -Parm -XParm-embedded- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FE. -FU/home/ring/devel/fpc/rtl/units/arm-embedded -darm -dRELEASE -Us -Sg system.pp
make[3]: *** [system.ppu] Segmentation fault (core dumped) make[3]: Leaving directory `/home/ring/devel/fpc/rtl/embedded'

Michael

Hi Michael,

I downloaded svn version 23457, and now I can compile the crosscompiler. Unfortunately, I can't compile a project with that crosscompiler. More precisely, the project can't be linked. I have to redo some things to note what I am doing and what the results are, but the linking stage seems to go wrong.
I'll report more when I have my notes.

Regards,

Koenraad Lelong

Hi,

I made a virtual appliance with opensuse 12.2, x386. To be able to download it you must create an account on http://susestudio.com. Search for freepascal, then you'll find it : Freepascal for arm-embedded.

While making and testing it I discovered that the last revision (at this time 23542) does create a compiler, but when I try to compile the application from the wiki, I get a linking error :

fpc -Parm -Tembedded -Wplpc2124 -XParm-none-eabi- tled1.pp

Free Pascal Compiler version 2.7.1 [2013/01/30] for arm Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Embedded
Compiling tled1.pp
Assembling program
Linking tled1
/home/fpc/bin/arm-none-eabi-ld: error: no memory region specified for loadable section `.note.gnu.build-id'
tled1.pp(54,4) Error: Error while linking
tled1.pp(54,4) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Error: /usr/bin/ppcrossarm returned an error exitcode (normal if you did not specify a source file to be compiled)

This is the same error I reported about some days ago. Is it me, doing something wrong, or is there something wrong with the crosscompiler ?

Regards,

Koenraad Lelong.

Hi,

An update. I tried to make a crosscompiler with the new sources on my "old" developing machine. There I still get the segmentation fault. The difference is that that machine is 64 bit, while the appliance is 32 bit.

Actually, that was why I made the appliance. To see if there were differences.

Regards,

Koenraad

I did some digging and found the following post:

http://www.redhat.com/archives/rhl-devel-list/2007-October/msg01192.html

and

http://www.redhat.com/archives/rhl-devel-list/2007-October/msg01196.html

It's quite old so I am not sure if this still is of relevance but at this time Freepascal did not support the section . The workarround seems to be to add --build-id to linker command so that the section is automagically created.

I will try later tonight if I have the same issue as you.

Michael

I might have found a hack to solve your linking problem for arm-embedded on linux, unfortunately I am not an expert on gnu ld, but perhaps this here gives a hint to somebody that knows how to properly solve your problem:

First, create a script names arm-embedded-ld with the following content:

#!/bin/sh
sed --in-place "s^*(.comment)^*(.comment)\n *(.note, .note.*)^g" link.res /usr/local/bin/arm-embedded-ld $*

do a chmod 755 on the script so that you are able to execute it and now make sure that the script is found in your path before the original arm-embedded-ld binary so that fpc calls the small script instead of the real linker.

The problem seems to be that there is no definition for the note section in the link.res file. the small script adds this section, then the real linker gets called and all are happy (I hope)
You definitely need to test if after this hack you are still able to to debug your binary, I did not go that far.

I hope that helped,

Michael

If this is already needed (for me it worked always without), please provide a patch for fpc/compiler/systems/t_embed.pas The linker script generation for arm starts at line 222.

Sounds to me like a broken binutils. I have never heard about the .note section, except for some warnings now and then on obscure platforms

I did a grep through the fpc sourcecode and found a reference in ./compiler/systems/t_linux.pas in an arm related ifdef section

           add('  .note.gnu.build-id : { *(.note.gnu.build-id) }');

so perhaps this is really missing in arm-embedded target.

The patch for for fpc/compiler/systems/t_embed.pas seems to be pretty straightforward, I will create the patch and test if debugging still works.

Michael

by the way:

I used binutils-2.23.1 to create the cross-tools, configure script was:

./configure --target=arm-none-eabi --program-prefix=arm-embedded-

compiled under Fedora-18.

...

> Sounds to me like a broken binutils. I have never heard about the > .note section, except for some warnings now and then on obscure > platforms

Hi guys,

Thanks for taking the time to investigate this.
As far as I know binutils is the collection of programs to create executables, so the gcc-compiler, assembler, linker, etc. Another name is "toolchain", right ?
I recently searched for a toolchain, and I found one : gcc-arm-none-eabi-4_7-2012q4-20121208-linux.tar.bz2. I got this in the release.txt :
GNU Tools for ARM Embedded Processors 4.7
- Dec 2012
I think I tried it also with an older toolchain from Codewarriors (now Mentor). I'll have to verify this, though.
There's nothing to compile, just unpack and use it. I don't know what you are using as toolchain, did you have the same problem ?

Like I said before, I made a virtual machine that's set up to have a development environment for embedded-arm and fpc, including openocd. I made some scripts to do the compilation (to get a crosscompiler and the embedded-arm projects). The only thing I should do is make some document explaining how to use those scripts, although they're rather straighforward.
That could be used to investigate this case. The downside is it's size, about 900MB. It's on susestudio.com and on dropbox (https://www.dropbox.com/sh/dbsxi81jx2cb73n/h6ro62_XsD). I'm going to use this when this problem is solved, but anyone can use it. I'm going to try to maintain this, so all comments are welcome. Users/passwords : fpc/fpc and root/linux.

Thanks again,

Koenraad Lelong.

This is mainly needed for the loader. But I'll try with 2.23.1, just building ...

For a newly build mingw cross assembler/linker it is not needed. What build target does your assembler/linker have (...-ld --version)?

Hi Florian, I am not sure if this was completely clear to you, this problem only seems to exist on linux, my primary platform is mac, there this is not necessary, also not on windows.

After Koenraad expirienced this problem on 30.01.2013 I tried on my Fedora 18 linux system and found the same problem he described (He was using an opensuse system).

As you are talking about the mingw cross assembler/linker (isn't that mostly for windows? Might of course be that I am wrong on this one) I am not quite sure if you tried this on linux.

my build target was arm-none-eabi, using vanilla binutils 2.23.1 from ftp.gnu.org, built on fedora 18 x86_64

Michael

Michael Ring wrote

Hi Florian, I am not sure if this was completely clear to you, this problem only seems to exist on linux, my primary platform is mac, there this is not necessary, also not on windows.

Yes I know. But I wonder why linux would need this. This is not host dependent but should be target dependent.

Anyways, I added the needed code in r23626 to write a build-id section. Please tell me if it works.

Yes. But the target is the same: arm-eabi.

I used only arm-eabi, this shouldn't matter, indeed.

I did a quick check on Mac & Linux, on both platforms compiling & loading resulting .elf file into gdb works fine.

Thank you very much,

Michael

Hi,

I'm very confused. I must be doing something wrong, but I can't find out what.
I tried this on a "virgin" virtual machine based on Opensuse 12.2. I installed a binutils 2.23.1 for it. I did "as -v", and I get it's version : 2.23.1. Then I compiled fpc r23627 with fpc 2.6.0. Then I compiled the tled1.pp program with the new crosscompiler and I get the error :

/home/fpc/bin/arm-none-eabi-ld: error: no memory region specified for loadable section `.note.gnu.build-id'
tled1.pp(54,4) Error: Error while linking
tled1.pp(54,4) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted
Error: /usr/bin/ppcrossarm returned an error exitcode (normal if you did not specify a source file to be compiled)

I'll make the new virtual machine available on dropbox.

Regards,

Koenraad Lelong.

My guess is that you use an old version of ppcrossarm:

Looking at your error message ppcrossarm is located in: /usr/bin/ppcrossarm

which is a quite unusual place for it when you install it from trunk.

Michael

Hi Micheal,

I don't think it's that. I started from scratch, only an fpc 2.6.0. for x386 is installed. This is my script to make the cross-compiler :

#!/bin/bash -e
cd $1
#SUBTYPE=armv7m
SUBTYPE=armv4
make clean
make buildbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBTYPE BINUTILSPREFIX=arm-none-eabi- CROSSOPT="-CfSoft" PREFIX=/usr
sudo make installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=$SUBTYPE BINUTILSPREFIX=arm-none-eabi- CROSSOPT="-CfSoft" PREFIX=/usr
#make clean
echo $SUBTYPE
echo -------------------
echo 'As root, once do : make-link.sh'
echo -------------------

Like you can see : prefix is /usr. I also tried with the make-lines on one line, as root. This does not help.

This in make-link.sh :

#!/bin/bash -e
cd /usr/bin
ln -s ../lib/fpc/2.7.1/ppcrossarm ppcrossarm

To compile an embedded project I use this :

#!/bin/bash
PROCESSOR=lpc2124
fpc -Parm -Tembedded -Wp$PROCESSOR -XParm-none-eabi- $1

I'm putting a new version of my VM on dropbox.

Regards,

Koenraad Lelong

Hi,

When I install that script my test-program compiles and links (fpc r23627) with an own compiled binutils 2.23.1. Without it I still get the linker-error.
I tried to make a crosscompiler today with r23680, but that fails. Is it still necessary to use that arm-embedded-ld hack ?

Thanks,

Koenraad Lelong