Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2012-05

Debug information

12 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Rainer Stratmann

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

Sven Barth
to Rainer Stratmann
Rainer Stratmann wrote 9 lines
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

Rainer Stratmann
to Sven Barth
Sven Barth wrote 14 lines
On 27.05.2012 14:32, Rainer Stratmann wrote: > 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.

That does not work.
I sign it in the lazarus project preferences window, but no effect.

Show quoted text 6 lines
Regards, Sven _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Martin
to Rainer Stratmann: How to get debug information? There is an error, but only adresses are shown. I put on…
Rainer Stratmann wrote
How 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.

Rainer Stratmann
to Martin
Martin wrote 6 lines
On 27/05/2012 13:32, Rainer Stratmann wrote: > How to get debug information? > > There is an error, but only adresses are shown. How/ Where are the addresses shown?

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.

Martin
to Rainer Stratmann
Rainer Stratmann wrote 9 lines
Am Monday 28 May 2012 21:12:30 schrieb Martin: > On 27/05/2012 13:32, Rainer Stratmann wrote: >> How to get debug information? >> >> There is an error, but only adresses are shown. > How/ Where are the addresses shown? The addresses were shown in the output window (console). Runtime error 207 at $0808BE90 $0808BE90
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 app

An 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

Show quoted text 5 lines
> 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.

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

Rainer Stratmann
to Martin
Martin wrote 12 lines
On 28/05/2012 20:35, Rainer Stratmann wrote: > Am Monday 28 May 2012 21:12:30 schrieb Martin: >> On 27/05/2012 13:32, Rainer Stratmann wrote: >>> How to get debug information? >>> >>> There is an error, but only adresses are shown. >> >> How/ Where are the addresses shown? > > The addresses were shown in the output window (console). > Runtime error 207 at $0808BE90 > $0808BE90

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?

Show quoted text 48 lines
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 app An 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 >> 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. 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 _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Martin
to Rainer Stratmann
Rainer Stratmann wrote 14 lines
Am Monday 28 May 2012 22:09:21 schrieb Martin: > On 28/05/2012 20:35, Rainer Stratmann wrote: >> Am Monday 28 May 2012 21:12:30 schrieb Martin: >>> On 27/05/2012 13:32, Rainer Stratmann wrote: >>>> How to get debug information? >>>> >>>> There is an error, but only adresses are shown. >>> How/ Where are the addresses shown? >> The addresses were shown in the output window (console). >> Runtime error 207 at $0808BE90 >> $0808BE90 Hi, that sounds very complicated in comparison to the past. There I could get it

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.

Rainer Stratmann
to Martin
Martin wrote
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.

All done, same effect (only addresses shown).
I thought of other options that block the lineoutput, but can not imagine which one.

Martin
to Rainer Stratmann
Rainer Stratmann wrote 9 lines
Am Monday 28 May 2012 22:25:47 schrieb Martin: > 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. 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.

Rainer Stratmann
to Martin
Martin wrote 14 lines
On 28/05/2012 23:53, Rainer Stratmann wrote: > Am Monday 28 May 2012 22:25:47 schrieb Martin: >> 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. > > 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.

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.

Show quoted text 7 lines
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. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Bernd Kreuss
to Rainer Stratmann
Rainer Stratmann wrote
I 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