How to get debug information?
There is an error, but only adresses are shown.
I put on debugger Information in Lazarus (-g) but can get no further infos when an error occurs (except the adresses).
Lazarus 0.9.30
fpc 2.4.2

Mailing lists / fpc-pascal / 2012-05
12 messages · 4 people · –
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
How to get debug information?
There is an error, but only adresses are shown.
I put on debugger Information in Lazarus (-g) but can get no further infos when an error occurs (except the adresses).
Lazarus 0.9.30
fpc 2.4.2
You also need to enable line information using "-gl". Debug information itself is only useful for stepping through an application using a debugger. The line information is the one you seek.
Regards,
Sven
That does not work.
I sign it in the lazarus project preferences window, but no effect.
How to get debug information? There is an error, but only adresses are shown. I put on…
Rainer Stratmann wroteHow to get debug information? There is an error, but only adresses are shown.
How/ Where are the addresses shown?
Does your program has code of it's own, that dumps the stacktrace? (normally added using with -gl)
Or do you run in a debugger (gdb?)
You should note that the DumpStack function, if called by your code (AND if debug info is available) does dump source file and line. BUT only up to the very first time it does encounter an address that can not be resolved. Once that has happened no further addresses are resolved.
The addresses were shown in the output window (console). Runtime error 207 at $0808BE90
$0808BE90
$080A0E60
$080A0738
$08049064
$08053256
$080494F2
$08048F84
$08048754
$080483E3
$080482B3
Does your program has code of it's own, that dumps the stacktrace?
No.
(normally added using with -gl) Or do you run in a debugger (gdb?)
No.
You should note that the DumpStack function, if called by your code (AND if debug info is available) does dump source file and line.
I am not familiar with that function?
BUT only up to the very first time it does encounter an address that can not be resolved. Once that has happened no further addresses are resolved.
I do not understand exactly what that means.
Ok: those addresses *should* get names, if you compile with -gl AND do
not in any form strip (strip.exe removes the debug info) your appAn app containing debug info has a considerable bigger exe. (can be 10 times or more as big as without)
if you make a copy of your exe, and run
strip[.exe] the_copy
the the copy should be much smaller
On windows strip.exe is in the fpc bin directory
If you get it to work, and one of the addresses is in the RTL (assuming your RTL has no dobug info), or in the kernel then the translation simply stops.
It could be that the top address is in the rtl, then you will never get the info
you can use gdb (assuming there is debug info / check the exe size) gdb your_exe
and inside gdb
info symbol *0x0808BE90
Not all symbols may resolve though
------------------
You can (again assume debug info) run in gdb
gdb your_exe
break FPC_RUNERROR
r
and when stopped
bt
Hi,
that sounds very complicated in comparison to the past. There I could get it work and simply the line numbers and the file were displayed in combination with the addresses. Why does it not work this way again? The addresses are not in the system unit.
I am compiling under Linux!
Are there also gdb and strip available?
Well as others already said: it should still work simply by adding -gl
But apparently it does not for you.
Finding out why not, indeed can be more complex. So I added various bits of info... In case.
Just seeing you use lazarus.
Check that you have not accidentally set any options that will block -gl, such as -Xs or maybe (may work but I do not know for sure) -Xg
After changing options, change "Build" or "Build all" from "run" menu.
Martin wroteCheck that you have not accidentally set any options that will block -gl, such as -Xs or maybe (may work but I do not know for sure) -Xg After changing options, change "Build" or "Build all" from "run" menu.
All done, same effect (only addresses shown).
I thought of other options that block the lineoutput, but can not imagine which one.
Gets back to one of the questions of the last mail: Did you have a look at the exe size?
The exe size is the easiest indicator, if debug info was added.
Running out of ideas myself.
Can you run with F9 in Lazarus? making sure the debugger is set up ( http://wiki.lazarus.freepascal.org/Debugger_Setup ) The debugger should stop on a run error, and you should be able to get the stacktrace.
It does not solve the initial problem, but one step at a time.
The program size (in Linux) is nearly 3 times more than without debug info.
Running out of ideas myself.
May be someone else can help...
Can you run with F9 in Lazarus? making sure the debugger is set up ( http://wiki.lazarus.freepascal.org/Debugger_Setup )
I will try later.
Rainer Stratmann wroteI will try later.
Also make sure you have turned *off* all optimizations, they can sometimes mess up the stack trace badly (by removing unneeded stack frames which can produce very confusing results) and also I have witnessed at least one occasion where smart linking also somehow interfered with debugging (but this might have been a gdb problem), but maybe better turn this off also, just to be on the safe side.
Building your own compiler and RTL from source with debugging symbols only sounds complicated the very first time you hear about this idea, once you have successfully done it yourself you will find that it is actually quite easy and not more complicated than installing a compiler via the .deb packages.
Bernd