I'm currently cross-compiling the MacOS RTL for PPC on a PC. I've fixed some trivial issues that had crept in since this was last maintained, some of which affect other targets, but am stuck at the errors below.

/usr/local/src/fpc/fpc-trunk/compiler/ppcXppc -Ur -Tmacos -Ppowerpc -XPpowerpc-macos- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../powerpc -FE. -FU/usr/local/src/fpc/fpc-trunk/rtl/units/powerpc-macos -dpowerpc -dRELEASE -Us -Sg system.pp
text.inc(1789,14) Warning: Implicit string type conversion from "AnsiString" to "UnicodeString"
text.inc(2013,44) Warning: Implicit string type conversion with potential data loss from "UnicodeString" to "AnsiString" system.pp(481,2) Warning: User defined: To be implemented - using GetProcessInformation???
system.pp(571) Fatal: Internal error 2003090901
Fatal: Compilation aborted
make[2]: *** [system.ppu] Error 1
make[2]: Leaving directory `/usr/local/src/fpc/fpc-trunk/rtl/macos'

Allowing that system.pp ends at line 570, I presume that something after line 481 is confusing the compiler. Any suggestions would be appreciated.

Not necessarily. It seems to be related to something "external".

You could try the following by adjusting the compiler source: before the internalerror (in compiler/powerpc/agppcmpw.pas) add a "writeln(tasmsymbol(p).typ)" and maybe also a "AsmFlush" so that the assembler file up to the error will be written so you can see in which function the problem exists.

You could also debug the compiler (copy the command line from the Makefile's output) when compiling the system unit and place a breakpoint on the internalerror and then investigate the "p" variable.

Regards,
Sven

On a second note: Is that assembler you are using a GNU assembler? If so then it might be better you use the "link on target" feature of FPC ("-st") as the GNU assembler is not supported for Mac OS...

Regards,
Sven

I was wondering how many of you know/use the
gppc386 trick?

The source code is located in compiler/utils

do a
make -C utils gppc386
this should compile a binary
called ./utils/gppc386

You should copy/rename it to,
for instance gppc1
cp ./utils/gppc386 ./gppc1

After this, you simply call make, as for instance here: make -C ../rtl clean all FPC=/full/path/to/complier/gppc1

gppc1 will start gdbpas (you can add a symbolic link to normal gdb) load ppc1 (same name with initial letter 'g' removed) and run ppc1 with the parameters given by make...

It should stop if something goes wrong
and not otherwise.

This is how I usually debug the compiler...

You need to be careful about a few things, like:
if you try to use this for a
make cycle
you need to change the starting compiler name to something that will not be deleted at start of "cycle", and then of course you also need to rename gppc1 accordingly.

In the hope that it can be useful!

Pierre Muller

I did not know that, but I personally prefer debugging using Lazarus :)

Regards,
Sven

Yes, and noted (should that be grafted into a makefile?). Presumably I'm not quite at that stage yet.

You can pass "CROSSOPT="-st"" to the call of make.

You are nearly at that stage though as the compiler has already parsed the unit, generated the assembler code tree and now is about to output the assembly file (system.s) and call the assembler. And while the step of outputing the assembler file is currently failing for you the last step which will immediately follow will then fail as well...

Reagrds,
Sven

system.pp(481,2) Warning: User defined: To be implemented - using GetProcessInformation???
AT_NONE
system.pp(571) Fatal: Internal error 2003090901
Fatal: Compilation aborted

./units/powerpc-macos/system.s is 28 bytes, containing only

string asis
aligning off

You could also debug the compiler (copy the command line from the Makefile's output) when compiling the system unit and place a breakpoint on the internalerror and then investigate the "p" variable.

I'm not very good with gdb (noting also Pierre's contribution, but it's probably somewhat ahead of my skills at the moment). How do I get the true name of the place I need to set the breakpoint?

Hmm... could you output "p.name" as well? maybe that will give us a lead... also two of the viable locations where such a tasmsymbol is created is in compiler/aasmdata.pas in TAsmData.RefAsmSymbol and TAsmData.WeakRefAsmSymbol. So you could writeln something (like what "s" is) in case the result is not assigned...

Couldn't you use Lazarus for that? Open the "ppcppc.lpi" project, adjust the command line arguments, compile and run... at least that's how I do my compiler development ;)

Regards,
Sven

If the last stage fails it won't be for quite that reason, because I've already updated my working notes in the wiki. It will be because I've not worked out how to use the MPW utilities, but the responsibility for getting that bit right is entirely with me.

..

"U_$SYSTEM_$$_SOFTFLOAT_EXCEPTION_MASK"

>> In TAsmData.RefAsmSymbol(), param is

"U_$SYSTEM_$$_SOFTFLOAT_EXCEPTION_FLAGS"

>> In TAsmData.RefAsmSymbol(), param is

"U_$SYSTEM_$$_SOFTFLOAT_ROUNDING_MODE"

AT_NONE
PBGetCatInfoSync
system.pp(571) Fatal: Internal error 2003090901
Fatal: Compilation aborted

OK, I've done a bit of that when I was starting to look at the MIPS compiler a year or so ago. I'll see how far I can get.

[Apropos MIPS: Pierre, any comment on my last mipseb run reported on 29th November?]

Mark Morgan Lloyd wrote

>>> Not necessarily. It seems to be related to something "external".

OK, I get that now that I'm looking at the functions etc.

>>> You could try the following by adjusting the compiler source: before >>> the internalerror (in compiler/powerpc/agppcmpw.pas)

Noting that this is the writer for the MPW-format assembler, rather than the GNU-format which is presumably tested more often.

Narrowing it down a bit with the help of Lazarus to WriteExternals calling WriteExternal:

>> In TAsmData.RefAsmSymbol(), param is "U_$SYSTEM_$$_READWRITESTRTEXT" >> In TAsmData.RefAsmSymbol(), param is "THREADVARLIST_$SYSTEM" >> In TPPCMPWAssembler.WriteExternals, count is 23832

ZZZ PBGetCatInfoSync TAsmSymbol 0

>> At index 1387

AT_NONE
PBGetCatInfoSync
system.pp(571) Fatal: Internal error 2003090901
Fatal: Compilation aborted
make[2]: *** [system.ppu] Error 1
make[2]: Leaving directory `/usr/local/src/fpc/fpc-trunk/rtl/macos'

Those >>> are debugging insertions: I'd better change that since they look like message quoting.

Bearing in mind that I don't entirely understand what I'm looking at, but I think it's significant that the index is neither right at the start nor right at the end.

So I suppose that the next thing to do is to (use Lazarus to) look at the conditions earlier in the compiler where AT_NONE is being inserted in the list.

[Apropos MIPS: Pierre, any comment on my last mipseb run reported on 29th November?]

Mark Morgan Lloyd wrote

So I suppose that the next thing to do is to (use Lazarus to) look at the conditions earlier in the compiler where AT_NONE is being inserted in the list.

It's putting a significant number of AT_NONE entries into the table, and the first one it tries to take out (which obviously isn't the first entry in the list) causes the internal error. When being put in, this entry had a call stack like

#0 TASMDATA__REFASMSYMBOL('PBGetCatInfoSync', <error reading variable>) at aasmdata.pas:443
#1 TCGPPC__A_CALL_NAME(0xb7ff2120, 'PBGetCatInfoSync', false, <error reading variable>) at ./powerpc/cgcpu.pas:183
#2 THLCG2LL__A_CALL_NAME(0xb7ff2120, 0xb7c76d00, 'PBGetCatInfoSync', 0x0, false, <error reading variable>, {DEF = 0xb7be0001, LOCATION = 0xb7f2fe20, INTSIZE = -5207293872358555647, DEFDEREF = {DATAIDX = -1073748636}, ALIGNMENT = -15, SIZE = OS_MS16, TEMPORARY = true (15), COMPOSITE = true (8), _vptr$ = {0x1, 0x1000003}}) at hlcg2ll.pas:461 #3 TCGCALLNODE__PASS_GENERATE_CODE(<error reading variable>) at ncgcal.pas:875
#4 SECONDPASS(0xb7f2f420) at pass_2.pas:197
#5 TCGASSIGNMENTNODE__PASS_GENERATE_CODE(<error reading variable>) at ncgld.pas:605
#6 SECONDPASS(0xb7c12580) at pass_2.pas:197
#7 TCGBLOCKNODE__PASS_GENERATE_CODE(<error reading variable>) at ncgbas.pas:380
#8 SECONDPASS(0xb7c158b0) at pass_2.pas:197
#9 TCGBLOCKNODE__PASS_GENERATE_CODE(<error reading variable>) at ncgbas.pas:380
#10 SECONDPASS(0xb7c155a0) at pass_2.pas:197
#11 DO_SECONDPASS(0xb7c155a0) at pass_2.pas:229
#12 TCGPROCINFO__GENERATE_CODE(<error reading variable>) at psub.pas:1297 #13 TCGPROCINFO__GENERATE_CODE_TREE(<error reading variable>) at psub.pas:1011
#14 READ_PROC_BODY(0xb7f2be00, 0xb7c2ccf0) at psub.pas:1848 #15 READ_PROC(false, 0x0) at psub.pas:1979
#16 READ_DECLARATIONS(false) at psub.pas:2103
#17 BLOCK(false) at psub.pas:273
#18 TCGPROCINFO__PARSE_BODY(<error reading variable>) at psub.pas:1676 #19 :944
#20 COMPILE('system.pp') at parser.pas:347
#21 COMPILE(0x0) at compiler.pas:255
#22 :239

I had also made out this location as the only plausible one for these AT_NONE entries. Maybe the external handling was changed since Mac OS last worked and the MPW writer wasn't adjusted then...

Regards,
Sven

11.12.2012 1:27, Sven Barth пишет:

Well, all ELF targets emit external symbols in object files with STT_NOTYPE type field, which corresponds to AT_NONE internal representation. COFF targets also accept this, although recent GCC/MinGW versions are marking external functions with proper type.

Sergei

I tried working through different backends to see if there was handling for AT_NONE in the ones that were working, but couldn't see anything obvious.