Re: [tcf-dev] Call stack issues when porting to another CPU architecture

[Evgueni Tarassov <eugene@xxxxxxxxxxx>]

Hi Tobias,


> Is my understanding correct that even without crawl_stack_frame() the 
call stack should be complete based on the debug information?


Yes - if all your code is compiled with debug info. Usually libraries, 
like libc, don't have debug info.

Without crawl_stack_frame(), the stack trace will stop on first frame 
that does not have debug info.


> Is there something I missed to trigger to cause the call stack to be 
updated during single stepping?


The agent erases stack trace data when target is resumed for any reason, 
included single stepping.

I don't know anything that would prevent re-tracing stack after single 
stepping.


Regards,

Eugene


On 4/10/2024 1:02 AM, Tobias Klinke via tcf-dev wrote:
> Hi,
>
> I'm working on a port of the TCF agent to another CPU architecture 
> (TriCore Aurix).
>
> In my setup, the TCF agent runs on Windows and is used to debug a 
> program running on the bare-metal target device. Symbols are coming 
> from an ELF file.
>
> I face some problems with the call stack:
> a) In Eclipse debug view I see at most two levels (top frame and one 
> below)
> b) The call stack only updates when I hit "suspend". While single 
> stepping only the top frame updates, the second level is frozen.
>
> My main questions are currently:
> 1. I haven't yet implemented crawl_stack_frame (I just return 0) as 
> the ELF binary contains debug information and my register definitions 
> contain correct DWARF IDs. Is my understanding correct that even 
> without crawl_stack_frame() the call stack should be complete based on 
> the debug information?
> 2. Is there something I missed to trigger to cause the call stack to 
> be updated during single stepping?
>
> Any other hints on what to check or what needs to be implemented are 
> also appreciated.
>
> Best regards,
> Tobias Klinke