Re: rts/Printer.c
> > If it's a global symbol, you should be able to access it form the ffi. > > > > If you want to traverse data structures the way you can using the > > HugsInternals library, you might want to tweak the code a little to > > provide a similar semantics/ API. Basically, all you have to do is > > take the C code and split it into handy bits. > > This is a nice idea - we'll be happy to incorporate the changes. Hi, I'm on to it. Let's presume for the moment that I will solve a simpler problem, before I get the full task done. Say, for argument's sake, that I want to make the function printObj() available in Haskell, where: void printObj (StgClosure *obj); (as defined in and exported from rts/Printer.c) In Haskell I want to reflect this as: printObj :: a -> IO () Alistair mentioned that I could use the FFI to access some C code in the RTS. My intuition would have been to go about adding a primop as described in /ghc/compiler/prelude/primops.txt (ie without calling through the FFI). My trouble is I can't find any examples that are greatly similar to what I want to do. My question is: should I implement it through the FFI or as a primitive ala primops.txt? Perhaps they amount to much the same thing. Cheers, Bernie. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: rts/Printer.c
> > Is there a way to compile the RTS so that the names of data > > constructors are retained? > > My memory from a long, long time ago is that we had a debugging mode > which used libbfd to get symbol names and some GHC-demangling code to > turn those back into names like the user typed in. Yes, we still have that code, but it doesn't get much use - gdb can map addresses back to symbol names. I think I always intended to beef this up using a proper hash table for the address->symbol mapping, but never got around to it. Alternatively, if you compile for profiling, then info tables contain some extra information including the constructor name for contructors. > > It looks like Printer.c has some hooks for printing data structures, > > is it feasible to make a primitive that allows Haskell code to call > > into this? I'm thinking in particular of calling something like > > printClosure() from Haskell code. > > If it's a global symbol, you should be able to access it form the ffi. > > If you want to traverse data structures the way you can using the > HugsInternals library, you might want to tweak the code a little to > provide a similar semantics/ API. Basically, all you have to do is > take the C code and split it into handy bits. This is a nice idea - we'll be happy to incorporate the changes. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: GHC 4.08.2 on OpenBSD 2.9, almost
> I'm trying to port any recent version of ghc to OpenBSD 2.9. > > I have, with a little bit of work, been able to compile 4.08.2 > from .hc sources. > > I now get the following kind of undefined symbol errors: > > Main.o: Undefined symbol `__init_Prelude' referenced from text > segment > Main.o: Undefined symbol `PrelBase_unpackCStringzh_closure' > referenced from text segment > Main.o: Undefined symbol `PrelIO_putStr_closure' > referenced from > text segment > > [ ... ] > > PrelMain__1.o: Undefined symbol `___init_Main' > referenced from text > segment > .o::PrelMain(void): Undefined symbol > `_Main_main_closure' referenced > from text segment > .o::PrelMain(void): Undefined symbol > `_Main_main_closure' referenced > from text segment > > My guess is that this kind of thing has happened before > ... is there > an area in the source I should be looking at? This looks suspiciously like a mismatch in the handling of leading underscores in symbol names somewhere. It appears from the messages above that Main.o doesn't have extra leading underscores on its symbols, but the libraries do. Perhaps Main.o was compiled by the native code generator? Because the leading-underscore setting is compiled into the compiler via an external setting, you'll need to bootstrap the compiler before the setting will be correct for your system. Try compiling your test program with -fvia-C. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
