backtrace code in fpc

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

backtrace code in fpc

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

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: backtrace code in fpc

Karoly Balogh (Charlie/SGR)
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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: backtrace code in fpc

Matias Vara
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)" <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: backtrace code in fpc

Matias Vara
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 <[hidden email]>:
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)" <[hidden email]> 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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: backtrace code in fpc

Florian Klämpfl
Am 22.07.2017 um 14:47 schrieb Matias Vara:
> 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?
>

Maybe not included by the linker script?

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: backtrace code in fpc

Matias Vara
Hello Florian,

2017-07-22 13:49 GMT+01:00 Florian Klämpfl <[hidden email]>:
Am 22.07.2017 um 14:47 schrieb Matias Vara:
> 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?
>

Maybe not included by the linker script?


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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Loading...