Re: [RFA]: Java Inferior Call Take 2

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jun 17, 2004 at 04:52:36PM -0400, Jeff Johnston wrote:
> Daniel Jacobowitz wrote:
> >On Mon, May 17, 2004 at 04:53:32PM -0400, Jeff Johnston wrote:
> >
> >>This is the reworked java inferior call patch.  My previous attempt tried 
> >>to modify the gdb v3 abi code to handle missing debug information from 
> >>gcj. After a couple of gcc patches from Andrew Haley, the gnu-v3-abi.c 
> >>code doesn't require any tampering.
> >>
> >>I had to enhance dwarf2read.c to handle the java vtable name (which is 
> >>vtable) and to modify C++-only code to handle java syntax for class names.
> >>
> >>I have included a test case.
> >>
> >>Ok to commit?
> >
> >
> >First of all, it doesn't work for me; I'm guessing that's because I
> >have gcj 3.3 installed.  Are the GCC changes in any released version of
> >GCC yet, so that I can add appropriately versioned XFAILs?
> >
> 
> I am using current gcc sources because Andrew Haley only recently added the 
> fixes.  It has to be post 3.4.0 which is the last release but prior to 
> Andrew's patches.

Are you actually using GCC HEAD?  Gcj does not even emit debug info for
the local variable "x" in jprint.main using today's CVS.

> >>	* valarith.c (value_subscript): Treat an array with upper-bound
> >>	of -1 as unknown size.
> >
> >
> >I still don't understand why this change is necessary, i.e. why
> >providing a large upper bound causes the whole memory region to be
> >loaded from the inferior.  That should not happen.
> >
> >
> 
> The change "is" needed or the warning gets issued in value_subscript.  C 
> and C++ get away with it because of c_style_arrays.
> 
> The other solution is to change the range of the virtual_functions array to 
> have a large value for an upperbound, but that requires a change to 
> gnu-v3-abi.c which "you asked me not to change".

I wrote:
  If you make the debug readers recognize this as the vtable for Java
  symbols, then the existing machinery should work, without having to
  do all this grubbing around in the v3 ABI code.

That's "these changes should not be necessary", not "keep your hands
off this file"!  In any case:

> Changing the -1 above to INT_MAX/4 results in a virtual memory exhausted 
> error when making a virtual function call.  Backtracing, we see:

> #4  0x080dcd2d in allocate_value (type=0x8358b48)
>     at 
>     /home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/values.c:86
> #5  0x080e4938 in value_at_lazy (type=0x8358b48, addr=134521984, sect=0x0)
>     at 
>     /home/jjohnstn/gdb-patches/inf-call-java-may12-2004/src/gdb/valops.c:485

The answer to my earlier question is that lazy values read from the
target lazily, but allocate memory eagerly.  So using a large upper
bound won't work.  The -1 is OK, I think.

> >Other changes have been made to gcj's debug output in order for this to
> >work; wouldn't this be a good time to fix the above?  No one's given a
> >reason that I recall for GCJ to abuse DW_AT_name in this fashion.
> >
> 
> Perhaps, but perfection is always an on-going goal.  IMO, this isn't worth 
> holding up the patch while we discuss this with gcc.  The code certainly is 
> not a problem for anybody to maintain and I am perfectly willing to put a 
> FIXME note for the time-being.

I would prefer this be fixed before the code is included; every hack we
add to accept invalid debug information is a maintenance burden.  I was
going to attach a GCC patch to this message, but I can't find a gcj
that "works" for purposes of this test case to base my changes on.

java@ folks:
  - the testcase that I'm not getting local variables from is at
      http://sources.redhat.com/ml/gdb-patches/2004-05/msg00509.html
    Tree-ssa has been merged since Jeff first posted that patch, so
    that's probably what broke it.
  - Is there any reason to hold on to the DW_AT_name values, which
    currently look like "jprint.main(java.lang.String[])" instead of
    "main" as DWARF would normally suggest?

-- 
Daniel Jacobowitz