Re: [fpc-devel] Dwarf-3

2016-01-24 Thread Martin Schreiber 
On Sunday 24 January 2016 17:17:57 Martin wrote:
> On 24/01/2016 16:03, Florian Klämpfl wrote:
> > Dwarf-3 can handle dyn. arrays much better. What do you think about
> > switching the default dwarf level from 2 to 3?
>
> The last gdb I tested on win (32bit vista) was gdb 10.0  (current is 10.1)
>
> And (IIRC) it still crashes (gdb exe has stopped working) with dwarf3.
>
Confirmed with Linux x64 gdb 7.9.1. gdb with  FPC -gw3 crashes by many watches 
("self",arrays,pointers...) and does not find uppercase queries for lowercase 
variables so the workaround for class variables can not be used. It is 
completely unusable for IDE purpose.

Martin
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Dwarf-3

2016-01-24 Thread Martin 

On 24/01/2016 16:03, Florian Klämpfl wrote:


Dwarf-3 can handle dyn. arrays much better. What do you think about switching 
the default dwarf
level from 2 to 3?



The last gdb I tested on win (32bit vista) was gdb 10.0  (current is 10.1)

And (IIRC) it still crashes (gdb exe has stopped working) with dwarf3.

This is when I run a great lot of queries on it, using the test case I 
have for the lazarus debug integration.



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Dwarf-3 (was: Debuginfo for dynamic arrays)

2016-01-24 Thread Florian Klämpfl 
Am 24.01.2016 um 15:20 schrieb Martin:
> On 24/01/2016 14:06, Martin Schreiber wrote:
>> Hi,
>> For a "array of integer" type variable FPC 32bit stabs returns for gdb 
>> "ptype"
>> command
>> "
>> type = ^(array [0..-1] of LONGINT)
>> ".
>> MSEide uses this info to fetch the itemcount and item memory and to show the
>> array  items in watches window.
>> FPC 64bit dwarf "ptype" returns
>> "
>> type = ^LONGINT
>> ".
>> How can we identify a dynamic array with FPC dwarf?
>>
> 
> If I remember correctly then you can do (after you got above result)
>ptype foo^
> or if foo is an expression ptype (foo)^
> and this will return an array as ptype.
> 

Dwarf-3 can handle dyn. arrays much better. What do you think about switching 
the default dwarf
level from 2 to 3?

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] dwarf 3 implementation issue

2014-05-09 Thread Martin Frb 

On 08/05/2014 21:11, Martin Frb wrote:


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

Hidding this from the debugger gets wrong results.


Besides that GDB fails on those anyway (at least the gdb I have). Here 
is another one, that does not (and can not) work with the current 
expression location in gw3


program dyarr;
type
 TX=array of integer;
var
  a: TX;
  p: PtrUint;
begin
  SetLength(a,3);
  a[0] :=  1; a[1] :=  2; a[2] :=  3;
  p := ptruint(a)-4;
  writeln( TX(p+4)[1] ); //writes 2
end.

-data-evaluate-expression TX(p+4)

DW_AT_data_location starts with DW_OP_push_object_address

It needs the address of the variable. But "p+4" has no address.

A debugger could still use it as a pointer, so the dwarf 2 definition 
could work (as I said, I got trash in gdb with either dwarf / but the 
problems of gdb are not the point)


The new dwarf3 does simple not describe the type dyn-array

yet, if the type was pointer to array, then the important location 
expression for the array upper bound could still be added to the 
subrange definition. It would use a DW_OP_push_object_address too, but 
that would then refer to the array after the pointer was already 
resolved (at least it should)



___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel