Re: debugging custom array types

[Tom Tromey <tromey@redhat.com>]

>>>>> "Michael" == Michael Haupt <michael.haupt@oracle.com> writes:

Michael> OK. Is it safe to assume that the VLA work Jan keeps mentioning on
Michael> this thread will eventually make it into gdb "proper" (or FSF gdb or
Michael> whatever the correct name is)? Is there an idea of how long it might
Michael> take?

It will go in eventually, but probably in a different form.
I don't know how long it will take.  It really needs a rewrite.

It may help with the problem you are facing, but it won't solve it.
That's because the jv-* code in gdb will still be wrong.  There's no way
to avoid fixing this, unless you want to have arrays that are laid out
exactly the same way that gcj does it.

For example, see the BINOP_SUBSCRIPT case in
jv-lang.c:evaluate_subexp_java.  This is the code that handles
expressions like "x[5]":

	  address = value_as_address (arg1);
	  address += get_java_object_header_size (exp->gdbarch);
	  read_memory (address, buf4, 4);
	  length = (long) extract_signed_integer (buf4, 4, byte_order);
	  index = (long) value_as_long (arg2);
[...]
	  address = (address + 4) + index * TYPE_LENGTH (el_type);

This is all pretty bogus; as you can see it pretty much directly knows
about array class layout.  Gross.

I think this code is actually broken right now.  At least, a simple test
made it seem like array subscripting just doesn't work even for gcj any
more.

Tom