From: Tom Tromey <tom@tromey.com>
To: jh--- via Gdb <gdb@sourceware.org>
Cc: jh@clesse.com
Subject: Re: Creating and using dwarf information for ARMv7-A exception handlers
Date: Mon, 01 Dec 2025 12:59:41 -0700 [thread overview]
Message-ID: <87ikeq9dn6.fsf@tromey.com> (raw)
In-Reply-To: <6af4b8e63d0f1e9ec75d5ca4452874a8@clesse.com> (jh's message of "Wed, 26 Nov 2025 11:00:50 +0100")
>>>>> jh--- via Gdb <gdb@sourceware.org> writes:
> I would like (if it is possible) to have a complete stack trace when
> my code is in the SVC handler.
I don't know anything about ARM. However it's often the case that
unwinding through special frames requires some extra support, either
some flag in the debuginfo somewhere, or a special unwinder in gdb.
> What am I doing wrong?
> Is there a way to dump the dwarf state in gdb? To try and determine
> what it understands of my code and how it is primed when the
> breakpoint is triggered.
> Is the register number wrong? Is it something on the gdb side?
There's no simple answer to these questions. Unwinding in gdb is rather
complicated.
You can sometimes get some info with "set debug frame 1".
However the normal method is to debug gdb and try to understand what's
gone wrong.
I do see a lot of unwinding code in arm-tdep.c. I'd expect a lot of
that to be bypassed, though, if the DWARF describes the frame in question.
If so then you'd be looked at debugging through the DWARF unwinder.
Tom
prev parent reply other threads:[~2025-12-01 20:00 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1916c229fb1f148902bf15a1b60dedbe@clesse.com>
[not found] ` <51ebaf670472865c9abb31854e16c795@clesse.com>
2025-11-26 10:00 ` jh--- via Gdb
2025-11-26 10:05 ` Basile Starynkevitch
2025-11-27 8:13 ` jh--- via Gdb
2025-11-27 8:41 ` Basile Starynkevitch
2025-12-01 19:59 ` Tom Tromey [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ikeq9dn6.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb@sourceware.org \
--cc=jh@clesse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox