I have encountered a problem using GDB (6.4.90-debian) with FPC (2.0.4 or 2.1.4). In a nutshell, GDB sometimes barfs on FPC generated stabs.

If the program is compiled with -g (stabs format) the debugger works but attempts to print some data structures or produce a back-trace can result in a SEGV in GDB (ie, GDB itself crashes).

If the program is compiled with -gd (DBX format) or -gw (dwarf) GDB works correctly without crashing but reference to source files that are in directories other than the current directory have a (relative) path prepended to the name which breaks other things (notably the emacs/GUD and Lazarus front ends).

By way of example, with GDB run in the (project home) directory

/home/bruce/vc/

with dwarf symbols GDB reports:

(gdb) info source
Current source file is src//Widget.pas
Compilation directory is 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.

When the program is compiled with stabs I get:

(gdb) info source
Current source file is Widget.pas
Compilation directory is src/
Located in /home/bruce/vc/src/Widget.pas
Contains 637 lines.
Source language is pascal.
Compiled with stabs debugging format.
Does not include preprocessor macro info.

which is correct (but GDB is otherwise unusable due the stabs problem).

My (2) questions are:

[1] has anyone else seen the GDB crashing problem when a program is compiled with stabs info?

[2] is the filename problem with dwarf encoded symbols an FPC bug or is there some configuration I'm missing somehere.

Note that in all cases I've compiled the program (which is a port of a a working Delphi application) with no optimizations or other bells and whistles enabled.

Many thanks for any advice about what I might be doing wrong.

Otherwise consider this a bug report :-)

Cheers, Bruce Tulloch.

Bruce Tulloch wrote

I have encountered a problem using GDB (6.4.90-debian) with FPC (2.0.4 or 2.1.4). In a nutshell, GDB sometimes barfs on FPC generated stabs.

That is a quite old gdb version. I would recommend at least gdb 6.5, and preferably gdb 6.6.

If the program is compiled with -g (stabs format) the debugger works but attempts to print some data structures or produce a back-trace can result in a SEGV in GDB (ie, GDB itself crashes).

Sounds like a bug in the gdb version you are using.

That's gdb which is doing that. We do not say in the debug information that the source file is called "src//Widget.pas"; we set the compilation dir to ./src/ and the file name to Widget.pas, just like when generating stabs.

In fact, it appears this bug is not present in Apple's fork of gdb. It is present in gdb 6.5-15.fc6rh (on Fedora Core 6) though.

[1] has anyone else seen the GDB crashing problem when a program is compiled with stabs info?

I haven't, but as I said you're using a really old version of gdb.

[2] is the filename problem with dwarf encoded symbols an FPC bug or is there some configuration I'm missing somehere.

It's a gdb bug.

Jonas

Thanks for the feedback Jonas.

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 and it still produces bad filenames when dwarf symbols are used instead of stabs.

With reference to the latter problem, I'm porting a (former Delphi) project with Lazarus (SVN) and FPC (2.1.4). For units that are in the same directory as the .lpr file, the dwarf reported filenames are correct.

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.

Is there something else you can suggest I try? At this point is looks like FPC is either generating incorrect names in the dwarf encoded symbolic data or something else is preventing gdb (6.6) from reading it correctly.

Is there another tool I can use than gdb to dump the dwarf data from the object?

Any clues much appreciated and let me know if there is other information I might be able to provide which helps get to the bottom of this.

Cheers, Bruce.

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.

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

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.

I'm aware of 1 issue that crashes GDB. That issue is related to printing huge arrays. Printing or indexing an array declared with 'array[0..high(longint)] of byte' will crash GDB, because it tries to allocate that much memory which is not available.

For the rest GDB with stabs is stable and used everyday in development of FPC and Lazarus.

Peter

There was actually a bug in our compiler: for source files not in the current directory, we set the "current compiler directory" to the location of the source file, but at the same time also specified that those source files were located in an "include directory" (which is a relative path from the cwd when you started the compilation).

I've fixed this now in svn. It won't be in 2.2.0 though, since that one will be released somewhere during the next couple of days.

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).

The two major semantical differences between FPC and Delphi I'm aware of are described at
http://wiki.freepascal.org/index.php?
title=Code_Conversion_Guide#Semantical_differences

Another issue is that uninitialized variables often have different values when the program is compiled with FPC rather than with Delphi, but that's not really FPC-specific. You can use -gt till -gttt in FPC to initialise all (non-refcounted) local variables, function results and out parameter with garbage (or with 0/nil in case of -gtttt, but that's not really recommended since it's more likely to hide than help find errors), to more easily track these down.

I'll send an example project if/when I can create one.

Thanks.

Jonas

Thanks Jonas, we will checkout the latest SVN version and let you know.

Apropos conversion from Delphi, we've grokked most of what's in the Lazarus Wiki and our code does not rely on Delphi's default variable initializations. Indeed we have been impressed at how well FPC has been able to emulate what Delphi does (with $MODE DELPHI enabled).

Most of the bugs and problems we've encountered so far are related to the use of with statements (used extensively in this codebase) and the subtle namespace resolution differences between Delphi and FPC. This application also makes extensive use of the TFrame class which if one takes care to manually create the .lrs files do in fact work in LCL despite the dislaimers everywhere that it doesn't :-). Of course we cannot edit TFrame resources with lazarus and I presume that the IDE is where most of the remaining work is required to support TFrame.

Most of the remaining problems relate to the widget set implementation (we're using GTK1 but would like to use GTK2), especially where fonts are concerned as well as some apparent glitches in LCL's TCanvas and some other visual components when they render to the screen.

We will try and put together an toy project that demonstrates the stabs problem. Peter Vreman pointed out the classic GDB heap problem and the issue here may be related. The crash occurs when printing a decendant of TComponent (TMyClass) when GDB attempts to show a field of TMyClass which is itself a decendant of TMyClass. The declaration of this field (and its related property) in the source is therefore necessarily made by forward reference and this raises our suspicions.

Thanks again, Bruce.

Bruce Tulloch wrote

Most of the bugs and problems we've encountered so far are related to the use of with statements (used extensively in this codebase) and the subtle namespace resolution differences between Delphi and FPC.

Please report bugs about this! http://www.freepascal.org/mantis . Some may not be fixed because considered bugs in or too confusing behaviour by Delphi, but most probably will be fixed, even if only in Delphi mode.

I already fixed a lot of with-related bugs since 2.0.4 (mostly related to "class of" reference types), but there may be more left.

Most of the remaining problems relate to the widget set implementation (we're using GTK1 but would like to use GTK2), especially where fonts are concerned as well as some apparent glitches in LCL's TCanvas and some other visual components when they render to the screen.

Ditto.

Jonas

In attempting to check the resolution of the GDB/DWARF issue reported earlier, we've encountered a new (apparent) FPC bug.

FPC 2.3.1 (SVN 8427) is producing this new compilation error:

"Error: Can't take the address of constant expressions"

when attempting to compile a line:

  EOF(MyFile);

where MyFile is a property of a class defined thus:

  TMyClass = class(TAnotherClass)
   private
     FFile : TextFile;
   protected
     property MyFile : TextFile read FFile;
   public
     ::
     ::
   end;

FPC 2.1.4, Delphi6 and Kylix3 don't complain.

Replacing MyFile with FFile work OK (but is not what we want for other reasons).

Is this a new bug or a new definition of how properties may be handled with EOF?

Cheers, Bruce.

Since moving to FPC 2.1.4 we noticed a lot of the with-related bugs went away. We're now working with FPC 2.3.1 from SVN and we'll report any bugs we find. Same for the Lazarus/LCL/GTK issues etc.

Thanks and well done to all to get 2.2 out the door :-)

Cheers, Bruce.

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).

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.

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 hope this helps. We will feedback more as we discover stuff.

Cheers, Bruce.

Hi Jonas,

Unfortunately GDB (6.6) still barfs on FPC (SVN 8427) generated stabs sometimes when performing a backtrace or printing certain objects in our application. As mentioned earlier, we'll do what we can to abstract the problem into the small demonstration program we can send you. For the time being we'll use DWARF2 as despite some remaining problems with that (reported in another email) it does not crash GDB.

Cheers, Bruce.

I should note here that the strange anomalies I reported below do not occur when using stabs instead of dwarf2.

That is, gdb knows the language is pascal regardless of the source file location and it never shows the file name with any path prepended. Stabs data also mangles the method symbol names to show their classes whereas dwarf2 does not (indeed dwarf2 knows nothing about classes in gdb).

Cheers, Bruce.

Dwarf support in GDB was/is very minimalistic. You can try to compile with -gw3 to enable the full dwarf 3 specs, but the last time I tried GDB didn't understand it.

Somehow it doesnt surprise me.

Marc

Bruce Tulloch wrote on di, 11 sep 2007:

FPC 2.1.4 doesn't complain because it's buggy: it allows you to pass properties to var parameters. I don't understand why Delphi/Kylix don't complain, because they also do not allow passing properties to var parameters (at least not in my tests) and I don't see how you could implement Eof() without a var parameter.

Jonas

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

Bruce Tulloch wrote on di, 11 sep 2007:

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.

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".

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

Jonas

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

Bruce Tulloch wrote on di, 11 sep 2007:

That is, gdb knows the language is pascal regardless of the source file location and it never shows the file name with any path prepended. Stabs data also mangles the method symbol names to show their classes whereas dwarf2 does not (indeed dwarf2 knows nothing about classes in gdb).

That's the (only) other gdb/Dwarf bug for which I've submitted a patch and which has been fixed in gdb cvs since their 6.6 release :)

Jonas

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

I've managed to distill this problem into a trivial Lazarus project.

Unpack the tarball, and build this project as .compiled indicates.

Run it under gdb 6.6 with a break-point placed as commented.

Try and step into TChild.Create at this point - gdb SEGV.

Rebuild with DWARF2 and it run without crashing gdb.

At least that's what I'm seeing here (Debian Etch, FPC SVN 8427, GDB 6.6).

I hope this helps. I will try and isolate it further.

Cheers, Bruce.

> > FPC 2.1.4, Delphi6 and Kylix3 don't complain.

FAIK, Delphi does not like Properties as var parameters.

-Michael

This seems to be a bug in the binary writer. Recompile all your sources with "-Aas" as a workaround.

Jonas

Michael Schnell wrote

>> >> FPC 2.1.4, Delphi6 and Kylix3 don't complain. FAIK, Delphi does not like Properties as var parameters.

Agreed, this makes sense. However the codebase I'm porting passes properties to EOF all over the place and this has compiled and run in Delphi6 and Kylix3 for some years.

It worked in FPC too, until I moved to 2.3.1.

Presumably this suggests Borland cut some corners with the validity of properties as var arguments or took some liberty with the definition of EOF or the Text/TextFile types.

Checking Kylix I've found that that unless the property of type TextFile is defined as a direct reference to a field of type TextFile, Kylix barfs. Indeed Kylix reports that TextFile is an "Invalid function result type" if one tries to return one via a property access method.

So, it would seem this is suspect in Borland's implementation and I will fix our code to avoid passing properties as var parameters everywhere I come across it in the ported code.

I agree it's not (should not) be a valid thing to do!

Thanks for the feedback.

Cheers, Bruce.

Marc Weustink wrote

Dwarf support in GDB was/is very minimalistic. You can try to compile with -gw3 to enable the full dwarf 3 specs, but the last time I tried GDB didn't understand it.

Nope, you're right, GDB 6.6 does not work with this know what other debugger options are available that do work with -gw3 (preferably Debian Etch or Lenny and compatible with Emacs/GUD)?

Bruce

I've refined the definition of this problem and attach an updated toy project that demonstrates it reliably.

I've also found some apparently simple ways to avoid it.

See the testbutton.pas file for full details.

To me it looks very much like a there is something very subtle but still wrong with with FPC 2.3.1 SVN 8427 STAB debug data.

Both gdb 6.6 and objdump 2.17 complain about it.

Apparently in 99% of cases the consequences are benign.

Unfortunately in my case it isn't but it does appear I can work around it by swapping the order of two lines of code (see testbutton.pas).

Note that in no event does this problem ever appear to effect the execution of the application itself; the FPC generated executable does appear be always correct.

It is simply an issue of the generated STAB debug data.

Bruce.

However the codebase I'm porting passes properties to EOF all over the place

What do you think a property as a var parameter is supposed to do ?

Theoretically a write to the property _could_ be compiled into a call to the set method. But with that the called function would need code to detect if the var parameter is a property and act accordingly. Though a nice feature, IMHO it would make things so complicated that it does not make much sense.

I suppose (part of) the difference is not that passing properties as vars was allowed but that the public value in question a not a property but a class variable (that _does_ have an address to be passed when doing "var").

-Michael

It doesn't have to detect, the compiler would generate a temp like:

init(temp);
get(temp);
func(temp);
set(temp);
destroy(temp);

Micha

Apart from being pretty slow, this also has different semantics than a var parameter. Suppose you modify the var parameter in the callee, and then call another method of the original class instance from the callee -> this method will see the original value of the field/ property rather than the modified "var" parameter.

Jonas

there should not be a temp as the object referenced needs to be modified using it's "set" method "on the fly" i.e. a second reference to that object within the called procedure needs to reflect the changes made in the instruction just executed. Everything else would be very ambiguous.

-Michael

example

type
  Tx = class,,
    fz: integer;
    ..
    procedure sety(value: integer);
    ...
    property y: integer write sety
    property z: integer read fz write fz
  end;
var
  x: tx
function  sub (var i: integer): integer;
begin
  i := 4;
  Result := x.z;
end;
procedure Tx. sety(value: integer);
begin
  fz := value;
end;
procedure main;
begin
  x := Tx.create;
  test := sub(x.y);
end;

Ah, aliasing problem, indeed.

Micha