RE: dwarf support for assembly level debugging information

[David Anderson <davea at quasar dot engr dot sgi dot com>]

>Is there any documentation on relationship between sections available?

See the appendix in dwarf3 (Appendix B).

>Can dwarf fall short of certain sections and still provide effective
>debugging facilities. This I inquire because I need to generate dwarf
>debugging information for assembly. I know we will fall short of certain
>sections. Can debuggers take it.


Try to create  a CU per .o with CU header,
CU DIE, subprogram DIEs. 
(so that means abbreviations must exist too).
To start, ignore type info (not required in dwarf)
as leaving type info out makes things much simpler.

Try to create sufficient info in .debug_frame so backtraces
work reliably.

The .debug_pubnames info is useful, and would refer to global
functions you define in assembler.

Maybe put the strings in .debug_str as that is convenient, you may find.

By restricting to this simple form you will find you can easily
generate dwarf that gnu-as can deal with. Well, reasonably easily.
By a perl script. Because most of the dwarf bytes are
identical.  In other words, first run the assembler thru
perl, digest your dwarfstuff and the
assembler code (maybe add stylized comments
for perl to read), turn into bytes gnu-as already
understands as dwarf2. The output being gnu-as input.

Just write down the readelf/dwarfdump content you want to see
and figure out the bytes (or do a simple .c and look at what
readelf/dwarfdump print out) and you will see it is not difficult.
Most bytes are identical per subprogram. Just a few change.

It's how we had SGI ld(1) create dwarf info for stubs and init code
and was much easier to do than you might think.
(as long as you keep your goals reasonable!)
Just took a few hours.


At present no assembler deals with stuff that
looks like the output of readelf or dwarfdump, but that
form is pretty attractive for some purposes. 
(This is what Chris Quenelle mentioned recently.)
It is not dense, so a compiler would not want to emit it,
I suppose, but for generating a .o by hand it would be great.

I have considered doing a tool to read
readelf/dwarfdump output and construct dwarf/elf .o
sections, but have not found time.

Hope this makes sense.
David Anderson.