3 ms·

I'm regularly using Tcl to sling C around and when I run into issues, gdb is there -- is he talking about something different, or am I missing something?

by bch 14y ago

scott_s 14y ago
His point is that when you're using gdb in your C code, the higher level language that called your C code (Erlang, Tcl, whatever) is opaque. That is, if when looking at your C code, you realize "the only way this variable can have this value is if my higher level code has this other value..." you can't easily inspect the higher level code in your debugger. Unless gdb is more powerful than I'm giving it credit for. Does it allow cross-language debugging from Tcl to C, and back to Tcl?
- bch 14y ago
  Well -- Tcl happens to be difficult to debug w/ tools because it's so dynamic -- but that said, let me tell you what I run into, and how I resolve. I compile C (original C, or bindings to libraries) and enable all warnings, use Tcl C APIs to do C memory management (allows electric-fence like behaviour where I've got optional guards on allocated mem), and I'm pretty familiar w/ the Tcl C API. When something is horribly wrong, I'll get a core dump and the full stack trace will indicate the path from Tcl, on up into my bindings, and further into the library in question. From there, typically with a small amount of inspection and testing it's easy to isolate the problem area and fix. This way I've solve application (Tcl script) code, my library bindings, and errors in 3rd party (open source) libs -- I've got no doubt that there's room for improvement in my process -- either by tools or techniques. That said, I feel productive and happy with what I've got going on now. When I want performance in Tcl, I punt and push it to C. When I want dynamic control or nice interfaces, I punt and drive it with Tcl.
  - scott_s 14y ago
    I think that's a reasonable process, and probably the best you can do with current tools. But even though it's reasonable given your software stack, it's still much more involved than just using gdb on C code. (Note that I'm not arguing that it's never worthwhile to use a higher level language to drive C code, just that I think Katz has a valid point regarding debugging.)
  - niggler 14y ago
    " I'm pretty familiar w/ the Tcl C API" The Tcl C API is fairly simple, and that's by design. There's a very slim chance you loused something up in the interface. Dealing with the interface from Erlang, or with many other higher level languages, is like pulling teeth.

I'm regularly using Tcl to sling C around and when I run into issues, gdb is there -- is he talking about something different, or am I missing something?

by bch 14y ago

I'm regularly using Tcl to sling C around and when I run into issues, gdb is there -- is he talking about something different, or am I missing something?

scott_s 14y ago

His point is that when you're using gdb in your C code, the higher level language that called your C code (Erlang, Tcl, whatever) is opaque. That is, if when looking at your C code, you realize "the only way this variable can have this value is if my higher level code has this other value..." you can't easily inspect the higher level code in your debugger. Unless gdb is more powerful than I'm giving it credit for. Does it allow cross-language debugging from Tcl to C, and back to Tcl?

bch 14y ago
Well -- Tcl happens to be difficult to debug w/ tools because it's so dynamic -- but that said, let me tell you what I run into, and how I resolve. I compile C (original C, or bindings to libraries) and enable all warnings, use Tcl C APIs to do C memory management (allows electric-fence like behaviour where I've got optional guards on allocated mem), and I'm pretty familiar w/ the Tcl C API. When something is horribly wrong, I'll get a core dump and the full stack trace will indicate the path from Tcl, on up into my bindings, and further into the library in question. From there, typically with a small amount of inspection and testing it's easy to isolate the problem area and fix. This way I've solve application (Tcl script) code, my library bindings, and errors in 3rd party (open source) libs -- I've got no doubt that there's room for improvement in my process -- either by tools or techniques. That said, I feel productive and happy with what I've got going on now. When I want performance in Tcl, I punt and push it to C. When I want dynamic control or nice interfaces, I punt and drive it with Tcl.
- scott_s 14y ago
  I think that's a reasonable process, and probably the best you can do with current tools. But even though it's reasonable given your software stack, it's still much more involved than just using gdb on C code. (Note that I'm not arguing that it's never worthwhile to use a higher level language to drive C code, just that I think Katz has a valid point regarding debugging.)
- niggler 14y ago
  " I'm pretty familiar w/ the Tcl C API" The Tcl C API is fairly simple, and that's by design. There's a very slim chance you loused something up in the interface. Dealing with the interface from Erlang, or with many other higher level languages, is like pulling teeth.