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. 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. 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.

Regards, Matias.

Hi,

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,

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)" <

wrote:

Hi,

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,

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 :

Maybe not included by the linker script?

Hello Florian,

2017-07-22 13:49 GMT+01:00 Florian Klämpfl :

Maybe, I am not sure. The map file does show a .debug_aranges section either. Also I cannot find any information about .debug_arranges section in the generated .s. The section is included by the link script:

.debug_aranges BLOCK(__section_alignment__) (NOLOAD) : { *(.debug_aranges) }

Matias

______________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal