Archer is a gdb project to improve C++ debugging and otherwise advance gdb ()

Joost van der Sluis | 16 May 2010 19:04

Re: Patch for pascal-dynamic arrays

On Sun, 2010-05-16 at 14:04 +0200, Jonas Maebe wrote:
> On 15 May 2010, at 23:44, Jan Kratochvil wrote:
> 
> > But if the "allocation" is just an internal
> > compiler issue which should be hidden by the same compiler at the DWARF level.
> > Therefore I would guess to use some:
> > 	drop DW_TAG_array_type -> DW_AT_allocated
> > 	DW_TAG_subrange_type -> DW_AT_upper_bound:
> > 		DW_OP_push_object_address
> > 		DW_OP_deref
> > 		DW_OP_dup
> > 		DW_OP_bra allocated
> > 			DW_OP_lit0
> > 			DW_OP_skip end
> > 		allocated:
> > 			DW_OP_lit8
> > 			DW_OP_minus
> > 			DW_OP_deref
> > 		end:
> 
> I agree. Joost, I've attached a patch for FPC's DWARF writer to fix it. I can't test whether it works (the
dumped DWARF info looks ok though), because I can't get gdb/F-13 to build:

It doesn't work.

That's because type_length_get() (gdbtypes.c) does not return 0 when the
high and low-bound are equal to each other. Instead it returns the
element-size. Then allocate_value_lazy tries to read element-size bytes
from the base-address (being 0x0) -> av.

(Continue reading)

headers

Jan Kratochvil | 16 May 2010 19:23

Re: Patch for pascal-dynamic arrays

On Sun, 16 May 2010 19:04:27 +0200, Joost van der Sluis wrote:
> That's because type_length_get() (gdbtypes.c) does not return 0 when the
> high and low-bound are equal to each other.

That's correct.  Both DW_AT_lower_bound and DW_AT_upper_bound express the
boundaries inclusively.  Array of length 0 must have DW_AT_upper_bound equal
to DW_AT_lower_bound minus one.

If you do not feel confortable with DW_AT_upper_bound that way you can also
use DW_AT_lower_bound and DW_AT_count with value 0.

> There's also a second problem. The lower bound is 1 for strings. With
> Jonas' patch for fpc the upper bound of strings is 0 when not allocated.

That looks correct.

> Leading to a size of -1.

That should lead to a size of 0.

I am not sure where is a problem there but GDB handles non-pascal arrays of
length zero right AFAIK.

Thanks,
Jan

headers

Jonas Maebe | 16 May 2010 23:49

Re: Patch for pascal-dynamic arrays

On 16 May 2010, at 19:23, Jan Kratochvil wrote:

> That's correct.  Both DW_AT_lower_bound and DW_AT_upper_bound express the
> boundaries inclusively.  Array of length 0 must have DW_AT_upper_bound equal
> to DW_AT_lower_bound minus one.

I've fixed this, thanks. I've also committed the patch to FPC svn.

> I am not sure where is a problem there but GDB handles non-pascal arrays of
> length zero right AFAIK.

Thanks to your patch, I can now successfully build the new gdb on SL54. In Pascal language mode, both empty
arrays and strings are printed as '0x0'. That's probably an issue in the Pascal value printer. In C
language mode (with the same binary), an empty string is (correctly) printed as '0x625418 ""', while an
empty array is printed as just the address of the variable containing the pointer to the array (which looks
a bit strange, but I guess it's consistent with how in C arrays and pointers are pretty much the same).

Array:

19	  setlength(a,8);
(gdb) set lang pascal
(gdb) ptype a
type = array [0..-1] of LongInt
(gdb) p a
$12 = 0x0
(gdb) set lang c
(gdb) ptype a
type = LongInt [0]
(gdb) p a

(Continue reading)

headers

Jonas Maebe | 16 May 2010 23:54

Re: Patch for pascal-dynamic arrays

On 16 May 2010, at 23:49, Jonas Maebe wrote:

> (gdb) ptype s
> type = array [1..8] of Char
> (gdb) p s
> $18 = #0#0#0#0#0#0#0
> (gdb) set lang c
> (gdb) ptype s
> type = Char [8]
> (gdb) p s
> $19 = "\000\000\000\000\000\000\000"

Actually, it seems one element too few is printed here (at least in Pascal mode, where strings are not
null-terminated): only 7 instead of 8 characters are shown in both Pascal and C mode.

Jonas