This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Java field offsets [was; GCC 4.0 RC2 Available]


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]