On 05/27/2009 09:51 PM, David Essex wrote:
Well DWARF looks interesting, but I'm confused as to your objectives.
Perhaps you could clarify.
I'd love to. Thanks for the opportunity!
The problem statement: "How can I use gdb to examine a COBOL
identifier's value and attributes?"
As far as I can tell, the recommended answer to this question is to
search the
generated C code for the C variable name of a COBOL identifier of
interest, then use gdb to examine that C variable at the appropriate
time.
I'll stop here if this answer is correct and is the acceptable status
quo. I don't see another answer in the FAQ.
I'll stop here if this answer is incorrect.
I'll continue if this answer is correct, and is not the acceptable
status quo.
Based on my earlier research into "how do others solve the unsupported
language while using gdb issue?", Mono seems to provide an interesting
model
(http://www.mono-project.com/Debugging).
What they've done is to leverage gdb/Python integration (nice, but too
leading edge) to print formatted dumps of Mono data structures.
I'd like to propose the same thing for OC. gdb supports syntax like:
- call cob_literal_describe('processing-flag')
- call cob_identifier_describe('months(1)')
- call cob_identifier_print('months(2)')
There are at least two ways (and possibly more) to implement such
routines:
- Extend the compiler to produce symbol cross-reference and
descriptor information in a private format. Write C routines to read
this table at run-time.
- Extend the compiler to produce symbol cross-reference and
descriptor information in Dwarf format. Use libdwarf to produce this
file at compile-time and consume this file at run-time. I call this a
"shadow" file because it would augment debugging information written by
the C compiler. Using libdwarf has the advantage of not reinventing the
wheel.
Jeff Chimene wrote:
Would there be any interest in adding an object module generator to
OpenCOBOL?
I'm going to investigate adding support for libdwarf
(http://wiki.dwarfstd.org/index.php?title=Libdwarf_And_Dwarfdump)
Please let me know if this is unsuitable for OC.
The library is copyrighted by Silicon Graphics under the terms of the LPGL.
I'll continue this post once I get some confirmation the libdwarf is
suitable for inclusion in OC
From link [1]:
...
Many projects generate (gcc for example) and consume (gdb for example)
DWARF2/3 information without any reference-to or use-of libdwarf.
From link [2]:
...
The DWARF Debugging Information Format is of interest to programmers
working on compilers and debuggers.
1) Libdwarf And Dwarfdump
http://wiki.dwarfstd.org/index.php?title=Libdwarf_And_Dwarfdump
2) David A's DWARF Page
http://reality.sgiweb.org/davea/dwarf.html
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list
|