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

[Bruce Tulloch]

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.

Jonas Maebe wrote:
> 
> On 09 Sep 2007, at 14:49, Bruce Tulloch wrote:
> 
>> 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.
> 
> 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
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>