[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [tcf-dev] Call stack issues when porting to another CPU architecture
|
- From: Evgueni Tarassov <eugene@xxxxxxxxxxx>
- Date: Wed, 10 Apr 2024 10:19:48 -0700
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=largest.net; dmarc=pass action=none header.from=largest.net; dkim=pass header.d=largest.net; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=7pL+eeLI1wAsvGYD9P+cxpx8RI2txYtPYoAhr5Gps1U=; b=e2tKPUt7BDGVmM6VfM00x7/Kgd+tW9a1zCovtVmRIsF501HntGu3smO2cLmCjDfwOJUVwlh5as5lY6VsYA6xao546+eaW8NlVxu4y0wtKh9PddtqKHa0o0CDuYS/rS88V1pjQlb7rSK7dEts0NCBsOvfajGRSDg3T6gibxpCJH++oXTmD+nI8HT101P89vyr9sjo7XvWHtCavBsxYoLKCNPqW+dHSOAlwBSPNeY7tIhQjAb9ERQji/UxJ9Jk+XA9QI9Z9FJF0VmCxADsX2D+oQvkXlBmsoNxi1+mAl4RiiWwhY2qceij0NaFgwNfbNjNguPhZovS/NQBFZbMjkHIZw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YjAmzOcL+zm/epeBs3JuAO4XsQzlZlGU6Jd3CCLvTnS97+b11T9wdtTCXSRkMGIWMWEvpK+sue+NsqarPDvuBx6kE9Zus+eEVOgziyNe8L/Jgd+E/T3uoTJ6fm3Ha+6fYUtNo/7pEBm2MqJxxg36onJ/45c84StGNVS+151E2zaM1kR7MaJIY/CT/IFwevKM7iLJtzqH0v7OREMXdmsMqT1DaGNqb8Dpgc+vwRLXOKpZTcmwkQWrOayX/sIDbSV4Z+adq3nR/tXpMaeED8mQwJ7EL54sZaYWcc9iAU9Av3CiamOZu41Z5BaXU7C7fa8J9izSA16ogn7SJwKzmLeRWw==
- Delivered-to: tcf-dev@xxxxxxxxxxx
- List-archive: <https://www.eclipse.org/mailman/private/tcf-dev/>
- List-help: <mailto:tcf-dev-request@eclipse.org?subject=help>
- List-subscribe: <https://www.eclipse.org/mailman/listinfo/tcf-dev>, <mailto:tcf-dev-request@eclipse.org?subject=subscribe>
- List-unsubscribe: <https://www.eclipse.org/mailman/options/tcf-dev>, <mailto:tcf-dev-request@eclipse.org?subject=unsubscribe>
- User-agent: Mozilla Thunderbird
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