Per Bothner writes: > Andrew Haley wrote: > > However, these fields are real, and they are used, but we shouldn't > > output any debug info for them. > > Does Dwarf support "computed field offsets"? (This might be needed > for Ada, to.) If so, the Right Thing might be to emit DIEs so gdb > can calculate the field offsets, mimicing the normal "indirect > dispatch". > > Not to say this is worth doing, even if possible. It would probably > be a lot of work to have gdb understand computed offsets, and unless > it is needed for something else, it's not worth it for Java. > > That is because we want a solution that also works for dynamically > loaded interpreted classes, and the solution is to get the offsets > from the run-time data structures, rather than the debug information.
I agree. > There is some partially-bit-rotted code in gdb to extract type > information from run-time Class information, but it was fragile > because it didn't fit well with gdb's obstack-based memory management. > The situation might be different now. gcj and libgcj maintainers have talked about this at some length in the past. Right now the leaning contender AFAIK is to have gdb read gcj's internal reflection data to get the info it needs. Andrew Cagney suggests that the right way to do this is provide an interface library that is built as part of libgcj, and have the debugger use that. This seems to me like a sensible solution in that it insulates gdb from details of gcj's internal representation but still allows debuggers all the interface they need. > OTOH, just like we now use Dwarf2 unwind-info for exception handling, > perhaps we could use Dwarf debug information for reflection information. That's an alternative; I've considered run-time generation of DWARF data, but it it seems inefficient and untidy when compared with the alternative. Andrew.
