[Mono-list] JIT patch for stabs debugging
11 Mar 2002 16:49:50 +0100
Paolo Molaro <email@example.com> writes:
> On 03/11/02 Martin Baulig wrote:
> > Should I produce "good" an clean dwarf-2 code (ie. exactly as it's
> > described in the dwarf-2 specification) or only use features which are
> > already supported by gdb ?
> > At the moment, I'm writing good code, but this forces people to use at
> > least gdb 5.1.1 (the latest released version), it does not work with
> > gdb 5.0.
> > IMO it makes sense to produce good dwarf-2 code since mono is a very
> > long living project and will still take several months until its
> > completion and gdb should have full dwarf-2 support in near future.
> Are the features not supported by gdb 5.0 important? Can it still be
> used even if some features are missing?
It does not work at all with gdb 5.0, it aborts loading the symbol
file with an error message.
> If gdb 5.0 still works when the debug info is more complete, I'd say
> output the full info. Otherwise it's better to have a switch that selects
> which version to output, if it's not too tricky to support both.
I already designed the code in a way which makes this possible.
The feature which is missing in gdb 5.0 is DW_FORM_strp:
In dwarf2, there are two ways to specify a string (for instance, a file
or method name) attribute:
a) you use DW_FORM_string and the zero-terminated string as attribute
The generated assembler code looks like this:
b) you use DW_FORM_strp and an offset into the string table.
The generated code looks like this:
and somewhere in the file, you have
.string "Mono JIT compiler version 0.9"
The second method (which can reduce the size of the generated symbol
file a lot since each string is only stored once) is not supported by
It won't be a problem to decide at runtime which one to use.
> Also, don't delete the support for stabs, since it's possible it could
> be the only debugging format of some platforms.
Sure. I rewrote debug.c to make it much more modular so that we can
even support other debugging formats in future.
It also solves the relocation problem - mono_debug_make_symbols () can
now safely be called multiple times and it always writes a complete
symbol file (with dwarf, you cannot simply append to a file like it's
done in the stabs code).
This means than when you hit a breakpoint, you can just call
mono_debug_make_symbols () and then reload the symbol table.
Another important thing is that I rewrote the line number generation
code, the debugging format dependent part of it now operates on an
in-memory array of line number information and now longer reads the
numbers directly from the MonoFlowGraph. This allows us to reuse this
code to emit line number information for C# source files later on.
I'll post a detailed description of my changes and a patch later on.