Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Sergei Gorelkin wrote:
11.12.2012 1:27, Sven Barth пишет:
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
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...
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.
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.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
-Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Sven Barth Envoyé : lundi 10 décembre 2012 16:37 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K) Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Sven Barth wrote: Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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. 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... Yes, and noted (should that be grafted into a makefile?). Presumably I'm not quite at that stage yet. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Am 10.12.2012 16:56, schrieb Pierre Free Pascal: -Message d'origine- De : fpc-devel-boun...@lists.freepascal.org [mailto:fpc-devel- boun...@lists.freepascal.org] De la part de Sven Barth Envoyé : lundi 10 décembre 2012 16:37 À : fpc-devel@lists.freepascal.org Objet : Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K) Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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. I was wondering how many of you know/use the gppc386 trick? I did not know that, but I personally prefer debugging using Lazarus :) Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Am 10.12.2012 17:05, schrieb Mark Morgan Lloyd: Sven Barth wrote: Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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. 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... 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Sven Barth wrote: Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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. 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? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Am 10.12.2012 17:24, schrieb Mark Morgan Lloyd: Sven Barth wrote: Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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. system.pp(481,2) Warning: User defined: To be implemented - using GetProcessInformation??? AT_NONE system.pp(571) Fatal: Internal error 2003090901 Fatal: Compilation aborted 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... ./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? 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Sven Barth wrote: 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... 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. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
Sven Barth wrote: Am 10.12.2012 17:24, schrieb Mark Morgan Lloyd: Sven Barth wrote: Am 10.12.2012 12:15, schrieb Mark Morgan Lloyd: 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. system.pp(481,2) Warning: User defined: To be implemented - using GetProcessInformation??? AT_NONE system.pp(571) Fatal: Internal error 2003090901 Fatal: Compilation aborted 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... .. In TAsmData.RefAsmSymbol(), param is RTTI_$SYSTEM_$$_DEF1351 In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_THREADID In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_ERROUTPUT In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_OUTPUT In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_INPUT In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_STDOUT In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_STDERR In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_INOUTRES In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_STACKTOP In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_STACKBOTTOM In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_STACKLENGTH In TAsmData.RefAsmSymbol(), param is 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 In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_EXCEPTADDRSTACK In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_EXCEPTOBJECTSTACK In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_EXCEPTTRYLEVEL In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_FREELISTS In TAsmData.RefAsmSymbol(), param is U_$SYSTEM_$$_READWRITESTRTEXT In TAsmData.RefAsmSymbol(), param is THREADVARLIST_$SYSTEM AT_NONE PBGetCatInfoSync 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? 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 ;) 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 markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
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. 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 ;) 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. 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 markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
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, 0x103}}) 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 PROC_UNIT at pmodules.pas:944
#20 COMPILE('system.pp') at parser.pas:347
#21 COMPILE(0x0) at compiler.pas:255
#22 main at pp.pas:239
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
On 10.12.2012 21:06, Mark Morgan Lloyd wrote:
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
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Revisiting MacOS for PPC (and possibly 68K)
11.12.2012 1:27, Sven Barth пишет:
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
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...
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
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
