[MLton-devel] RedHat 7.1/7.3 problems

[Matthew Fluet]

> I'm leaning towards a subtle linker or assembler bug.

This is truly puzzling.  Consider the following:

[fluet@cfs38 ~/Temp 35]% gcc -Wall -O1 -g -c -o z.o z.c
[fluet@cfs05 ~/Temp 46]% gcc -Wall -O1 -g -o y y.c z.o
[fluet@cfs05 ~/Temp 50]% ./y @MLton gc-summary -- foo bar
MLton_init:
argc = 6
gc-summaryMain:
argv[2] = gc-summary
argv[3] = --
argv[4] = foo
argv[5] = bar
[fluet@cfs05 ~/Temp 47]% gdb y
GNU gdb Red Hat Linux (5.1-1)
(gdb) break main
Breakpoint 1 at 0x804846f: file y.c, line 7.
(gdb) break MLton_init
Breakpoint 2 at 0x80484bd: file z.c, line 6.
(gdb) run @MLton gc-summary -- foo bar
...
(gdb) step
24              printf("argv[%i] = %s\n", i, argv[i]);
(gdb) step
printf (format=0x8048678 "gc-summary") at printf.c:33
33      printf.c: No such file or directory.
        in printf.c

*** This is where it gets odd.  Note that the execution of z.c:24 steps to
printf with a format string equal to "gc-summary", not "argv[%i] = %s\n".
That explains why we see the line "gc-summaryMain:\n" being printed in the
output.

(gdb) finish
Run till exit from #0  printf (format=0x8048678 "gc-summary") at
printf.c:33
0x08048550 in MLton_init (argc=6, argv=0xbffff694) at z.c:24
24              printf("argv[%i] = %s\n", i, argv[i]);
Value returned is $6 = 10
(gdb) step
25              if (0 == strcmp (arg, "gc-summary")) {
(gdb) step
31                printf ("i > 1\n");

*** Again, very odd.  After evaluating the condition at z.c:25, the
program steps to z.c:31, a statement that corresponds to neither the true
branch nor the false branch of the if statement at z.c:25.

(gdb) step
printf (format=0x8048695 "") at printf.c:33
33      printf.c: No such file or directory.
        in printf.c

*** Another oddity.  Again, the format string in the printf call doesn't
equal the constant string at z.c:31

(gdb) finish
Run till exit from #0  printf (format=0x8048695 "") at printf.c:33
MLton_init (argc=6, argv=0xbffff694) at z.c:32
32                return i;
Value returned is $7 = 0
(gdb) step
...


So, it seems like the symbols are being scrambled for some reason.  That
would seem to point to a linker problem.  In fact, I can rule out the
assembler, because:

[fluet@cfs38 ~/Temp 49]% gcc -Wall -O1 -S -o z.s z.c
[fluet@cfs38 ~/Temp 50]% gcc -Wall -O1 -c -o z.o z.s
[fluet@cfs05 ~/Temp 51]% gcc -Wall -O1 -S -o y.s y.c
[fluet@cfs05 ~/Temp 52]% gcc -Wall -O1 -c -o y.o y.s
[fluet@cfs05 ~/Temp 54]% gcc -Wall -O1 -o y y.o z.o
[fluet@cfs05 ~/Temp 55]% ./y @MLton gc-summary -- foo bar
MLton_init:
argc = 6
gc-summaryMain:
argv[2] = gc-summary
argv[3] = --
argv[4] = foo
argv[5] = bar

but

[fluet@cfs05 ~/Temp 56]% gcc -Wall -O1 -c -o z.o z.s
[fluet@cfs05 ~/Temp 57]% gcc -Wall -O1 -o y y.o z.o
[fluet@cfs05 ~/Temp 58]% ./y @MLton gc-summary -- foo bar
MLton_init:
argc = 6
argv[2] = gc-summary
argv[3] = --
Main:
argv[4] = foo
argv[5] = bar

Steve, I'll send you the z.o object file created on cfs38.  Could you see
how that compiles and runs on your 7.1 machines.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
MLton-devel mailing list
MLton-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mlton-devel