[fpc-pascal] backtrace code in fpc

Matias Vara matiasevara at gmail.com
Sat Jul 22 14:47:30 CEST 2017


I am not sure why my executable does not contains a .debug_aranges section.
It contains .debug_line and .debug_info. Am I missing some linker flags?

Thanks, Matias.

2017-07-19 0:05 GMT+01:00 Matias Vara <matiasevara at gmail.com>:

> Hello Charlie and thanks for the comments. I ended up by implementing my
> own Infodwrf unit.
> Matias
> On 18 Jul 2017 11:48 p.m., "Karoly Balogh (Charlie/SGR)" <
> charlie at scenergy.dfmk.hu> wrote:
> Hi,
> On Mon, 17 Jul 2017, Matias Vara wrote:
> > Hello everyone, I am trying to port the code for backtrace, e.g.,
> > GetLineInfo(), to my freepascal kernel in order to print a backtrace
> > when an exception happens.
> Slightly off topic, but make sure when you copy code from (or even study
> the source of) the RTL, that your resulting code is license compatible.
> > The drawback now is that I am not sure where the source is. I think it
> > is the unit lnfodwrf.pp however I am not sure.
> The backtrace/stack traversal code itself is in system unit, see
> FPC_PushExceptObject and surrounding code. To print the frames collected
> there, the system unit will just use BackTraceStrFunc as implemented by
> various debuginfo units to print lineinfo strings based on information by
> the different debug/symbol formats.
> You just have to implement your own debug info parser and custom
> BackTraceStrFunc, then the RTL should handle the rest. You can check the
> various locations where BackTraceStrFunc is called in system unit for
> further reference.
> > From the code, it seems that this unit is opening the executable to get
> > the debug section, is this correct? is it not getting the name of the
> > symbols from memory? In my case, the debug symbols must be taken from
> > memory since there is no disk access.
> The lnfodwrf unit just gets the symbol name for a given address, stored in
> DWARF debug info sections in an executable, and injects it's own
> BackTraceStrFunc in the RTL to return that.. The same with lineinfo unit
> for STABS debug info format, actually. Opening a file and loading it is
> not a requirement, as long as your tables are in the memory anyway. But
> normally these are not loaded by the executable loader of OSes, hence
> these units will load/parse them.
> If they're in memory in your case already, you can just skip the loading,
> and implement your own customized version of lnfodwrf unit, etc.
> BackTraceStrFunc is the key really, as it's quite universal. And the
> default implementation is quite simple, see SysBackTraceStr.
> Hope this was helpful,
> --
> Charlie
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20170722/8c44669f/attachment.html>

More information about the fpc-pascal mailing list