Hello, 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 <matiasev...@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)" < > char...@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@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal