Robert Kiesling wrote:
> Okay, thanks. Please excuse the newbie question, and which should get
> me in the right direction. I would, however, like to determine which
> formats would be supported by an installed GCC. I suppose I could
> determine those by using a configure script and finding out which
> debug options don't generate errors, but it would be much better,
> ISTM, to do that at run time. I would like to support things like
> stack traces in a system independent manner. GDB does not provide
> a run-time library with that API, however. I guess I should find
> the bfd plugins useful for that, or add that to my wish list. :_
So just to clarify, the code you want to write would be in the position
of being part of a running executable which may or may not contain debug
information in its on-disk image file? And you want to access that
information at runtime to somehow utilize it?
If that's the case then it seems to me that gcc and its options are
irrelevant; it doesn't matter what the compiler, assembler, and/or
linker were or weren't capable of supporting, since you have a linked
binary and that's that. It either has some usable information (in one
or more formats) or it doesn't -- and there are countless variables[1]
outside of your control that could affect this. Besides, the toolchain
that built the binary might not be named "gcc", might not be in the
PATH, or even on the same machine, or even still existant anywhere, so
querying it seems brittle. Just look at the binary.
For a crude first approximation you can simply iterate over all section
headers looking for any with the SEC_DEBUGGING flag set, the moral
equivalent of "objdump -wh foo | grep DEBUGGING". If you find .stab and
.stabstr then you have stabs, if you see
.debug_{info,line,str,abbrev,...} then you have Dwarf-2, if you find
both you've got a mixture, if you see nothing then it's been stripped,
and so on.
The part that really seems like it's going to kill you is that you said
you want to do this in a system-independent manner. That is simply a
whole boatload of code to write: you need parsers for a number of file
formats (ELF, PE/COFF, Mach-O, ...?) and then parsers for a number of
debugging formats (Dwarf-2, stabs, dbx, SOM, ...?) This is a gargantuan
task on the level of reimplementing gdb.
There are standalone libraries for the common cases such as libelf[2]
and libdwarf[3], but that doesn't really help you reach the goal of
system-independence. BFD is of course another option but AFAIK that
only covers the file-format reading aspect, not the debug parsing
aspect. And I think you will find that working with it is somewhat
painful as it was never really intended to be a standalone library but
rather an integral part of binutils/gdb.
Brian
[1] It could have been:
- built without -g or with -g0
- built with the default -g
- built with a non-default -g (e.g. -gstabs+)
- built with a mix of formats (e.g. some objects compiled with -gdwarf-2
and some compiled with -gstabs+)
- built with -g but then later stripped
- built with -g and then had the debug info moved to a separate matching
.dbg file (--add-gnu-debuglink) which may or may not be present on the
system
[2] http://www.mr511.de/software/
[3] http://reality.sgiweb.org/davea/dwarf.html
