[fpc-devel] FPC SVN 8427 : GDB/DWARF2 issues

[Jonas Maebe]

Bruce Tulloch wrote on di, 11 sep 2007:

> I can confirm that this appears fixed, though still a little strange.
>
> To explain...
>
> Using FPC 2.3.1 SVN 8427 and GDB 6.6 and building with -gw/-gl we have:
>
>   (gdb) info source
>   Current source file is /home/bruce/vc/src//Widget.pas
>   Compilation directory is /home/bruce/vc/src/
>   Located in /home/bruce/vc/src/Widget.pas
>   Contains 637 lines.
>   Source language is pascal.
>   Compiled with unknown debugging format.
>   Does not include preprocessor macro info.
>
> The difference appears to be that all references to directories are now
> absolute, not relative and Emacs/GUD (at least) works happily with GDB.
>
> The first strange thing to notice is that the current source file still
> has a path prepended (as reported by GDB) if the source file is not in
> the working directory (ie, the "/home/bruce/vc/src//" shown above).

That's normal, because of Dwarf's distinction between the "current  
compilation directory" and "include directories relative to the  
current compilation directory". Stabs has no such distinction, afaik.

> The second strange thing is that gdb's "info source" reports
>
>   Source language is minimal.
>   Compiled with DWARF 2 debugging format.
>   Does not include preprocessor macro info.
>
> when viewing source which is in the current working directory but:
>
>   Source language is pascal.
>   Compiled with unknown debugging format.
>   Does not include preprocessor macro info.
>
> when viewing source which is located elsewhere. It seems gdb understands
> that it's reading DWARF2 but not that the language is pascal if the file
> is in the working directory and vice versa if the file is elsewhere.

gdb 6.6 ignores the Pascal language specifier in the Dwarf-2 info. I  
don't know why it works when the file is in a different directory, as  
it always ignores it. I've submitted a patch which has since then been  
applied in gdb cvs.

You can work around it by using "set lang pascal".

> So far these issues appear benign for our purposes here, but presumably
> they indicate something is still amiss?
>
> Another clue may be complaints by readelf -wl which reports:
>
> "Warning: The line info appears to be corrupt - the section is too small"

I can reproduce this, I'll have a look.


Jonas

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.