[fpc-devel] Debug Info proposal

Martin Friebe fpc at mfriebe.de
Sun Jan 13 19:42:29 CET 2008


I haven't tested this, but from what I read, if strip can preserve the
symbols in a separate file then gdb should be able to load them.

http://www.delorie.com/gnu/docs/gdb/gdb_125.html
>
> |exec-file [ filename ]|
>     Specify that the program to be run (but not the symbol table) is
>     found in filename. GDB searches the environment variable |PATH| if
>     necessary to locate your program. Omitting filename means to
>     discard information on the executable file. 
> |symbol-file [ filename ]|
>     Read symbol table information from file filename. |PATH| is
>     searched when necessary. Use the |file| command to get both symbol
>     table and program to run from the same file.
>
I am not sure what file format gdb expects for symbols. It may well be,
that you can take your original (unstripped) executable for the symbols.
Please try it out yourself.

Good luck

Martin


Daniël Mantione wrote:
>
>
> Op Sun, 13 Jan 2008, schreef Joost van der Sluis:
>
>> Op zaterdag 12-01-2008 om 20:11 uur [tijdzone +0100], schreef Bogus?aw
>> Brandys:
>>> Jonas Maebe wrote:
>>>
>>> Could fpc devel team provide application with source code which could
>>> translate addresses from bare bone stacktrace generated from stripped
>>> executable into full stacktrace with unit/line info using bare bone
>>> stacktrace file and executable with debug info included ?
>>
>> Why would we? This is exactly what strip does! It strips out the
>> debug-info to a seperate file. This is wat the -debug package is when
>> you create a .rpm. That -debug package stores the debuginfo. If you
>> install the -debug package, you can use gdb to debug your application.
>> If you don't install it, you can't.
>
> To be honest, if you would receive a runtime error + stack backtrace 
> output from a user, converting it back to a source line back trace 
> isn't that easy currently. Sure, you can load the debuginfo executable 
> in gdb, then look up the lines one by one, but it would be a time 
> consuming process.
>
> Daniël
> ------------------------------------------------------------------------
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>   




More information about the fpc-devel mailing list