[fpc-devel] GDB barfs on FPC generated stabs.

[Bruce Tulloch]

The dwarf problem appears to be GDB (configuration?) related.

For a source file not in the working directory I get the same type
of information as you from readelf, eg:

 <0><7ec44>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_name        : Widget.pas	
     DW_AT_producer    : Free Pascal 2.1.4 2007/05/07	
     DW_AT_comp_dir    : /home/bruce/vc/src/
     DW_AT_language    : 9	(ANSI Pascal)
     DW_AT_identifier_case: 3	(case_insensitive)
     DW_AT_stmt_list   : 0x153dd	
     DW_AT_low_pc      : 0x823f860	
     DW_AT_high_pc     : 0x8242ca0	

whereas for a file that *is* in the working directory I get:

 <0><46656>: Abbrev Number: 1 (DW_TAG_compile_unit)
     DW_AT_name        : Main.pas	
     DW_AT_producer    : Free Pascal 2.1.4 2007/05/07	
     DW_AT_comp_dir    : 	
     DW_AT_language    : 9	(ANSI Pascal)
     DW_AT_identifier_case: 3	(case_insensitive)
     DW_AT_stmt_list   : 0xd1da	
     DW_AT_low_pc      : 0x809cd20	
     DW_AT_high_pc     : 0x809e4e4	

ie, the DW_AT_comp_dir field is nil. It appears as if GDB mangles the
name of the file if DW_AT_comp_dir is specified by prepending the
difference between the full path and working directory to the reported
file name. Based on your feedback it seems to do this in linux (Fedora
in your case, Debian in mine) but not in Apple's fork of gdb.

As for the stabs/crash problem, I've tried creating a few small test
projects to reproduce it but so far have succeeded only with the very
large application we're porting (which while it runs fine with Delphi
has numerous other unrelated bugs from FPC's point of view).
I'll send an example project if/when I can create one.

Thanks, Bruce.

Jonas Maebe wrote:
> 
> On 09 Sep 2007, at 13:36, Bruce Tulloch wrote:
> 
>> I've since downloaded and built gdb 6.6 and both problems remain the same
>> so I don't think it's gdb per se. This latest GDB version still
>> produces a
>> SEGV on stabs symbols from time to time
> 
> A segfault in gdb is a bug in gdb regardless of whether our debug
> information contains an error or not, but it may of course point at an
> error in our debug info. We'll need a compilable example and
> instructions on how to reproduce it before we can fix it though.
> 
>> However for units that are in a directory specified via an -Fu
>> argument the
>> names are corrupted as I described before. Eg, -Fusrc/ produces a
>> filename
>> for the "Widget" unit as "src//Widget.pas" instead of just
>> "Widget.pas". In
>> the case of stabs the filename is reported correctly regardless of where
>> the unit is located.
> 
> We really do not add any extra directory to the file name, I checked it
> in the generated assembler code.
> 
>> Is there another tool I can use than gdb to dump the dwarf data from the
>> object?
> 
> readelf -w program
> 
> Example:
> 
> <0><5d>: Abbrev Number: 1 (DW_TAG_compile_unit)
>      DW_AT_name        : un.pp
>      DW_AT_producer    : Free Pascal 2.3.1 2007/08/28
>      DW_AT_comp_dir    : ./udir
> 
> Still, gdb (6.5 under Fedora) also says:
> 
> (gdb) info source
> Current source file is ./udir//un.pp
> Compilation directory is ./udir
> Located in /user/jmaebe/lnxhome/fpc/test/udir/un.pp
> 
> 
> Jonas
> 
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>