Marc:
Here's something to think about for later.
I know of no way, at the Scheme level, to debug incorrect declarations of fixnum or flonum. If you run an application interpreted, it just works, which is OK. If you run something compiled in safe mode, then it works whether the declarations are correct or not. And when you run it in unsafe mode then it generally fails with a segmentation fault. The only way I know to debug this type of fault is to compile Gambit and the application itself with - g, run the application inside gdb, then determine (a) what operation is failing and (b) the location of that operation in the scheme code by diagnosing the C output of gsc. Not fun, even for me ;-).
I'l like to suggest the following compilation model for compiling numerics in safe mode:
Declaration: generic, mostly-*
Result: Generates code to determine the types of arguments and do the correct thing, including calling the generic operations if necessary.
Declaration: fixnum, flonum
Result: check the types of arguments, and generate an exception of the arguments do not match the correct types.
I don't think there needs to be any change in unsafe mode.
This way I could debug mistaken declarations without going through gdb.
Brad
Afficher les réponses par date
On 24-Oct-05, at 7:49 PM, Bradley Lucier wrote:
Marc:
Here's something to think about for later.
I know of no way, at the Scheme level, to debug incorrect declarations of fixnum or flonum. If you run an application interpreted, it just works, which is OK. If you run something compiled in safe mode, then it works whether the declarations are correct or not. And when you run it in unsafe mode then it generally fails with a segmentation fault. The only way I know to debug this type of fault is to compile Gambit and the application itself with -g, run the application inside gdb, then determine (a) what operation is failing and (b) the location of that operation in the scheme code by diagnosing the C output of gsc. Not fun, even for me ;-).
I'll look into your suggestions. However, for tracking source-code location in gdb you can use the "-g" option and the Gambit compiler's "-track-scheme" option. Here's an example:
% cat test.scm (declare (standard-bindings) (fixnum) (not safe)) (define (sum vect) (let ((n (vector-length vect))) (let loop ((i n) (s 0)) (if (= i 0) s (loop (+ i 1) (+ s (vector-ref vect (- i 1)))))))) (pp (sum '#(11 22 33))) % gsc -dynamic -ld-options "-g" test.scm % gdb gsi GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ... done
(gdb) run test Starting program: /usr/local/Gambit-C/bin/gsi test Reading symbols for shared libraries . done Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x003d9000 ___H_sum (___ps=0x2a9be4) at test.c:147 147 ___SET_R2(___VECTORREF(___R1,___R2)) (gdb) q The program is running. Exit anyway? (y or n) y % gsc -dynamic -ld-options "-g" -track-scheme test.scm % gdb gsi GNU gdb 6.1-20040303 (Apple version gdb-413) (Wed May 18 10:17:02 GMT 2005) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries ... done
(gdb) run test Starting program: /usr/local/Gambit-C/bin/gsi test Reading symbols for shared libraries . done Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x003d9000 ___H_sum (___ps=0x2a9be4) at test.scm:8 8 (+ s (vector-ref vect (- i 1)))))))) (gdb)
On 25-Oct-05, at 7:08 PM, Bradley Lucier wrote:
On Oct 25, 2005, at 3:58 PM, Marc Feeley wrote:
for tracking source-code location in gdb you can use the "-g" option and the Gambit compiler's "-track-scheme" option.
Thanks, that's helpful. I didn't find that option when searching the documentation.
Brad
Doc says:
@opindex -track-scheme The @samp{-track-scheme} options causes the generation of @samp{#line} directives that refer back to the Scheme source code. This allows the use of a C debugger to debug Scheme code.
Marc
On Oct 25, 2005, at 8:37 PM, Marc Feeley wrote:
On 25-Oct-05, at 7:08 PM, Bradley Lucier wrote:
On Oct 25, 2005, at 3:58 PM, Marc Feeley wrote:
for tracking source-code location in gdb you can use the "-g" option and the Gambit compiler's "-track-scheme" option.
Thanks, that's helpful. I didn't find that option when searching the documentation.
Brad
Doc says:
@opindex -track-scheme The @samp{-track-scheme} options causes the generation of @samp{#line} directives that refer back to the Scheme source code. This allows the use of a C debugger to debug Scheme code.
Marc
I meant that before I sent my first e-mail, I searched the documentation for an option like this, and didn't find it.
After you pointed out that this option existed, I was able to find it in the documentation ;-).
Thanks again.
Brad
-
Bradley Lucier -
Marc Feeley