From: Luis Machado <luis.machado@linaro.org>
To: Paul Carroll <pcarroll@codesourcery.com>,
Andrew Pinski <pinskia@gmail.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Modify Aarch64 prologue analyzer to accept 128-bit registers
Date: Tue, 14 Nov 2017 14:12:00 -0000 [thread overview]
Message-ID: <fad8a6e5-48a3-1d1b-8472-aa135d35a9ad@linaro.org> (raw)
In-Reply-To: <c5bcf8f8-6cd4-d73f-fd3f-5ac731eae5d8@codesourcery.com>
On 11/14/2017 11:41 AM, Paul Carroll wrote:
> (Sending again, due to problems with the mailing list not liking my
> previous post)
>
> On 11/13/2017 12:32 PM, Andrew Pinski wrote:
>> Hmm, The normal elf aarch64 ABI says only 64bits is saved. Is there
>> another ABI which says 128bits of the SIMD register is saved?
>
> Thanks for the comment, Andrew.
> In this case, the code in question is an interrupt routine.
> As such, it is not following the ABI, except when making calls itself.
> When gdb processes the start of the interrupt routine, it finds the
> 'stp' with the 128-bit register references and asserts.
> That is a problem for debugging embedded applications, and is what this
> patch is trying to avoid.
>
I take it this is RTOS-specific?
If so, I can see a couple alternatives. One way would be to patch it in
the RTOS-specific file in GDB, keeping the fix contained in the right
context instead of in general code that will likely not benefit from it.
The second alternative is to augment the code with CFI information so
GDB doesn't have to use the prologue analyzers. There will always be a
particular combination of instructions GDB won't recognize, especially
for custom code that doesn't follow the ABI.
The plus side of fixing this on the RTOS code itself is that GDB doesn't
have to be patched every time an unknown prologue sequence is
encountered. But attempting to debug binaries stripped of symbols and
debug information will required GDB to be patched.
prev parent reply other threads:[~2017-11-14 14:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1816677702.1219332.1510594086497.ref@mail.yahoo.com>
2017-11-13 17:28 ` pcarroll
2017-11-13 17:32 ` Andrew Pinski
2017-11-14 14:01 ` Paul Carroll
2017-11-14 14:12 ` Luis Machado [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=fad8a6e5-48a3-1d1b-8472-aa135d35a9ad@linaro.org \
--to=luis.machado@linaro.org \
--cc=gdb-patches@sourceware.org \
--cc=pcarroll@codesourcery.com \
--cc=pinskia@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).