[fpc-devel] dvarf 3 implementation issue

[Martin Frb]

On 08/05/2014 20:34, Jonas Maebe wrote:
> On 08/05/14 16:10, Martin Frb wrote:
>> Indeed there is a workaround that can be applied, but it would mean
>> extra slowdown, as additional ptype must first be sent to gdb to find
>> out, if it an dynarray = otherdyn.
>
> I understand it's annoying, but I don't see a good solution.
What was wrong with the old pointer to array?

Even if coding in pascal, the fact that dyn arrays are pointers is 
exposed in various situations.


>
>> On the other hand, gdb is not yet dwarf3 ready, and if dwarf3 means that
>> much extra maintenance, I may just not support it via gdb.
>
> Actually, gdb even already supports most of DWARFv4 (and gcc generates 
> it too). variable-length-array support was only merged to gdb 
> master/trunk recently though, which is required for this FPC dynamic 
> array support in the debugging information.
Yes it supports it, but it lacks testing with none gcc generated dwarf.

Well the latest I currently have for testing is 7.6.1, and that still 
crashes on various bits of dwarf by fpc. (including dwarf2, but iirc 
even worse with dwarf3)
Yes, I now, I ought to report them to the gdb bug tracker...

>
>> Well at this time, it is not clear, if it actually would be added to the
>> gdb based version at all, even if all was fixed. It is just keeping an
>> option open.
>>
>> --------
>> What is the advantage for fpc to use DW_AT_data_location for dyn array?
>
> It's to be able to describe dynamic arrays as actual arrays instead of 
> as pointers in the debug information, so that debuggers don't have to 
> know about FPC internals to determine that these pointers are actually 
> arrays and to find out what their length is..

Put they are pointers

- They can be assigned nil
- they can be typecast to pointer or ptrUint  (try that with a static array)
- dynarr1-dynarr2 compares the pointers (again that differs from static 
array, that is not pointer based an behaves different)

So the entire point is, the debugger should know that they are pointers.

Hidding this from the debugger gets wrong results.

And it only means that if you want right results, the debugger now know 
other parts about how fpc dyn arrays really work. I dont see how that is 
better.


> determine that these pointers are actually arrays and to find out what 
> their length is.. 
I do not know about GDB, but from my reading of dwarf 3 the location 
expression (if the deref is taken out), should work with pointer to 
array to.

It actually depends, on what gdb will do with DW_OP_push_object_address 
in a location-expression for the subrange (representing the index).

- The object address should be the array (so the pointer should already 
have been applied.
- But if GDB uses the address before the pointer, then the deref must be 
kept.

It only is a problem if gdb does not implement it at all.

--------------
gdb allows to typecast it as anything.

e.g byte(somedynarray) / which fpc does not (gdb even does that for a 
static array). I ASSUME gdb just takes the address, and reds the new 
type from that address.
So that would explain why at least even with dwarf3, one can typecast 
the array to a pointer.