Binary Compatibility: debug info for compiled Java programs

Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

At the gcc summit last week, we were asked about how we're going to do
debug info for programs compiled with the BC ABI.  This is a problem:
as we don't know the layout of objects at compile time, we can't
generate the usual DWARF debugging type info.

I said that there were two front-running solutions: calling into
libgcj runtime routines that access the metadata, or generating DWARF
debugging type info at run time.  Andrew Cagney objects to calling
libgcj runtime routines, because then we won't be able to debug core
files.  Also, if the runtime library is hosed for some reason, we
won't be able to debug any structures.  This is a good point, and I
suppose it more or less kills the idea.

Bryce pointed out that there is another solution that he favours,
which involves gdb reading libgcj's metadata.

I reacted badly to this idea because I found it rather distasteful.
It seems to me that to do it this way is a case of pathological
coupling that I'd like to avoid.  However, it may well be the most
efficient solution because it doesn't involve doing any extra work at
runtime.

Bryce pointed out that there's already some precedent for this, in
that C++ debugging already does something similar.  He also thinks
that doing this is easier than generating DWARF in libgcj.  I'm not
sure about that, one way or the other.

Both solutions require gdb changes: to generate DWARF data at runtime
requires some changes because gdb is used to reading debug data from
object files, not from the inferior process.

So, I'm still unsure about how to proceed.  It looks like Bryce's
suggestion is preferable on efficiency grounds, although it might be
possible to generate DWARF cheaply while laying out classes.

Bryce, sorry if I've misstated your position.  This is based on my
best recollection.

Comments welcome...

Andrew.

Re: Binary Compatibility: debug info for compiled Java programs

[Daniel Jacobowitz]

On Wed, Jun 09, 2004 at 01:13:49PM +0100, Andrew Haley wrote:
> At the gcc summit last week, we were asked about how we're going to do
> debug info for programs compiled with the BC ABI.  This is a problem:
> as we don't know the layout of objects at compile time, we can't
> generate the usual DWARF debugging type info.
> 
> I said that there were two front-running solutions: calling into
> libgcj runtime routines that access the metadata, or generating DWARF
> debugging type info at run time.  Andrew Cagney objects to calling
> libgcj runtime routines, because then we won't be able to debug core
> files.  Also, if the runtime library is hosed for some reason, we
> won't be able to debug any structures.  This is a good point, and I
> suppose it more or less kills the idea.
> 
> Bryce pointed out that there is another solution that he favours,
> which involves gdb reading libgcj's metadata.

I'm not familiar with the BC ABI (and missed the talk); could you give
me an example of what information you have at compile time and what you
generate at runtime?

I suspect that a fourth solution is possible: gcj generating DWARF
which describes how to read the metadata.  It may not be very
efficient, though, and it will still require a certain amount of
playing with GDB.

-- 
Daniel Jacobowitz

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

Daniel Jacobowitz writes:
 > 
 > I'm not familiar with the BC ABI (and missed the talk); could you give
 > me an example of what information you have at compile time and what you
 > generate at runtime?

All structures are laid out at runtime.

http://people.redhat.com/lockhart/.gcc04/MasterGCC-2side.pdf  Page 169.

 > I suspect that a fourth solution is possible: gcj generating DWARF
 > which describes how to read the metadata.  It may not be very
 > efficient, though, and it will still require a certain amount of
 > playing with GDB.

Yeah, that was suggested as well.  I forgot to mention it.  I don't
know if this is possible in DWARF data: don't member offsets have to
be constants?

I must admit I like this idea least of all!  Maybe I subconsciously
suppressed the memory.

Andrew.

Re: Binary Compatibility: debug info for compiled Java programs

[Daniel Jacobowitz]

On Wed, Jun 09, 2004 at 02:16:44PM +0100, Andrew Haley wrote:
> Daniel Jacobowitz writes:
>  > 
>  > I'm not familiar with the BC ABI (and missed the talk); could you give
>  > me an example of what information you have at compile time and what you
>  > generate at runtime?
> 
> All structures are laid out at runtime.
> 
> http://people.redhat.com/lockhart/.gcc04/MasterGCC-2side.pdf  Page 169.

So: the list of members, the inheritance tree, et cetera is static at
compile time; for their locations you have runtime tables.

>  > I suspect that a fourth solution is possible: gcj generating DWARF
>  > which describes how to read the metadata.  It may not be very
>  > efficient, though, and it will still require a certain amount of
>  > playing with GDB.
> 
> Yeah, that was suggested as well.  I forgot to mention it.  I don't
> know if this is possible in DWARF data: don't member offsets have to
> be constants?
> 
> I must admit I like this idea least of all!  Maybe I subconsciously
> suppressed the memory.

Could you explain what you don't like about it?

Member offsets definitely don't have to be constant.  In fact, from the
spec:
  For a C++ virtual base, the data member location attribute will
  usually consist of a non-trivial location expression.
The way C++ handles virtual bases is similar enough in execution that
the same thing will work here.  For a member it would look like:

  # Base location of the class is on the stack
  DW_OP_addr <otable location>
  DW_OP_constu <otable offset>
  DW_OP_plus
  DW_OP_deref (or DW_OP_deref_size <size of atable entry>)
  DW_OP_plus



-- 
Daniel Jacobowitz

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

Daniel Jacobowitz writes:
 > On Wed, Jun 09, 2004 at 02:16:44PM +0100, Andrew Haley wrote:
 > > Daniel Jacobowitz writes:
 > >  > 
 > >  > I'm not familiar with the BC ABI (and missed the talk); could you give
 > >  > me an example of what information you have at compile time and what you
 > >  > generate at runtime?
 > > 
 > > All structures are laid out at runtime.
 > > 
 > > http://people.redhat.com/lockhart/.gcc04/MasterGCC-2side.pdf  Page 169.
 > 
 > So: the list of members, the inheritance tree, et cetera is static at
 > compile time; for their locations you have runtime tables.

No, not exactly.  It's possible to insert a class into the inheritance
chain or add new fields.

 > >  > I suspect that a fourth solution is possible: gcj generating DWARF
 > >  > which describes how to read the metadata.  It may not be very
 > >  > efficient, though, and it will still require a certain amount of
 > >  > playing with GDB.
 > > 
 > > Yeah, that was suggested as well.  I forgot to mention it.  I don't
 > > know if this is possible in DWARF data: don't member offsets have to
 > > be constants?
 > > 
 > > I must admit I like this idea least of all!  Maybe I subconsciously
 > > suppressed the memory.
 > 
 > Could you explain what you don't like about it?

An odd feeling of unease, I suppose.  I imagine the expressions could
become rather complex.

 > Member offsets definitely don't have to be constant.  In fact, from the
 > spec:
 >   For a C++ virtual base, the data member location attribute will
 >   usually consist of a non-trivial location expression.
 > The way C++ handles virtual bases is similar enough in execution that
 > the same thing will work here.  For a member it would look like:
 > 
 >   # Base location of the class is on the stack
 >   DW_OP_addr <otable location>
 >   DW_OP_constu <otable offset>
 >   DW_OP_plus
 >   DW_OP_deref (or DW_OP_deref_size <size of atable entry>)
 >   DW_OP_plus

Okay, that's good.  Would we also be able to cope with not being able
to resolve our superclass till runtime?  It can't just be a pointer to
a symbol, because there may be many identical symbols.

Andrew.

Re: Binary Compatibility: debug info for compiled Java programs

[Daniel Jacobowitz]

On Wed, Jun 09, 2004 at 02:37:41PM +0100, Andrew Haley wrote:
> Daniel Jacobowitz writes:
>  > On Wed, Jun 09, 2004 at 02:16:44PM +0100, Andrew Haley wrote:
>  > > Daniel Jacobowitz writes:
>  > >  > 
>  > >  > I'm not familiar with the BC ABI (and missed the talk); could you give
>  > >  > me an example of what information you have at compile time and what you
>  > >  > generate at runtime?
>  > > 
>  > > All structures are laid out at runtime.
>  > > 
>  > > http://people.redhat.com/lockhart/.gcc04/MasterGCC-2side.pdf  Page 169.
>  > 
>  > So: the list of members, the inheritance tree, et cetera is static at
>  > compile time; for their locations you have runtime tables.
> 
> No, not exactly.  It's possible to insert a class into the inheritance
> chain or add new fields.

That's something you can do while preserving Binary Compatibility, but
if we find the loaded copy of the class, its compile-time-generated
debug information will describe its fields, right?  And if we find an
older copy of the debug information, then the new fields will appear to
be invisible but the existing fields will be located OK.  OK, that's a
minor problem in that we need to learn how to prefer the right copy of
the debug info.

>  > Member offsets definitely don't have to be constant.  In fact, from the
>  > spec:
>  >   For a C++ virtual base, the data member location attribute will
>  >   usually consist of a non-trivial location expression.
>  > The way C++ handles virtual bases is similar enough in execution that
>  > the same thing will work here.  For a member it would look like:
>  > 
>  >   # Base location of the class is on the stack
>  >   DW_OP_addr <otable location>
>  >   DW_OP_constu <otable offset>
>  >   DW_OP_plus
>  >   DW_OP_deref (or DW_OP_deref_size <size of atable entry>)
>  >   DW_OP_plus
> 
> Okay, that's good.  Would we also be able to cope with not being able
> to resolve our superclass till runtime?  It can't just be a pointer to
> a symbol, because there may be many identical symbols.

No, unfortunately, that won't work.  Not sure what to do about that.

-- 
Daniel Jacobowitz

Re: Binary Compatibility: debug info for compiled Java programs

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

>> No, not exactly.  It's possible to insert a class into the inheritance
>> chain or add new fields.

Daniel> That's something you can do while preserving Binary Compatibility, but
Daniel> if we find the loaded copy of the class, its compile-time-generated
Daniel> debug information will describe its fields, right?

Not really.  First, you can read about Java binary compatibility here:

http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#44872

However, this is only part of the picture.  The other part is that the
Java runtime environment can differ from the compile-time environment.
In particular, a given class can be loaded into a running virtual
machine any number of times, via different ClassLoaders.  And since
all references used by a class are symbolic, and since a ClassLoader
mediates the name->class lookup, it follows that each separately
loaded instance of such a class can have different superclasses.

I.e., we load class Derived, which inherits from class Base, twice.
We load it once via ClassLoader A and once via ClassLoader B.  Then we
can end up with different versions of Base, that might have different
properties.  E.g., B's Base might have extra private fields.  (Exactly
what changes are valid is what is described in that chapter of the
JLS.)


In our BC ABI, we add a new level of indirection.  So, a field lookup
isn't just *(object+offset), but instead *(object+otable[index]),
where the otable ("offset table") is computed at class initialization
time.

Generating Dwarf that redirects through the otable, like the code
itself does, is tempting.  But is it possible?  I don't see how
something like 'print object' would work -- you would have to look
more closely at all the reflection data to discover all the fields in
a given class.

Tom

Re: Binary Compatibility: debug info for compiled Java programs

[Daniel Jacobowitz]

On Wed, Jun 09, 2004 at 04:25:01PM -0600, Tom Tromey wrote:
> However, this is only part of the picture.  The other part is that the
> Java runtime environment can differ from the compile-time environment.
> In particular, a given class can be loaded into a running virtual
> machine any number of times, via different ClassLoaders.  And since
> all references used by a class are symbolic, and since a ClassLoader
> mediates the name->class lookup, it follows that each separately
> loaded instance of such a class can have different superclasses.
> 
> I.e., we load class Derived, which inherits from class Base, twice.
> We load it once via ClassLoader A and once via ClassLoader B.  Then we
> can end up with different versions of Base, that might have different
> properties.  E.g., B's Base might have extra private fields.  (Exactly
> what changes are valid is what is described in that chapter of the
> JLS.)
> 
> 
> In our BC ABI, we add a new level of indirection.  So, a field lookup
> isn't just *(object+offset), but instead *(object+otable[index]),
> where the otable ("offset table") is computed at class initialization
> time.

I still don't see how this mechanism implements the above principle,
i.e. converting symbolic field names to offsets; is the otable
associated with the object doing the access or with the objet defining
the class?  Anyway, I could probably work this out if I sat down for an
hour with your paper :)

> Generating Dwarf that redirects through the otable, like the code
> itself does, is tempting.  But is it possible?  I don't see how
> something like 'print object' would work -- you would have to look
> more closely at all the reflection data to discover all the fields in
> a given class.

Generating Dwarf that redirects through a particular otable is easy. 
Generating information to describe the sort of symbolic changes to
inheritance and fields, on the other hand, is not.

-- 
Daniel Jacobowitz

Re: Binary Compatibility: debug info for compiled Java programs

[Tom Tromey]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

>> In our BC ABI, we add a new level of indirection.  So, a field lookup
>> isn't just *(object+offset), but instead *(object+otable[index]),
>> where the otable ("offset table") is computed at class initialization
>> time.

Daniel> I still don't see how this mechanism implements the above principle,
Daniel> i.e. converting symbolic field names to offsets; is the otable
Daniel> associated with the object doing the access or with the objet defining
Daniel> the class?

The otable is associated with the class that is doing the access.
So if the implementation of class Foo refers to a method C.m(), then
the otable for Foo will have an entry "C.m" (with type signature, and
maybe some other stuff).

The symbols in the otable (and actually I've been using shorthand
here, we have a second "atable" for addresses as well -- same
difference though) are resolved when the class ("Foo") is linked.  In
Java this is done at runtime, the JVM Spec (and perhaps the JLS) has
information on the precise steps involved in class preparation and
initialization.

Tom

Re: Binary Compatibility: debug info for compiled Java programs

[Ian Lance Taylor]

Tom Tromey <tromey@redhat.com> writes:

> The symbols in the otable (and actually I've been using shorthand
> here, we have a second "atable" for addresses as well -- same
> difference though) are resolved when the class ("Foo") is linked.  In
> Java this is done at runtime, the JVM Spec (and perhaps the JLS) has
> information on the precise steps involved in class preparation and
> initialization.

By the way, Tom and Andrew, I meant to ask, but I forgot: would it
make sense to build the numeric otables and atables for the common
case, and then recompute only when required?  I have to think that the
common case is pretty darn common--I'm sure people don't spend all
their time loading classes into different hierarchies.  Perhaps you
already do this.

Ian

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

Ian Lance Taylor writes:
 > Tom Tromey <tromey@redhat.com> writes:
 > 
 > > The symbols in the otable (and actually I've been using shorthand
 > > here, we have a second "atable" for addresses as well -- same
 > > difference though) are resolved when the class ("Foo") is linked.  In
 > > Java this is done at runtime, the JVM Spec (and perhaps the JLS) has
 > > information on the precise steps involved in class preparation and
 > > initialization.
 > 
 > By the way, Tom and Andrew, I meant to ask, but I forgot: would it
 > make sense to build the numeric otables and atables for the common
 > case, and then recompute only when required?

That's possibly true, but you'd somehow have to discover that
something had changed, and I'm not sure how you'd do that without
doing the lookups.

 > I have to think that the common case is pretty darn common--I'm
 > sure people don't spend all their time loading classes into
 > different hierarchies.

What is very common is for people to distribute Java binaries without
specifying the exact versions of the classes they depend on.  So, it's
normal for the run-time library environment of a Java program to be
different from the compile-time environment.  The whole idea of binary
compatibility is to make this possible.

Andrew.

Re: Binary Compatibility: debug info for compiled Java programs

[Ian Lance Taylor]

Andrew Haley <aph@redhat.com> writes:

>  > By the way, Tom and Andrew, I meant to ask, but I forgot: would it
>  > make sense to build the numeric otables and atables for the common
>  > case, and then recompute only when required?
> 
> That's possibly true, but you'd somehow have to discover that
> something had changed, and I'm not sure how you'd do that without
> doing the lookups.

It seems to me that you could hash the relevant information for each
relevant class and store it in the defining class and in the loaded
class.  When you load the binary, check the hashes, and recompute if
they differ.

>  > I have to think that the common case is pretty darn common--I'm
>  > sure people don't spend all their time loading classes into
>  > different hierarchies.
> 
> What is very common is for people to distribute Java binaries without
> specifying the exact versions of the classes they depend on.  So, it's
> normal for the run-time library environment of a Java program to be
> different from the compile-time environment.  The whole idea of binary
> compatibility is to make this possible.

On the other hand, at during compile/edit/debug, the compile-time and
run-time environment should be similar.

Hmmm, I suppose that could be a good way to hide bugs, though.

Ian

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

Ian Lance Taylor writes:
 > Andrew Haley <aph@redhat.com> writes:
 > 
 > >  > By the way, Tom and Andrew, I meant to ask, but I forgot: would it
 > >  > make sense to build the numeric otables and atables for the common
 > >  > case, and then recompute only when required?
 > > 
 > > That's possibly true, but you'd somehow have to discover that
 > > something had changed, and I'm not sure how you'd do that without
 > > doing the lookups.
 > 
 > It seems to me that you could hash the relevant information for each
 > relevant class and store it in the defining class and in the loaded
 > class.  When you load the binary, check the hashes, and recompute if
 > they differ.

That's worth thinking about.

Say you have a reference to foo.bar and a hash for foo.  You compute
the hash for foo and see that it hasn't changed, so you don't have to
recompute the offset of foo.bar.  That's cool, but hashing is no
easier than recomputing the offset.  So, it's only a win if you have a
lot of references to members of foo.  This might be a big win if you
can show that none of your ancestors have changed, so you don't need
to recompute the offsets of any of your own members.

What you could perhaps do is have two versions of a method, and only
use the BC version if the classes it depends on have changed.  That
would be quicker, but maybe more effort than is really warranted.  It
might be useful for escape analysis, though: you might be able to
prove that an object doesn't escape as long as the lasses it depends
on haven't changed.

 > >  > I have to think that the common case is pretty darn common--I'm
 > >  > sure people don't spend all their time loading classes into
 > >  > different hierarchies.
 > > 
 > > What is very common is for people to distribute Java binaries without
 > > specifying the exact versions of the classes they depend on.  So, it's
 > > normal for the run-time library environment of a Java program to be
 > > different from the compile-time environment.  The whole idea of binary
 > > compatibility is to make this possible.
 > 
 > On the other hand, at during compile/edit/debug, the compile-time and
 > run-time environment should be similar.

Yes, that's true.

Andrew.

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

Daniel Jacobowitz writes:
 > On Wed, Jun 09, 2004 at 04:25:01PM -0600, Tom Tromey wrote:
 > > However, this is only part of the picture.  The other part is that the
 > > Java runtime environment can differ from the compile-time environment.
 > > In particular, a given class can be loaded into a running virtual
 > > machine any number of times, via different ClassLoaders.  And since
 > > all references used by a class are symbolic, and since a ClassLoader
 > > mediates the name->class lookup, it follows that each separately
 > > loaded instance of such a class can have different superclasses.
 > > 
 > > I.e., we load class Derived, which inherits from class Base, twice.
 > > We load it once via ClassLoader A and once via ClassLoader B.  Then we
 > > can end up with different versions of Base, that might have different
 > > properties.  E.g., B's Base might have extra private fields.  (Exactly
 > > what changes are valid is what is described in that chapter of the
 > > JLS.)
 > > 
 > > 
 > > In our BC ABI, we add a new level of indirection.  So, a field lookup
 > > isn't just *(object+offset), but instead *(object+otable[index]),
 > > where the otable ("offset table") is computed at class initialization
 > > time.
 > 
 > I still don't see how this mechanism implements the above principle,
 > i.e. converting symbolic field names to offsets; is the otable
 > associated with the object doing the access or with the objet defining
 > the class?

The object doing the access.  Every class has an otable that is fixed
up with the field offsets of every field that it accesses.

 > > Generating Dwarf that redirects through the otable, like the code
 > > itself does, is tempting.  But is it possible?  I don't see how
 > > something like 'print object' would work -- you would have to look
 > > more closely at all the reflection data to discover all the fields in
 > > a given class.
 > 
 > Generating Dwarf that redirects through a particular otable is easy. 
 > Generating information to describe the sort of symbolic changes to
 > inheritance and fields, on the other hand, is not.

That's kinda what I expected.  Is it hard to generate DWARF to
describe class layout?

Andrew.

Re: Binary Compatibility: debug info for compiled Java programs

[Daniel Jacobowitz]

On Thu, Jun 10, 2004 at 05:42:20PM +0100, Andrew Haley wrote:
> Daniel Jacobowitz writes:
>  > I still don't see how this mechanism implements the above principle,
>  > i.e. converting symbolic field names to offsets; is the otable
>  > associated with the object doing the access or with the objet defining
>  > the class?
> 
> The object doing the access.  Every class has an otable that is fixed
> up with the field offsets of every field that it accesses.

Thanks, that's what I was missing.

>  > > Generating Dwarf that redirects through the otable, like the code
>  > > itself does, is tempting.  But is it possible?  I don't see how
>  > > something like 'print object' would work -- you would have to look
>  > > more closely at all the reflection data to discover all the fields in
>  > > a given class.
>  > 
>  > Generating Dwarf that redirects through a particular otable is easy. 
>  > Generating information to describe the sort of symbolic changes to
>  > inheritance and fields, on the other hand, is not.
> 
> That's kinda what I expected.  Is it hard to generate DWARF to
> describe class layout?

That depends.  A decent-sized chunk of dwarf2out is devoted to this; on
the other hand, you've got a much simpler problem to solve since you're
only dealing with Java aggregates.  The hardest part would be
describing the types of fields with appropriate cross-referencing.

I'm not sure how to do this without nasty runtime overhead; it might be
easier to keep the logic in GDB.  I haven't given it much thought,
though.

-- 
Daniel Jacobowitz

Re: Binary Compatibility: debug info for compiled Java programs

[Per Bothner]

Andrew Haley wrote:
> Bryce pointed out that there is another solution that he favours,
> which involves gdb reading libgcj's metadata.

There is already (somewhat bit-rotted) code to do this - but of
course for the old ABI.

Note that we need a solution that also handles dynamically-loaded
interpreted or (future) jit-compiled classes.

That argues for having gdb reading meta-data from the interior.

> Both solutions require gdb changes: to generate DWARF data at runtime
> requires some changes because gdb is used to reading debug data from
> object files, not from the inferior process.

The Java support in gdb can sort-of do either.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

Per Bothner writes:
 > Andrew Haley wrote:
 > > Bryce pointed out that there is another solution that he favours,
 > > which involves gdb reading libgcj's metadata.
 > 
 > There is already (somewhat bit-rotted) code to do this - but of
 > course for the old ABI.
 > 
 > Note that we need a solution that also handles dynamically-loaded
 > interpreted or (future) jit-compiled classes.
 > 
 > That argues for having gdb reading meta-data from the interior.

Or generating info on the fly; surely either would do.

Andrew.

Re: Binary Compatibility: debug info for compiled Java programs

[Anthony Green]

On Wed, 2004-06-09 at 05:13, Andrew Haley wrote:
> So, I'm still unsure about how to proceed.  It looks like Bryce's
> suggestion is preferable on efficiency grounds, although it might be
> possible to generate DWARF cheaply while laying out classes.

Whatever we do, I'd like to see some solution that attempted to minimize
communication with the inferior process (for remote debugging
purposes).  I also agree with Andrew that it would be bad to do
something preventing us from debugging core files.

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Cagney]

> On Wed, 2004-06-09 at 05:13, Andrew Haley wrote:
> 
>>> So, I'm still unsure about how to proceed.  It looks like Bryce's
>>> suggestion is preferable on efficiency grounds, although it might be
>>> possible to generate DWARF cheaply while laying out classes.
> 
> 
> Whatever we do, I'd like to see some solution that attempted to minimize
> communication with the inferior process (for remote debugging
> purposes).

As an issue, it isn't relevant to this discussion.

Andrew asked me about the overhead of extracting data from the inferior. 
  I sketched out a number of already proposed changes changes, such as 
having the inferior agressively supply memory, that would address the 
problems you mention.

Andrew

Re: Binary Compatibility: debug info for compiled Java programs

[Anthony Green]

On Wed, 2004-06-09 at 14:26, Andrew Cagney wrote:
> > Whatever we do, I'd like to see some solution that attempted to minimize
> > communication with the inferior process (for remote debugging
> > purposes).
> 
> As an issue, it isn't relevant to this discussion.
> 
> Andrew asked me about the overhead of extracting data from the inferior. 
>   I sketched out a number of already proposed changes changes, such as 
> having the inferior agressively supply memory, that would address the 
> problems you mention.

I'm afraid I don't understand what you mean.

AG

-- 
Anthony Green <green@redhat.com>
Red Hat, Inc.

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

Andrew Cagney writes:
 > > On Wed, 2004-06-09 at 05:13, Andrew Haley wrote:
 > > 
 > >>> So, I'm still unsure about how to proceed.  It looks like Bryce's
 > >>> suggestion is preferable on efficiency grounds, although it might be
 > >>> possible to generate DWARF cheaply while laying out classes.
 > > 
 > > Whatever we do, I'd like to see some solution that attempted to minimize
 > > communication with the inferior process (for remote debugging
 > > purposes).
 > 
 > As an issue, it isn't relevant to this discussion.

In either case, whatever we do, we must communicate with the target
system to extract structure info.

 > Andrew asked me about the overhead of extracting data from the inferior. 
 >   I sketched out a number of already proposed changes changes, such as 
 > having the inferior agressively supply memory, that would address the 
 > problems you mention.

Well, kinda sorta.  Anthony is thinking about targets on the end of a wire.

Andrew.

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Cagney]

> Andrew Cagney writes:
>  > > On Wed, 2004-06-09 at 05:13, Andrew Haley wrote:
>  > > 
>  > >>> So, I'm still unsure about how to proceed.  It looks like Bryce's
>  > >>> suggestion is preferable on efficiency grounds, although it might be
>  > >>> possible to generate DWARF cheaply while laying out classes.
>  > > 
>  > > Whatever we do, I'd like to see some solution that attempted to minimize
>  > > communication with the inferior process (for remote debugging
>  > > purposes).
>  > 
>  > As an issue, it isn't relevant to this discussion.
> 
> In either case, whatever we do, we must communicate with the target
> system to extract structure info.
> 
>  > Andrew asked me about the overhead of extracting data from the inferior. 
>  >   I sketched out a number of already proposed changes changes, such as 
>  > having the inferior agressively supply memory, that would address the 
>  > problems you mention.
> 
> Well, kinda sorta.  Anthony is thinking about targets on the end of a wire.

So am I.

Andrew

Re: Binary Compatibility: debug info for compiled Java programs

[Andrew Haley]

Andrew Cagney writes:
 > > Andrew Cagney writes:
 > >  > > On Wed, 2004-06-09 at 05:13, Andrew Haley wrote:
 > > Anthony is thinking about targets on the end of a wire.
 > 
 > So am I.

Good.  It would help if you'd be a little bit less obscure.  Please.  :-)

Andrew.