[fpc-devel] Re: FPC unit symbol checksum woes

[Adriaan van Os]

Peter Vreman wrote:

> These kind of recompile failures are a known issue. Years ago it is already identifed and an idea
> how to rewrite the unit handling. But it is a huge project and time is very limited.
> 
> You can try to compile the compile with -dINTFPPU this will generate a .ppu.intf after the
> interface seciton has been parsed. Diffing the ppudump between the .ppu and .ppu.intf will give a
> better indication what is changed in the ppu between the interface parsing and implementation
> parsing.

Thanks for the hint. I managed to rebuild the compiler with -dINTFPPU and this does produce 
.ppu.intf files when compiling with it. The diff between the ppudump of the the .ppu files and the 
.ppu.intf files does show checksum and other differences. Not sure which ones to look at.

For example:

@@ -1,20 +1,21 @@
-Analyzing Objects/DrumStyles.ppu.intf (v91)
+Analyzing Objects/DrumStyles.ppu (v91)

  Header
  -------
  Compiler version        : 2.3.1
  Target processor        : i386
  Target operating system : Darwin-i386
-Unit flags              : little_endian
-FileSize (w/o header)   : 31358
-Checksum                : F4F82F2E
-Interface Checksum      : 7FE18E88
-Definitions stored      : 0
-Symbols stored          : 0
+Unit flags              : static_linked, little_endian, local_threadvars, local_symtable
+FileSize (w/o header)   : 81958
+Checksum                : BFD83432
+Interface Checksum      : 86AA546F
+Definitions stored      : 1096
+Symbols stored          : 1428

  Interface section
  ------------------
  Module Name: DrumStyles
+Source file 1 : DrumStyles.pas 2008/08/29 23:22:46
  Uses unit: System (Crc: 286B12B3, IntfcCrc: E9DCB7B9)
  Uses unit: MacPas (Crc: F374769E, IntfcCrc: 72C6383A)
  Uses unit: MacOSAll (Crc: A4E5FD79, IntfcCrc: A2FF6F65)
@@ -64,11 +65,16 @@
  Uses unit: Hints (Crc: DB360E5E, IntfcCrc: 55A8384F)
  Uses unit: MBFiles (Crc: AC9F8454, IntfcCrc: 72616F2F)
  Uses unit: Classes (Crc: 42E7F73E, IntfcCrc: E050CFF2)
-DerefMapsize: 3
+Link unit object file: DrumStyles.o (static )
+!! Skipping unsupported PPU Entry in General Part: 100
+!! Skipping unsupported PPU Entry in General Part: 82
+DerefMapsize: 5
  DerefMap[0] = SYSTEM
  DerefMap[1] = MACOSALL
  DerefMap[2] = CLASSES
-Derefdata length: 4785
+DerefMap[3] = MGLOBALS
+DerefMap[4] = SYSUTILS
+Derefdata length: 28828

  Interface definitions
  ----------------------
@@ -86,9 +92,10 @@
              Level : 2
              Class : (24) Nil
            Procsym : (26) SymId 57
-         File Pos : 1 (94,10)
+         File Pos : 1 (3411,10)
         SymOptions : Public
          Import Nr : 0
+       Alias names : _DRUMSTYLES_READDRUMSTYLE$SHORTSTRING$$BOOLEAN
      ------ parast ------
      ------ parast ------
      Symtable datasize : 1
@@ -98,18 +105,18 @@
           File Pos : 1 (94,24)
         SymOptions : Public
               Spez : Value
-          Regable : IntReg
-       Addr Taken : FALSE
+          Regable : Addr
+       Addr Taken : TRUE
           Var Type : (13) Unit 0, DefId 19
            Options : HasLocalCopy
       DefaultConst : (22) Nil
             ParaNr : 10
-         VarState : 2
+         VarState : 3
  ** Definition Id 1 **
  Record definition
        Type symbol : (32) SymId 59
         DefOptions :
-        DefStates :
+        DefStates : InitTable Used, RTTITable Used, InitTable Written, RTTITable Written
         FieldAlign : 0
        RecordAlign : 4
           PadAlign : 4
@@ -204,7 +211,7 @@
  Record definition
        Type symbol : (134) SymId 73
         DefOptions :
-        DefStates :
+        DefStates : InitTable Used, RTTITable Used, InitTable Written, RTTITable Written
         FieldAlign : 0
        RecordAlign : 4
           PadAlign : 4

etcetera.

> For the rest we can't help without having complete sources to reproduce. A single gdb backtrace
> doesn't help in this case. It shows only a result of a bug and not the real location where it goes
> wrong.

I can put the ppudump files somewhere, or try something else at your advice or send you the 
complete source code by private email. Whatever you prefer.

Regards,

Adriaan van Os