[MLton] PowerPC .deb built

[Wesley W. Terpstra]

Erp, I found an error when the hppa build completed.
There are spaces, but no commas between 'Architecture: ' fields.
Otherwise, they build ok.

On Thu, May 12, 2005 at 10:07:03PM -0700, Stephen Weeks wrote:
> > 4. The unhelpful error checking /,% hit me again.
> >    How often is it really the case that these operations will be wrong?
> >    Is there even one platform where this is a concern?
> 
> I don't see the issue.  It seems good to be reminded of the
> potential problem.

Well, if it never happens, it's no problem..?
Sorry for a bad earlier suggestion btw, but s/__parisc__/__hppa__/ :-)

> > 5. I went digging through the kaffe source and copied it's definitions
> >    for accessing the instruction pointer for each platform except m68k. How
> >    can I test whether this is actually working?
> 
> Try time profiling (look in doc/examples/profiling).

Ok, I've tested the code; what I got from kaffe was for sa_handler, not
sa_sigaction. Damn. So, I've gone and found the right values for what MLton
does. Now powerpc and sparc are both fine with time profiling. I'll give you
a patch which fixes them as soon as I have hppa working. I intend to leave
the kaffe code for the other platforms as a comment (the code at least
includes the register names and correct structure indexes).

However, hppa is giving me some problems...

The first problem is that MLton uses function pointers, but these are not
the same as char* pointers. The getText{Start,End} use a function pointer to
_start and etext. From google cruising I noticed many people declare these
symbols as char or int (not a function) if they intend to take a pointer.

Motivated by this, I've gone and looked at the insides of tak using 'nm' and
debugging the labels and start/end from inside gc.c. (labels are sorted)

First, for control, on i386:
        08049600 T _start
        08050d37 T MLtonProfile0
        08051534 T MLtonProfile28
        08049c30 T MLtonProfile810
        08051490 T MLtonProfile1095
        0805f01b A etext

        Start: 8049600
        Label 0: 8049c30
        Label 1352: 8051534
        End: 805f01b

It makes no difference if I use char* or void (*)(void)

On hppa, though:
        function pointers:
                0001bd60 T _start
                0001e814 T MLtonProfile0
                0002f914 T MLtonProfile808
                00041270 A etext

                Start: 59b7e
                Label 0: 58e9e
                Label 808: 5aa9e
                End: 59b06

*** notice that the labels as reported by gc.c are out of start-end bounds!
--> failure to allocate the function lookup table (which is sick, btw :-)

        char pointers:
		000118e0 T _start
		00014394 T MLtonProfile0
		00012068 T MLtonProfile13
		00025530 T MLtonProfile806
		00025494 T MLtonProfile808
		00036df0 A etext

		Start: 118e0
		Label 0: 12068
		Label 808: 25530
		End: 36df0

Confirming with gdb the actual value of the program counter:
        Program received signal SIGINT, Interrupt.
        MLtonProfile455_internal () at /tmp/file2eaBXu.1.c:3971
        3971    /tmp/file2eaBXu.1.c: No such file or directory.
                in /tmp/file2eaBXu.1.c
        (gdb) print $pc
        $1 = (void *) 0x25640
        ... run some more ...
        $2 = (void *) 0x2530c

So, what I conclude is that you need to import the symbols as 'char' and
then take a pointer if you want to get a useful address 'portably'.

This requires only a few changes...

The first change is to platform/getText.c, where:
- extern void _start(void);
- extern void etext(void);
+ extern char _start;
+ extern char etext;

The second is to include/main.h:
  #define DeclareProfileLabel(l)                  \
-        void l()	__attribute__ ((weak))
+        extern char l __attribute__ ((weak))


Finally, (this change I have not tested, instead using sed on the .c files
to fix it; testing it will take 2 more days... erg), c-codegen.fun:
                   ("struct GC_sourceLabel", "sourceLabels", labels,
                    fn (_, {label, sourceSeqsIndex}) =>
-                    concat ["{(pointer)", ProfileLabel.toString label, ", ",
+                    concat ["{(pointer)&", ProfileLabel.toString label, ", ",

Do you think this is the correct fix?

> Done.  Althogh I would think having "checkout -P" in your .cvsrc would
> solve the problem.

True, and I have that on most machines, but I discover it is missing on
others by the regressions failing half-way through. It wouldn't be a big 
deal except the run takes nearly 24 hours and I leave it unattended.

-- 
Wesley W. Terpstra <wesley@terpstra.ca>