I'm trying to get up to date on various platforms- i386 (NT and Linux), SPARC and now ARM (both Linux). I've installed 2.2.2 on Windows and built from source for i386 Linux without significant problems.

On SPARC I can build from scratch and tests complete. fpc appears to be OK, but fp bombs during initialisation leaving the screen in raw mode. If I redirect stdout to a file I get

An unhandled exception occurred at $FFA767E2 :
EBusError : Bus error or misaligned data access
$FFA767E2

I'm not very good with gdb etc.- how do I start to track this down?

I've had fp working in the past with 2.2.0, so I think this is a fairly new one. My apologies that I've not been more active testing.

Compile everything with

make OPT="-O- -g"

then open two terminal/console windows on the machine, in one of the type "tty" and note the output, and in the other one start "gdb fp", then

tty tty_of_other_console
run

and then when it crashes type
backtrace

post the output of the latter command here.

Jonas

It appears I can't get that far. If I

make clean
make GDB_V603=1 OPT="-O- -g" all

I fairly promptly get

..
/usr/local/bin/ppcsparc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../sparc -Fi../unix -Fisparc -FE.
-FU/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl/units/sparc-linux -O- -g -dsparc -dRELEASE -Sg ../objpas/typinfo.pp
/usr/local/bin/ppcsparc -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../sparc -Fi../unix -Fisparc -FE.
-FU/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl/units/sparc-linux -O- -g -dsparc -dRELEASE ../objpas/math.pp
Fatal: Compilation aborted
An unhandled exception occurred at $FF09163A :
EBusError : Bus error or misaligned data access
$FF09163A

make[8]: *** [math.ppu] Error 217
make[8]: Leaving directory
`/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl/linux' make[7]: *** [linux_all] Error 2
make[7]: Leaving directory `/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl' make[6]: *** [rtl] Error 2
make[6]: Leaving directory
`/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/compiler' make[5]: *** [next] Error 2
make[5]: Leaving directory
`/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/compiler' make[4]: *** [ppc1] Error 2
make[4]: Leaving directory
`/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/compiler' make[3]: *** [cycle] Error 2
make[3]: Leaving directory
`/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/compiler' make[2]: *** [compiler_cycle] Error 2
make[2]: Leaving directory `/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc' make[1]: *** [build-stamp.sparc-linux] Error 2
make[1]: Leaving directory `/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc' make: *** [fpcsrc/build-stamp.sparc-linux] Error 2

That's working with 2.2.2 already installed. Unless I hear otherwise I'll revert to 2.2.0 when I get time and see if I can compile 2.2.2 without error with the debugging options.

..

That's working with 2.2.2 already installed. Unless I hear otherwise I'll revert to 2.2.0 when I get time and see if I can compile 2.2.2 without error with the debugging options.

Starting off with 2.2.0 doesn't make any difference. If I do this

0 3> make "GDB_V603=1"
OPT="-O- -g" all

I get this

/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../sparc -Fi../unix -Fisparc -FE.
-FU/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl/units/sparc-linux -O- -g -dsparc -dRELEASE ../objpas/math.pp
Fatal: Compilation aborted
An unhandled exception occurred at $FF5673CA :
EBusError : Bus error or misaligned data access
$FF5673CA

make[8]: *** [math.ppu] Error 217
make[8]: Leaving directory
`/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl/linux' make[7]: *** [linux_all] Error 2

I can confirm that ppc1 has been recently built so should have -g etc. If I do this

# cd /usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl/linux # gdb /usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/compiler/ppc1 (gdb) set args -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../sparc -Fi../unix -Fisparc -FE.
-FU/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl/units/sparc-linux -O- -g -dsparc -dRELEASE ../objpas/math.pp
(gdb) tty /dev/pts/5
(gdb) run

where /dev/pts/5 is another Konsole session running bash as root, I get this:

Starting program: /usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/compiler/ppc1 -Ur -Ur -Xs -O2 -n -Fi../inc -Fi../sparc -Fi../unix -Fisparc -FE. -FU/usr/local/src/fpc/fpcbuild-2.2.2/fpcsrc/rtl/units/sparc-linux -O- -g -dsparc -dRELEASE ../objpas/math.pp

Program received signal SIGBUS, Bus error.
0x00011fc4 in FILLCHAR (X=void, COUNT=18, VALUE=546774876) at generic.inc:143
143 generic.inc: No such file or directory.
in generic.inc
(gdb) backtrace
#0 0x00011fc4 in FILLCHAR (X=void, COUNT=18, VALUE=546774876) at generic.inc:143
#1 0x00011e18 in FILLCHAR (X=void, COUNT=19, VALUE=32 ' ') at system.inc:178
#2 0x0001a7c8 in SPACE (B=318767107, result='
0,${'#2#2#2#2'},0'#0#0#0#0#0#0) at sstrings.inc:353 #3 0x0001b93c in STR_REAL (LEN=22, F=-1, D=nan(0xfffffffffffff), REAL_TYPE=RT_S64REAL, S='i1', highS=255)
at real2str.inc:456
#4 0x0001be90 in fpc_shortstr_float (D=nan(0xfffffffffffff), LEN=-32767, FR=-1, RT=1, S='i1', highS=255)
at sstrings.inc:403
#5 0x00215d58 in TDEBUGINFOSTABS__APPENDSYM_CONST (LIST=0xf7854df0, SYM=0xf7a55210, this=0xf7f944a0)
at dbgstabs.pas:1343
#6 0x0011bd78 in TDEBUGINFO__APPENDSYM (LIST=0xf7854df0, SYM=0xf7a55210, this=0xf7f944a0) at dbgbase.pas:358 #7 0x0011c39c in TDEBUGINFO__WRITE_SYMTABLE_SYMS (LIST=0xf7854df0, ST=0xf7f7c490, this=0xf7f944a0)
at dbgbase.pas:428
#8 0x00216318 in TDEBUGINFOSTABS__INSERTTYPEINFO (this=0xf7f944a0) at dbgstabs.pas:1415
#9 0x001977e8 in PROC_UNIT () at pmodules.pas:1129 #10 0x0016ebd0 in COMPILE (FILENAME='../objpas/math.pp') at parser.pas:373 #11 0x0004704c in COMPILE (CMD='') at compiler.pas:244 #12 0x000103cc in main () at pp.pas:207
(gdb)

Hope I got that right.

Yes, you did. Thanks. The bug is indeed in fillchar in generic.inc:

       { Align on native pointer size }
       aligncount:=(PtrUInt(pdest) and (sizeof(PtrUInt)-1));
       dec(count,aligncount);
       pend:=pdest+aligncount;

That make aligncount equal to the misalign count, rather than to the number of bytes necessary to align the pointer. It should rather be something like this:

       pend:=align(pdest,sizeof(ptruint));
       dec(count,pend-pdest);

I'll look at it tomorrow.

Jonas

I've committed a fix in 2.3.1. If all goes well in the testsuite run tonight, I'll merge it to 2.2.3 over the weekend. I don't know why this bug didn't cause crashes in the nightly tests I run on sparc/ solaris (I have gotten other alignment crashes on this machine in the past).

Jonas

Thanks Jonas, I'd missed the earlier comment which must have got lost by the spam filter. I'll keep an eye for 2.2.3 but if you want to kick me into life please note address below.

I really must find a way to put more time into this, but being able to produce a useful backtrace is a big step forwards- I'm more used to using a logic analyser for this sort of thing.

It's been merged to 2.2.3 now. You can either download the source zipfile from ftp://ftp.freepascal.org/pub/fpc/snapshot/v22/source/fpc.zip , or get it from svn as described here: http://www.freepascal.org/develop.var#svn (make sure you use the checkout url mentioned in the "Fixes to 2.2.x" section).

I really must find a way to put more time into this, but being able to produce a useful backtrace is a big step forwards- I'm more used to using a logic analyser for this sort of thing.

I don't think most users would appreciate it if that were the main way to debug program crashes :)

Jonas

fpc and fp appear to work on linux/sparc. However trying to single-step or run to a breakpoint in fp fails with another bus error or misaligned data access- do I stand any realistic chance of generating a useful backtrace for this?

I've had no success trying to drive fpc interactively across ttys to get to the point of failure. However while tinkering I found that failure depends on compilation options:

none Fails (fpc reports RTE 217)
"OPT=-g" Fails as above
"OPT=-O- -g" No failure
"OPT=-O-" No failure
"OPT=-O1 -g" Fails as above

Using the last of those and driving the debugger blind I get

Program received signal SIGBUS, Bus error.
0x002b0e08 in find_pc_sect_line (pc=65764, section=0x0, notcurrent=0) at symtab.c:2201
in symtab.c
Current language: auto; currently c
(gdb) backtrace
#0 0x002b0e08 in find_pc_sect_line (pc=65764, section=0x0, notcurrent=0) at symtab.c:2201
#1 0x002b10a8 in find_pc_line (pc=65764, notcurrent=0) at symtab.c:2214 #2 0x0005364c in ANNOTATE_STOPPED () at gdbint.pp:1501 #3 0x002c4114 in normal_stop () at infrun.c:3045
#4 0x002dee9c in find_default_create_inferior (exec_file=0xffffffff <Address 0xffffffff out of bounds>,
allargs=0x5a4400 "", env=0x1, from_tty=0) at target.c:1516 #5 0x002bdf74 in run_command (args=0x0, from_tty=0) at infcmd.c:481 #6 0x00347968 in do_cfunc (c=0x5bf268, args=0x5da668 "/home/markMLl/test", from_tty=0) at cli/cli-decode.c:57 #7 0x00349838 in cmd_func (cmd=0x5bf268, args=0x0, from_tty=0) at cli/cli-decode.c:1599
#8 0x00314914 in execute_command (p=0xff15277f "", from_tty=0) at top.c:733 #9 0x000540c4 in GDBINT_EXECUTE_COMMAND (COMMAND=0x0, FROM_TTY=1, MASK=0) at gdbint.pp:2161
#10 0x0031445c in do_catch_errors (uiout=0x5a6138, data=0xff1524f0) at top.c:524
#11 0x003142d8 in catcher (func=0x31444c <do_catch_errors>, func_uiout=0x5a6138, func_args=0xff1524f0,
func_val=0xff1524ec, func_caught=0xff1524e8, errstring=0x0, gdberrmsg=0x0, mask=-1) at top.c:431
#12 0x00314498 in catch_errors (func=0x540ac <GDBINT_EXECUTE_COMMAND>, func_args=0xff15277c, errstring=0x0, mask=-1)
at top.c:536
#13 0x0005440c in TGDBINTERFACE__GDB_COMMAND (S= [...] ) at gdbint.pp:2263 #14 0x001f5e94 in TGDBCONTROLLER__COMMAND (S= [...] ) at gdbcon.pp:163 #15 0x001f6178 in TGDBCONTROLLER__RUN () at gdbcon.pp:251 #16 0x000e10e4 in TDEBUGCONTROLLER__RUN () at fpdebug.pas:906 #17 0x001f6158 in TGDBCONTROLLER__STARTTRACE () at gdbcon.pp:246 #18 0x000acce8 in TIDEAPP__DOSTEPOVER () at fpmrun.inc:82 #19 0x000a8c40 in TIDEAPP__HANDLEEVENT (EVENT=
{WHAT = 2648947360, BUTTONS = 128 '\200', DOUBLE = 162, WHERE = {X = 310378512, Y = 16777216}, KEYCODE = 32930,
SCANCODE = 128 '\200', CHARCODE = 162 '<A2>', KEYSHIFT = 32 ' ', COMMAND = 2158108688, ID = 310378512, DATA = 7.2911 276715319871e-304, INFOPTR = 0x1300000b, INFOLONG = 318767115, INFOWORD = 4864, INFOINT = 4864, INFOBYTE = 19 '\023',
INFOCHAR = 19 '\023'}) at fpide.pas:1259
#20 0x0005983c in TGROUP__EXECUTE () at views.pas:2030 #21 0x00062238 in TPROGRAM__RUN () at app.pas:780
#22 0x0001402c in main () at fp.pas:451
(gdb)

If I'm interpreting that correctly then either the command blocks in #14 and #13 are wrong when the Pascal code is optimised (I have not recompiled the GDB interface library), or find_pc_sect_line is finding something it doesn't like. In case it's the former here are the full lines:

#13 0x0005440c in TGDBINTERFACE__GDB_COMMAND (S=
{length = 157 '\235', st = {227 '<E3>', 191 '<BF>', 160 '<A0>', 17 '\021', 0 '\0', 20 '\024', 58 ':', 208 '
<D0>', 2 '\002', 32 ' ', 144 '\220', 128 '\200', 162 '<A2>', 0 '\0', 0 '\0', 2 '\002', 128 '\200', 0 '\0', 32 ' ', 1
'\001', 0 '\0', 0 '\0', 0 '\0', 208 '<D0>', 6 '\006', 32 ' ', 200 '<C8>', 128 '\200', 162 '<A2>', 32 ' ', 1 '\001', 4 '\004', 128 '\200', 0 '\0', 28 '\034', 1 '\001', 0 '\0', 0 '\0', 0 '\0', 144 '\220', 16 '\020', 0 '\0', 24 '\030', 6
4 '@', 4 '\004', 84 'T', 72 'H', 1 '\001', 0 '\0', 0 '\0', 0 '\0', 127 '\177', 252 '<FC>', 216 '<D8>', 180 '<B4>', 1
'\001', 0 '\0', 0 '\0', 0 '\0', 128 '\200', 162 '<A2>', 32 ' ', 0 '\0', 4 '\004', 128 '\200', 0 '\0', 11 '\v', 1 '\00
1', 0 '\0', 0 '\0', 0 '\0', 17 '\021', 0 '\0', 20 '\024', 58 ':', 224 '<E0>', 2 '\002', 32 ' ', 144 '\220', 144 '\220
', 16 '\020', 0 '\0', 24 '\030', 64 '@', 4 '\004', 84 'T', 62 '>', 1 '\001', 0 '\0', 0 '\0', 0 '\0', 146 '\222', 16 '
\020', 0 '\0', 8 '\b', 144 '\220', 16 '\020', 0 '\0', 16 '\020', 127 '\177', 255 '<FF>', 162 '<A2>', 22 '\026', 1 '\0
01', 0 '\0', 0 '\0', 0 '\0', 17 '\021', 0 '\0', 20 '\024', 58 ':', 224 '<E0>', 2 '\002', 32 ' ', 144 '\220', 144 '\22
0', 16 '\020', 0 '\0', 24 '\030', 64 '@', 4 '\004', 84 'T', 49 '1', 1 '\001', 0 '\0', 0 '\0', 0 '\0', 146 '\222', 16
'\020', 0 '\0', 8 '\b', 144 '\220', 16 '\020', 0 '\0', 16 '\020', 127 '\177', 255 '<FF>', 162 '<A2>', 5 '\005', 1 '\0
01', 0 '\0', 0 '\0', 0 '\0', 17 '\021', 0 '\0', 20 '\024', 58 ':', 208 '<D0>', 2 '\002', 32 ' ', 144 '\220', 128 '\20
0', 162 '<A2>', 0 '\0', 0 '\0', 2 '\002', 128 '\200', 0 '\0', 7 '\a', 1 '\001', 0 '\0', 0 '\0', 0 '\0', 17 '\021', 0
'\0', 20 '\024', 58 ':', 208 '<D0>', 2 '\002', 32 ' ', 144 '\220', 146 '\222', 16 '\020', 0 '\0', 25 '\031', 127 '\17
7', 255 '<FF>', 162 '<A2>', 11 '\v', 1 '\001', 0 '\0', 0 '\0', 0 '\0', 129 '\201', 199 '<C7>', 224 '<E0>', 8 '\b', 12
9 '\201', 232 '<E8>', 0 '\0', 0 '\0', 157 '\235', 227 '<E3>', 191 '<BF>', 160 '<A0>', 17 '\021', 0 '\0', 20 '\024', 5 8 ':', 208 '<D0>'...}}) at gdbint.pp:2263
#14 0x001f5e94 in TGDBCONTROLLER__COMMAND (S=
{length = 3 '\003', st = {99 'c', 100 'd', 32 ' ', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 5 '\005', 102 'f', 105 'i'
, 108 'l', 101 'e', 32 ' ', 0 '\0', 0 '\0', 9 '\t', 115 's', 101 'e', 116 't', 32 ' ', 97 'a', 114 'r', 103 'g', 115
's', 32 ' ', 0 '\0', 0 '\0', 4 '\004', 107 'k', 105 'i', 108 'l', 108 'l', 0 '\0', 0 '\0', 0 '\0', 17 '\021', 116 't'
, 98 'b', 114 'r', 101 'e', 97 'a', 107 'k', 32 ' ', 80 'P', 65 'A', 83 'S', 67 'C', 65 'A', 76 'L', 77 'M', 65 'A',
73 'I', 78 'N', 0 '\0', 0 '\0', 3 '\003', 114 'r', 117 'u', 110 'n', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 4 '\004', 115 's
', 116 't', 101 'e', 112 'p', 0 '\0', 0 '\0', 0 '\0', 4 '\004', 110 'n', 101 'e', 120 'x', 116 't', 0 '\0', 0 '\0', 0
'\0', 5 '\005', 115 's', 116 't', 101 'e', 112 'p', 105 'i', 0 '\0', 0 '\0', 5 '\005', 110 'n', 101 'e', 120 'x', 11
6 't', 105 'i', 0 '\0', 0 '\0', 8 '\b', 99 'c', 111 'o', 110 'n', 116 't', 105 'i', 110 'n', 117 'u', 101 'e', 0 '\0'
, 0 '\0', 0 '\0', 4 '\004', 102 'f', 105 'i', 108 'l', 101 'e', 0 '\0', 0 '\0', 0 '\0', 2 '\002', 45 '-', 100 'd', 0
'\0', 1 '\001', 91 '[', 0 '\0', 0 '\0', 2 '\002', 93 ']', 32 ' ', 0 '\0', 1 '\001', 32 ' ', 0 '\0', 0 '\0', 0 '\0', 0
'\0', 0 '\0', 0 '\0', 15 '\017', 67 'C', 111 'o', 109 'm', 112 'p', 105 'i', 108 'l', 101 'e', 114 'r', 32 ' ', 101
'e', 120 'x', 105 'i', 116 't', 101 'e', 100 'd', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 4 '\004', 46 '.', 80 'P', 82 'R', 7
3 'I', 0 '\0' <repeats 15 times>, 64 '@', 245 '<F5>', 24 '\030', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 1 '\001', 46
'.', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 64 '@', 36 '$', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0', 0 '\0',
2 '\002', 44 ',', 32 ' ', 0 '\0', 1 '\001', 32 ' '...}}) at gdbcon.pp:163

Hope this makes sense.

Indeed, the tty redirection doesn't work very will in combination with raw terminal modes.

[snip]

I don't see what's wrong in the code at first sight. The command in frame 14 already seems wrong though, since frame 15 is gdbcon.pp:251, wich should pass 'run' rather than 'cd ' to gdb (the 'cd ' stuff comes from gdbcon.pp:195).

But I'm not an IDE developer in any way, I'm purely a compiler/rtl person. There are few IDE developers left though.

Jonas

Hi everyone
I recently got access to an IBM supercomputer (hundreds of PowerPC) running AIX. Naturally, the powerpc linux version of the compiler does not work. To begin with, AIX uses XCOFF binaries. So my question is: How hard is it to port the powerpc version of fpc to AIX or at least generate binaries that would run on AIX? Depending on the complexity of the issue I am willing to give it a try.

Thanks

Peter Popov

It should not be that hard. There are two main ABI's for PowerPC: the sysv and the aix ABI. Linux/*BSD use the sysv ABI, and Mac OS, Mac OS X and AIX uses the aix ABI. Hence, the aix abi is already supported in the compiler. A libc-based rtl port based on the solaris rtl shouldn't be that hard either.

Jonas

PS: please do not reply to existing messages when starting a new thread, as it messes up automatic threading in mail clients that support it

Could you give me some pointers how to begin?

Peter

I started a document here:

http://wiki.lazarus.freepascal.org/Porting_Free_Pascal

It's very incomplete, so fell free to extend as you discover how things work.

After experimentation I was able to do better without redirection but logging to file.

OK, but your recognition of something wrong in the gdb command blocks seems to suggest that fpc is mis-compiling the fp IDE when optimisation is enabled. I find that if I copy a non-optimised fp over an optimised one (i.e. with fpc and all ppus being optimised) then fp drives the debugger properly- at least as far as I've been able to test it.

I've run the test suite for the compiler with and without optimisation, so far I don't see any revealing differences in the output but I might be overlooking something significant due to inexperience.

The wiki page pointed to by Felipe describes the compiler changes fairly well. For the rtl: just copy the contents of rtl/solaris to rtl/ aix, and adapt the files (lookup constants and structure definitions in the C header files and adapt the corresponding Pascal definitions). Apart from rtl/solaris/termio*.*, I think you need everything to get a basic rtl working.

You can avoid having to use assembler for the entry point code by using the same trick that is used for Darwin. Have a look at rtl/bsd/ system.pp (search for FPC_DARWIN_JMP_MAIN, which is defined by current compilers -- just copy that entire {$ifdef darwin} block to your own system unit) and add your newly added system_powerpc64_aix identifier to the set of OSes that use this functionality in compiler/ncgutil.pas in the procedure gen_proc_symbol_end (in the if-test).

Jonas

Thanks Jonas.
I read Felipe's wiki thouroughly and i think I can manage that part. I also see I have to use the Darwin (powerpc) rtl, not the linux (powerpc) rtl. I will start experimenting with it on monday.

I have one question though, which is not clear to me, as I am not a low-level system guy:
To get the whole thing started I have two options:
1. Generate cross-compiler capable of producing AIX compatible binaries and start working on the rtl.
2. Generate a compiler for AIX and and start working on the rtl.

Option 1 seems the easier. I don't have mac powerpc machine, so I have to work from linux. Your suggestion is to start with the darwin compiler, right? As far as I looked, AIX uses XCOFF binaries. Can the mac powerpc compiler generate compatible binaries? Is the FPC_DARWIN_JMP_MAIN suggestion solution to this problem?

Option 2 seems complicated: I will have to first generate the compiler and rtl object files for AIX. Next, link the compiler on AIX using AIX's linker. Afterwards, work can begin on the rtl, which seems more complex?

Either way, I will have to first be able to generate aix compatible object files before starting the actual compiler branch. Unless you advise otherwise I will generate a linux-darwin cross and start experimenting with option 1.

Peter

Peter Popov wrote

I read Felipe's wiki thouroughly and i think I can manage that part. I also see I have to use the Darwin (powerpc) rtl, not the linux (powerpc) rtl. I will start experimenting with it on monday.

You can choose either the Darwin or the Solaris rtl, both are libc- based. However, the Solaris one is probably closer since Darwin is based on BSD while Solaris on sysv. AIX is also based on sysv (in spite of the fact that it uses a different ABI).

I don't understand what you mean by option 2. You always have to start with a cross compiler, since before you can have a native compiler you need a port of the rtl.

I don't have mac powerpc machine, so I have to work from linux.

That doesn't really matter.

Your suggestion is to start with the darwin compiler, right?

The compiler is mostly OS-agnostic. When cross-compiling, you can use pretty much anything as a host platform. See Marco's buildfaq for some more information about building the compiler and cross-compiling in general: http://www.stack.nl/~marcov/buildfaq.pdf

As far as I looked, AIX uses XCOFF binaries. Can the mac powerpc compiler generate compatible binaries?

The compiler generates assembler code. This assembler code has to be passed, in your case, to a cross-assembler which generates AIX XCOFF object files, and subsequently to a cross-linker to generate an XCOFF binary. The compiler couldn't care less what the object format is, it just generates assembler (except if you use an internal object writer, but that is optional and not required).

Usually, assemblers for new targets do some small things slightly different, and you'll probably have to compensate for that in your assembler writer. Most of it can probably be shared with the existing assembler writers though (compiler/aggas.pas, compiler/ppcgen/ agppcgas.pas).

Is the FPC_DARWIN_JMP_MAIN suggestion solution to this problem?

When the operating systems starts a program, there is usually some setup that needs to be done: running init routines, store the pointers to the parameters and environment variables in global variables, etc. This code usually resides in a file called crt1.o or similar and is distributed either with the OS or with the (C) compilers.

You can either create a patched Pascal (or assembler) version of such a file (as has been done for Solaris and Linux), or you can use the system version of this file and simply take over when it calls 'main' (normally to start the 'main' function of a C program). The latter is what is done if you use the FPC_DARWIN_JMP_MAIN functionality.

Option 2 seems complicated: I will have to first generate the compiler and rtl object files for AIX. Next, link the compiler on AIX using AIX's linker. Afterwards, work can begin on the rtl, which seems more complex?

You cannot generate a compiler and rtl object files for AIX before you have ported the rtl and the compiler to AIX.

Either way, I will have to first be able to generate aix compatible object files before starting the actual compiler branch. Unless you advise otherwise I will generate a linux-darwin cross and start experimenting with option 1.

A compiler is always built for a particular target architecture, and then it always supports generating code for all OSes on that architecture. So if you have an i386 machine, you have to build an i386->powerpc (or i386->powerpc64) cross compiler. This compiler will (if you don't change anything) support generating assembler code for all ppc(64) targets, including linux and darwin(regardless of whether it's built on Windows, on Linux or on anything else). When you add support for AIX to the compiler sources, it will also support generating assembler code for AIX/ppc(64).

See the buildfaq for more details.

ppc and ppc64 are two different targets (so a single compiler cannot generate both ppc and ppc64 code at this time), but they share a lot of code. You're free to choose which one you want to port (first), as I guess that AIX likes most ppc OSes seamlessly supports both 32 and 64 bit binaries.

Jonas

PS: while porting the compiler, you may want to grep the compiler sources for systems_darwin and system_powerpc64_darwin, to see whether the special cases for those targets also apply to AIX. Also note that the Darwin ABI slightly deviates from the standard AIX ABI regarding some alignments,

Mark Morgan Lloyd wrote

I've run the test suite for the compiler with and without optimisation, so far I don't see any revealing differences in the output but I might be overlooking something significant due to inexperience.

You can compare the generated output/sparc-solaris/faillist files to see whether there are differences in which tests fail (after running it in one configuration, copy the file to somewhere else so it won't get overwritten by the next testrun).

Jonas

Thanks for the detailed answer. I think the picture now is clear enough to start working

Peter

They are identical, same checksum. I'm redoing with a completely clean output directory just in case I've done something wrong but I don't think so- I should be able to confirm this evening since I will be away from my desk much of today.

I've redone and I might have something. First run had the compiler-build with default options, second had it with OPT=-O-, third also ran the tests with -O- in case that was significant. That resulted in three directories in tests/output:

sparc-linux-optimiser-on
sparc-linux-optimiser-off
sparc-linux-optimiser-off-during-tests

Running diff:

# diff ./sparc-linux-optimiser-on/faillist
./sparc-linux-optimiser-off/faillist
18,40d17
< webtbs/tw2242
< webtbs/tw2812
< webtbs/tw3082
< webtbs/tw3157
< webtbs/tw3930
< webtbs/tw3939
< webtbs/tw5800
< webtbs/tw6684
< webtbs/tw6822a
< webtbs/tw6822c
< webtbs/tw7838b
< webtbs/tw8180
< webtbs/tw8730c
< webtbs/tw8730d
< webtbs/tw9089b
< webtbs/tw9089c
< webtbs/tw9089d
< webtbs/tw9347a
< webtbs/tw9347b
< webtbf/tw3930a
< webtbf/tw8777a
< webtbf/tw8777b
< webtbf/tw8777c
# diff ./sparc-linux-optimiser-off/faillist
./sparc-linux-optimiser-off-during-tests/faillist
17a18,19

webtbs/tw2242 webtbs/tw2812

Hi All
I've been porting fpc 2.3.1 to a Blue Gene/P system (BG/P) and I hit a bizarre bug in cthreads which I have no clue about. Needless to say, it occurs only on the BG/P backend - this is the massivel parallel computing part. To make the story short: these are thousands of powerpc chips which run a "linux-like" stripped down kernel, no terminal in my case, debugging is very limited.

Basically I figured how to create the posix thread right. However when the thread function (ThreadMain) is about to return it calls pthread_exit(...). Now this results in a failed assertation in gcc, signal 6 and a coredump.

I was able to trace it to the unwinding of the gcc exception handler for the terminating thread. An obvious assertation fails (in unwind-dw2.c), which means that some basic startup data of gcc is either 1) messed up 2) not initialized.

So, I have two related questions:
1. Is the pthread_exit(...) call essential in ThreadMain?
2. This bug is either in the setup of some basic unit (system, initc, basicunix, unix), or something in gcc needs to be initialized. Am I missing anything?

What I've done so far is this (short story): I made a very simple example in which pthread_create is called directly with very simple thread function. It is along the lines of this
http://bugs.freepascal.org/view.php?id=14176 . This time however I removed all I/O and no obvious threadvars. It runs fine on a regular linux-powerpc and crashes on the BG/P computing nodes. I then compiled the function which call pthread_create(...) along with the thread functions with gcc and then linked against a pascal main function with fpc. The idea was to have fpc start the main function and then execute the same code with gcc. This one worked fine on BG/P. This makes me think initialization of GCC is OK, e.g. cprt0.as is fine.

Could anyone suggest a good debugging strategy? I am wondering if it is easy to generate a "bare bone" system unit which only makes the compiler happy, no functions, no threadvars, etc. That is, nothing, except orderly initialization of libc.

I will welcome any suggestions

Thanks
Peter Popov

Peter Popov wrote

I was able to trace it to the unwinding of the gcc exception handler for the terminating thread. An obvious assertation fails (in unwind- dw2.c), which means that some basic startup data of gcc is either 1) messed up 2) not initialized.

The problem is probably that FPC either does not generate DWARF CFI info for Linux/PowerPC, or that the DWARF CFI info it generates is wrong.

So, I have two related questions: 1. Is the pthread_exit(...) call essential in ThreadMain?

No. If you don't call pthread_exit, then the function resiult of ThreadMain will be reported as the thread exit value.

Jonas

PS: please do not create new mailing list threads by replying to older messages, because then the mailing list archive and several mail clients will group your message with that previous thread.

No. The only thing I've ever done regarding DWARF CFI is disable its generation in FPC for Darwin because it was broken there.

It is probably specific to the Kylix implementation (maybe they detach the thread later on otherwise). Simply not calling pthread_exit() does not automatically make a thread detached.

Note that by looking at the Kylix implementation in detail, you make it very hard for us to ever accept run time library patches from you for those part os the RTL, because you are tainting yourself this way (in the sense of copyright).

Jonas

Do you know where to look for these things? And how to check the implementation on that architecture, given the source of gcc and glibc? IBM have modified glibc and gcc. Fortunately, I was able to locate the diff patches so it might be simple.

I was looking at the implementation in kylix where there is comment that "calling pthread_exit() explicitly while the thread is still running prevents the thread from becoming detached before termination. The later might crash a TThread.WaitFor call in a different thread. It uses pthread_join which will fail if after detachment and before termination." I don't know if this is relevant to nptl threads, etc. On the other hand the posix manual says pthread is called implicitly after the thread function returns.

Peter

Thanks for the earlier remarks.

I work strictly with the fpc source. The thread function in cpthreads.pp does call pthread_exit in the end. So far two lines of the linux code which sett up the thread attributes have to be undef'd in order to create threads successfuly on BG/P. Exact thread attribute whish is an issue is not yet clarified.

Looking into kylix was a desparate effort to figure out if changing anything in the thread setup might shed light on the mess with pthread_exit. Once I located the assert failure (so far only postmortem debugging) things became clearer.
I might get a shot at doing a live debug in the comming days, which will clarify matters a lot.

By the way, there is commented line in cpthreads.pp which would have created the new thread in detached state. Should this be removed from the source alltogether, it creates confusion?

Peter

Apparently the problem was the initialization order of libc and libgcc. FPC links (linux-powerpc) in the following order:

cprt0.o
crtbegin.o
crti.o
.....
crtend.o
crtn.o

This was the root of the problem with pthread_exit. Instead, the correct order should be (according to the output of 'gcc -###'):

cprt0.o
crti.o
crtbegin.o
.....
crtend.o
crtn.o

Has anyone encountered issues related to the order of initalization of libc and libgcc before? I am planning to put the correct order in the BG/P cross compiler, however this may be a more general issue

Peter