Hi,

I noticed that in the linking tab, generating line info (-gl) is now coupled with Generate debugging info for gdb (-g) and this defaults to dwarf with sets.

Now when my app raises an exception I only get stack traces in this form: C:\Users\Bart\LazarusProjecten\bugs\SynEdit>se
TApplication.HandleException Stupid exception
Stack trace:
$004222D0 line 36 of main.pp
$004E4F03 line 2286 of include/control.inc
$004F960F line 62 of include/buttoncontrol.inc
$004F9ADF line 174 of include/buttons.inc
$004FA001 line 339 of include/buttons.inc
$004F952A line 26 of include/buttoncontrol.inc
$0040ADBA
$004DAED2 line 5243 of include/wincontrol.inc
$0051B251 line 111 of lclmessageglue.pas
$004BF780 line 2407 of win32/win32callback.inc
$0051E198 line 375 of win32/win32wsforms.pp
$767D62FA
$767D6D3A
$767D965E
$767D96C5
$73884601
$73884663

In the past (when only using -gl in the linking tab) this looked something like this:

C:\Users\Bart\LazarusProjecten\bugs\SynEdit>se
TApplication.HandleException Stupid exception
Stack trace:
$004222D0 TFORM1__BUTTON1CLICK, line 36 of main.pp $004E4F03 TCONTROL__CLICK, line 2286 of include/control.inc $004F960F TBUTTONCONTRL__CLICK, line 62 of include/buttoncontrol.inc $004F9ADF TCUSTOMBUTTON__CLICK, line 174 of include/buttons.inc $004FA001 TBUTTON__CLICK, line 339 of include/buttons.inc $004F952A TBUTTONCONTROL__WMDEAFAULTCLICKED line 26 of include/buttoncontrol.inc
$0040ADBA
$004DAED2 TWINCONTRL__WNDPROC, line 5243 of include/wincontrol.inc $0051B251 DELIVERMESSAGE, line 111 of lclmessageglue.pas $004BF780 WINDOWPROC, line 2407 of win32/win32callback.inc $0051E198 line 375 of win32/win32wsforms.pp
$767D62FA

This form of stacktrace makes debugging so much easier then the one I am getting now.

How can I get my stacktraces back to the style it was before?

(Lazarus 0.9.31 r32422 FPC 2.4.4 i386-win32-win32/win64)

2011/9/19 Bart :

How can I get my stacktraces back to the style it was before?

Use Stabs debugging info. I think it is default for Win32.

You can always select any debug format you want.

I had recent conversations on the fpc-devel list, and obtained the following info from Jonas:

Any command-line switch starting with -g always includes "-g" the exception is -g- or any -g-xxx

-gl therefore always includes, and included -g
-gl triggers the inclusion of the lineinfo unit (or infodwrf), which can only work with debug info (stabs or dwarf)

Also according to Jonas (and fpc.exe -h) "-g" creates the "fpc default" debug info, which may or may not be stabs.

So using only -gl in old lazarus, was equal to "-g -gl" which would have created stabs or dwarf, depending on what fpc thought to be right.

----
This fact, that -gl includes -g is no more evident in the lazarus settings. And that is the only thing that changed (and it will change for other settings -gv -gh too)

Just set the debug info to stabs, and you should be fine.

BTW => dop you now the package "leak info" ?

It creates an entry in the tool menu.
And while originally for leak traces, it works with all stacktraces. (or at least it works with dwarf traces,, that is what I use)

You can either load a trace from file, or paste from clipboard, then you can simply click the lines, and it navigates you to the right source file (in some cases it may not find fpc units)

2011/9/19 Martin :

-gl therefore always includes, and included -g

Before, on Win32 Stabs was default with "-g -gl" (at least with FPC 2.4.4) and now with "Automatic" Lazarus forces "-gw2 -godwarfsets". I know I can change but can it by default pass simply "-g" when "Automatic" is chosen? So that FPC chooses which debug info to include, not Lazarus.

The whole idea is, that using Lazarus as an ide, the user actually gets to see what is used...

Otherwise, if users have problems, and are asked to tell what they use, the don't know.
and there are no docs or other methods to tell what info fpc uses by default, on platform xyz (not to speak to need to know the fpc version ...)

So being able to tell what the default is, is full intention.

Also according to testing I have done, using the version of GDB included in lazarus => so doing what the average user would do, it appears that dwarf is delivering better results. (e.g, (IIRC) properties that map to fields are inspectable, if using dwarf => so promoting dwarf, will reduce the amount of problems that new users have) There may of course be exceptions to that. Thats why there is a choice.

Out of curiosity:
- Why do you prefer stabs?
- Why do you prefer stabs generated by -g, rather than choosing explicitly?

You can always select any debug format you want.

Why has Lazarus changed the default debug format to dwarf on windows? Lnfodwrf is doing a poor job of looking up symbols (it only looks for line information) and it crashes under certain circumstances. See http://bugs.freepascal.org/view.php?id=20296.
I understand dwarf is the future and stabs dying a slow death. But currently the dwarf has still to learn walking and stabs is still a fit senior.

Ludo

2011/9/19 Martin :

I see your point.

- Why do you prefer stabs?

Because I always had problems with DWARF, at least on Win32. I have GDB 7.3.2 from MinGW. STABS seems to work better. There is problem with stacktrace, like Bart posted. I cannot cast pointers, variables to PChar, PByte, PByteArray, which I use often to look at the bytes. For example try to do:

"pbytearray(form1.fcaption)^"
"pchar(form1.fcaption)^"
"pbyte(pointer(0x5238a4))^"

For example I want to display reference count of string:

"plongint(form1.fcaption)[-2]"

Doesn't work with DWARF.

- Why do you prefer stabs generated by -g, rather than choosing explicitly?

I thought -g always chooses the best supported debug info for the platform. I thought it chooses Stabs not Dwarf since it works better. Maybe that is not the case.

Otherwise there's no problem. I figured out I can set Stabs in default options for new project.

First of all it, you're case is special, it is the only one that actually performed the upgrade.
The following rules are used:
* If the old config had:
- "debug info -g" enbled
- "dwarf -gw" disabled
then (never mind the state of -gl -gh -gv ...) the new config has "debug enabled, using stabs", and kept all other options as they where

The above settings (in the old config) are assumed the user wanted explicitly stabs (even so, they have a same likely hood that the user just clicked the first options, and had no idea what the "dwarf" otpion even means...)

* if the old config had none of the flags => then so does the new

I if the old config had
- "debug info -g" enbled
- "dwarf -gw" enabled (or any other -g### enabled) then the new config defaults to dwarf.

so having set only -gl triggered the last setting.

As explained only -gl does not exist, it triggers some debug info anyway => it was assumed that the user may not have understood that, and therefore it gets corrected to the recommended new settings.

Of course, it is possible, that an expert user, who understood that fpc would include the -g for a -gl, had set -gl only (saving the time of checking a 2nd options) => but an expert user should easily be able to correct this.

--------------
Also see my other mail: dwarf will solve some of the issues that new users (and old users too often complain abut). It does make some (only some, but at least that) of the properties inspectable.

I admit, the fact that people would include debug info for the purpose of stacktraces on stderr only (and not to use gdb), never came to mind. Yet, even if there would not have been a reason: except for the recent bug in infodwrf (which hopefully will get fixed) I never thought there was an important difference for stacktraces. Of course, I have never attempted to read them myself => I do use them (very frequently) but I always import them into "leak view", so I never realized the difference.

Anyway, as I already pointed out, it can be easily fixed, by setting the info to stabs, if required.

2011/9/19 Martin :

That is not my experience. In my projects I had set in project options "-g" and "-gl". After opening project in new Lazarus it defaults to "Automatic (Dwarf with sets)".

From lpi before:

<Debugging>
<GenerateDebugInfo Value="True"/>
</Debugging>

After:
<Debugging>
<GenerateDebugInfo Value="True"/>
<DebugInfoType Value="dsAuto"/>
</Debugging>

Line info is by default True, I guess.

2011/9/19 cobines :

I have GDB 7.3.2 from MinGW.

Sorry, that is actually 7.3-2. The newest available.

cobines wrote

> - Why do you prefer stabs? Because I always had problems with DWARF, at least on Win32. I have GDB 7.3.2 from MinGW. STABS seems to work better. There is problem

Same gdb here => and that should also be included in trunk snapshots, or download able from the binariy section of lazarus svn.

using fpc trunk

Lets look at them individually (and maybe what are the declarations for those types?

The last one (without quotes)

plongint(form1.fcaption)[-2]

works here. (make sure your lcl is compiled with dwarf too, though I would expect it to work anyway)

Also look at the error. Maybe "plongint" is not defined? Then try

^longint(form1.fcaption)[-2]

---
just tried
pbytearray(form1.fcaption)^

worked as well

> - Why do you prefer stabs generated by -g, rather than choosing explicitly? I thought -g always chooses the best supported debug info for the platform. I thought it chooses Stabs not Dwarf since it works better. Maybe that is not the case.

Well it chooses what the fpc devel thing to be best.

I have done my own tests, and run plenty of test my self, and tested many expressions against a huge amount of combinations of gdb versions betweeen 6.3.5 and 7.3 / fpc 2.4.2 to trunk, with both settings.

The result is that most things work on both. The Lazarus IDE also takes care of the many of the issues either format has.

2 things that dwarf can indeed not.
- correctly determining that a "var param pointer to object" as in "function foo(var BAR: PObject)", if used in an expression "BAR^" with one deref => actually is TObject and not PObject
hardly a tragedy => how many people use PObject, and how many have it as var param?
- some complex expressions that relay on accessing members of elements of dyn-arrays "dyn^[1].a" => that is a bit of an issue, I agree

On the plus site, you get the "property Counter: integer read FCounter" => that you can inspect.

Lot's of people, especially those less experienced, try to inspect things like this using hints => and with dwarf, they have at least a few they can expect. with stabs it doesn't work at all.

(personally I use the watches window, and can directly type FCounter, but as I said, lot's of people try to use the hints)

---
So for using within Lazarus, IMHO dwarf is at least as good as stabs.

using outside lazarus => I do not know

Otherwise there's no problem. I figured out I can set Stabs in default options for new project.

Exactly, ...

I have just been testing again (with todays lazarus (there have been some issues in the past few days) => it works.

I do get the type=stabs, I checked my project had exactly the settings you copied above. I also checked tha content of the new saved lpi file....

Please test with the latest version of Lazarus.

If it is important, I can add an option to the dropdown "use fpc default (-g)".
BUT it would not be the default.

Personally, I prefer not to add it => it will only confuse people, it there is a "lazarus" and a "fpc" default

2011/9/19 Martin :

Yes, I updated from SVN and now I get Stabs.

2011/9/19 Martin :

works here. (make sure your lcl is compiled with dwarf too, though I would expect it to work anyway)

You are right. I needed to build LCL with -gw. Now all expressions I posted work fine.

Martin wrote

So for using within Lazarus, IMHO dwarf is at least as good as stabs.

Thanks Martin, for all your testing. This is good news, especially since my new debugger only reads DWARF info.

Regards,
- Graeme -

Our mails crossed eachother.

"Leak view" is using heaptrc to get the info. So you're bound to hit the same bug and issues one day or another.

The other point that needs to be understood is that only the lineinfo or the lnfdwrf unit is loaded, not both (pmodules.pas line 659) . That means that ALL modules (LCL, RTL, external statically linked modules) need to be compiled with the same debug info to get maximum use of heaptrc or crash trace dumps. GDB uses all debug info available, including the coff symbols that are still present in the windows dll's.

Ludo

If you need to find out thinks yourself => e.g how different versions of gdb handle different things:

debugger/tests/GDBMI/RunGDBMI.lpi

look into TestBase.pas => how to configure a list of fpc and gdb versions (so you will be offered more than the one currently used in Lazarus).

The RunGDBMI.exe compiles a pascal source, that you can select, then you enter one or more gdb commands, and it will be run against every combination of fpc/gdb/stabs/dwarf

using CSF and strip-echo, you can copy and paste the result into excep/oo-calc => and have a nice table of all the results.

Ludo Brands wrote

"Leak view" is using heaptrc to get the info. So you're bound to hit the same bug and issues one day or another.

Not sure what you mean?

I get stacktraces from infodwrf (but also tested the lineinfo/stabs ones), and have copy and pasted them a thousand times into leak-view.

It works perfect. (though I believe, if I miss some of the leading spaces on the first line, it sometimes starts from the 2nd line...)

good point, and to add to it, AFAIK even gdb has some issues with mixed info, but I am not sure...

but that only means to ensure LCL is delivered with the same info than your app (so dwarf in future)

GDB uses all debug info available, including the coff symbols that are still present in the windows dll's.

Lnfodwrf assumes that line info blocks are stored contiguously. Changes in fpc introduce sometimes "garbage" between blocks and make Lnfodwrf crash. So as long as you use an "old" fpc, there is no problem. I haven't found out yet which revision introduced the problem. A 2.5.1 from april is working fine. Dwarf specs say that .debug_info compilatation units have to be parsed to find the offset in .debug_line. Garbage between blocks is perfectly allowed. Alligning coudl be a reason for introcuding garbage. Lnfodwrf skips parsing .debug_info.

Ludo

good point, and to add to it, AFAIK even gdb has some issues with mixed info, but I am not sure...

I just found a problem with propably the internal fpc linker when mixing stabs and dwarf. Stabs uses code N_SourceFile and N_IncludeFile to specify filenames. N_SourceFile is or a full path or a base directory + relative path. N_IncludeFile is or a full path or a relative path. When compiling the main program for dwarf debugging symbols, the fpc linker removes all N_SourceFile entries and leaves plenty of N_IncludeFile entries without base directory. Obviously gdb can't find the source file when having only the relative path and not the base directory.
Linking with the external linker doesn't create this problem.

Yes, I am aware of the -gostabsabsincludes compiler option that forces absolute filenames.

Ludo

Thank you (a late reply), that does it for me.
Had to rebuild LCL with stabs too, of course ;-)

Bart