[fpc-devel] Revisiting MacOS for PPC (and possibly 68K)

Pierre Free Pascal pierre at freepascal.org
Mon Dec 10 16:56:03 CET 2012



> -----Message d'origine-----
> De : fpc-devel-bounces at lists.freepascal.org [mailto:fpc-devel-
> bounces at lists.freepascal.org] De la part de Sven Barth
> Envoyé : lundi 10 décembre 2012 16:37
> À : fpc-devel at 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





More information about the fpc-devel mailing list