Quoth felix winkelmann <[EMAIL PROTECTED]>, on 2008-02-05 08:50:56 +0100: > Ok. The only idea I have right now is to build with "DEBUGBUILD=1" and > compile gl.scm under the debugger.
I now have Chicken with DEBUGBUILD=1 running in a GDB trying to compile gl.scm with the same command line chicken-setup's csc invocation said it was using before. It bombs with SEGV. I could show the whole backtrace, but given the way Chicken uses C calls I'm not sure it'd be helpful... is there something specific I should be doing in this case? I see a couple of references on chicken-hackers, but nothing that I can decipher; I also see a reference to gdb.egg < http://www.mail-archive.com/[email protected]/msg04747.html >, but that appears to be for some other purpose. The top stackframe shows: #0 0x0000000000482398 in f_10980 (c=2, t0=140735375900672, t1=6) at compiler.c:5429 5429 if(C_truep((C_word)C_lambdainfop(((C_word*)t0)[5]))){ There's about five hundred other opaque-looking stackframes, and then #502 0x00002b8728bb323a in tr2 (k=0x2b8728c4b5a6 <f_4232>) at library.c:6067 #503 0x00002b8728ecde35 in CHICKEN_run (toplevel=0x0) at runtime.c:1345 #504 0x00002b8728ecbac3 in CHICKEN_main (argc=17, argv=0x7fff821765b8, toplevel=0x404539) at runtime.c:564 #505 0x00000000004044fe in main (argc=17, argv=0x7fff821765b8) at chicken.c:1929 which I don't expect to be that helpful. GDB appears to be refusing to load the header files containing any of these macros (for reasons which I do not know---it found the compiler.c source file just fine), meaning that trying to evaluate the pieces of that statement to pick it apart would be an exercise in pain at the moment. Should I try to get GDB to behave on that front, or is that barking up the wrong tree? > cheers, > felix ---> Drake Wilson _______________________________________________ Chicken-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/chicken-users
