[Caml-list] ocamlc -output-obj problems

[Caml-list] ocamlc -output-obj problems

[Jonathan Roewen]

Hi,

I'm having serious problems with ocamlc -output-obj.

It seems if I create a global variable, the interpreter won't run (it
gets into caml_interprete, but I don't know where it goes wrong once
in that function).

Without any globals present, it runs fine.

let table = Hashtbl.create 8;;

Hashtbl.add table 42 "hello world";;

the above code, as simple as it is, causes things to break. Remove it,
and it'll run.

I experience the same problems when linking against Bigarray library,
and having a global value in my Console module.

The only custom parts in my ocaml environment are now just
libcamlrun.a, providing stub functions that return errors/raise
exceptions for functions I don't want/need to support.

My makefile is:

CFLAGS=-DCAML_NAME_SPACE -O -fno-defer-pop -ffreestanding -I
../include -I ../byterun -I ../ocaml/lib/ocaml -nostdlib -nostartfiles
-nostdinc

bytekernel.o: asm.mli keyboard.ml VFS.ml PCI.ml busManager.ml bytekernel.ml
	ocamlc -output-obj -o bytekernel.o asm.mli keyboard.ml VFS.ml PCI.ml
busManager.ml bytekernel.ml

kernel.elf: asm_loader.o irq.o c_loader.o bytekernel.o idt.o
asm_stubs.o fake_math.o console_stubs.o
	ld -s -static -nostdlib -Ttext 0x1000000 -e asm_start -L ../libc -L
../libm -L ../byterun \
		-o kernel.elf asm_loader.o irq.o c_loader.o idt.o asm_stubs.o
bytekernel.o fake_math.o console_stubs.o \
		-lcamlrun `gcc -print-file-name=libgcc.a` -lm -lc -L
../ocaml/lib/ocaml -lbigarray

Someone got half a clue on this?

Kindest Regards,

Jonathan

Re: [Caml-list] ocamlc -output-obj problems

[skaller]

On Tue, 2005-11-15 at 16:52 +1300, Jonathan Roewen wrote:
> Hi,
> 
> I'm having serious problems with ocamlc -output-obj.
> 
> It seems if I create a global variable, the interpreter won't run (it
> gets into caml_interprete, but I don't know where it goes wrong once
> in that function).
> 
> Without any globals present, it runs fine.

> The only custom parts in my ocaml environment are now just
> libcamlrun.a, providing stub functions that return errors/raise
> exceptions for functions I don't want/need to support.

Maybe one of those is actually being used?

Your basic argument is:

(a) the make process works for normal Ocaml
(b) you removed only unused functions from one library being linked in
    by stubbing them out
(c) now it crashes

==> contradiation.

Clearly the most likely is that (b) is wrong :)

Trying changing the stubs to print a diagnostic .. though
since the build isn't using standard libraries I don't
know how you'd do that (you may need to use low level Unix
calls like write instead of fprintf)

Global variables typically need special handling.. since the
idea is fundamentally flawed in the first place there is always
going to be some crud to try to workaround the design fault.
EG startup code to initialise some register to point to the
global data frame.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

Re: [Caml-list] ocamlc -output-obj problems

[Jonathan Roewen]

> Maybe one of those is actually being used?
>
> Your basic argument is:
>
> (a) the make process works for normal Ocaml
> (b) you removed only unused functions from one library being linked in
>    by stubbing them out
> (c) now it crashes
>
> ==> contradiation.
>
> Clearly the most likely is that (b) is wrong :)

Perhaps, but I've tried adding a few, and can't find anything.

Anyways, how can I find out what the given bytecode instruction is?
I've added some debugging to caml_interprete() to list the how many
instructions have passed.

Here's an even simpler example of what causes my bytecode to 'crash':

external print_string: string -> unit = "my_print_string";;
let printf args = Printf.ksprintf print_string args;;
print_string "Kernel shutting down..";;

the declaration of printf above causes it to fail. comment it out, it's fine.

Jonathan

Re: [Caml-list] ocamlc -output-obj problems

[Jonathan Roewen]

On 11/15/05, Jonathan Roewen <jonathan.roewen@gmail.com> wrote:
> Hmm, I made a test case to run with system ocaml tools. It segfaults
> =/ So, perhaps this is what's happening in my OS -- except I don't
> have anything to catch something like that...
>
> I've attached it. Very, very simple. Makefile, bytekernel.ml that has
> same problems on my OS, and c_loader.c that calls caml_startup() same
> way as I do in my OS.
>
> So perhaps it isn't just my imagination ;-)
>
> Hell if I know what's wrong either...
>
> Jonathan
>
>
>
I should also note: commenting out the printf declaration, it runs fine.

Re: [Caml-list] ocamlc -output-obj problems

[Jonathan Roewen]

> I should also note: commenting out the printf declaration, it runs fine.
>

Used gdb to trace where it's dying. It's in caml_copy_string().

Here's stacktrace:

(gdb) run
Starting program: /home/jonathan/kernel/kernel.elf

Program received signal SIGSEGV, Segmentation fault.
0x0804b48d in caml_copy_string ()
(gdb) bt
#0  0x0804b48d in caml_copy_string ()
#1  0x0804b54f in caml_alloc_array ()
#2  0x0804b595 in caml_copy_string_array ()
#3  0x08052cfb in caml_sys_get_argv ()
#4  0x080593b2 in caml_interprete ()
#5  0x0804a527 in caml_startup_code ()
#6  0x0804992b in caml_startup ()
#7  0x080498c6 in c_start ()
#8  0x080498ab in main ()

It makes no difference what I set argv to that I pass in. NULL makes
it die in caml_alloc_array(). { 0 } doesn't work, { "" } doesn't, nor
does { "", 0 }, nor does something arbitrary like { "hello", "world"
[, 0] }.

IMO, it sounds like ocamlc -output-obj is doing something funky it
shouldn't (I'm using 3.09.0 btw).

Commenting out the printf assignment thing, it runs fine .. so I'm
very, very suspicious of the compiler at this stage.

Jonathan

Re: [Caml-list] ocamlc -output-obj problems

[Jonathan Roewen]

It's all my fault. It's always all my fault ;D

char **argv = ... => char *argv[] = ...

that one simple change fixed it. god-damn it all ;-)

I'm glad ocaml doesn't have inconsistencies like this...

Sorry for all these emails...

Jonathan

Re: [Caml-list] ocamlc -output-obj problems

[Alessandro Baretta]

Jonathan Roewen wrote:
> It's all my fault. It's always all my fault ;D
> 
> char **argv = ... => char *argv[] = ...

Please excuse my stupidity: what's the difference?

Alex

Re: [Caml-list] ocamlc -output-obj problems

[skaller]

On Tue, 2005-11-15 at 14:01 +0100, Alessandro Baretta wrote:
> Jonathan Roewen wrote:
> > It's all my fault. It's always all my fault ;D
> > 
> > char **argv = ... => char *argv[] = ...
> 
> Please excuse my stupidity: what's the difference?

The first case says argv is a pointer to a pointer.
The second says it is an array of pointers.

When you pass an argument of the second type to a
function, it *decays* to the first type: there is 
no difference accessing the two.

But there is a HUGE difference in the data structure
created by a declaration -- the first reserves
exactly one word of storage. The second reserves
an actual array. Watch:

This compiles:

char * a[] = {"A","B"};
char ** b = a; 

This does NOT compile:

char * a[] = {"A","B"};
char ** b = {"A","B"};
a.c:2: warning: initialization from incompatible pointer type
a.c:2: warning: excess elements in scalar initializer
a.c:2: warning: (near initialization for ‘b’)

Note also: ++a is illegal, a is a constant. You cannot
increment an array. But ++b is allowed, it is merely
a pointer to the first element of the array.

And now notice Jonathan wrote:

> char **argv = ... => char *argv[] = ...

with an = in there. Looks like his gcc is broken :)

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net