From: David Daney <ddaney@caviumnetworks.com>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sourceware.org, "Pinski,
Andrew" <Andrew.Pinski@caviumnetworks.com>,
Ralf Baechle <ralf@linux-mips.org>,
linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH] Make mips-linux signal frame unwinding more robust.
Date: Thu, 25 Feb 2010 18:49:00 -0000 [thread overview]
Message-ID: <4B86C5EB.6090303@caviumnetworks.com> (raw)
In-Reply-To: <20100225174739.GA2851@adacore.com>
On 02/25/2010 09:47 AM, Joel Brobecker wrote:
>> This patch makes gdb follow suit and find the sigcontext_base using
>> the signal frame's SP rather than an offset from the trampoline.
>
> Is there a document that explains that the sigcontext structure is
> always going to be at the frame's SP?
No official document, however the principle of maintaining binary
compatibility is important, and recognized by the kernel maintainers.
There are several things that constrain the the changes that can be made
in the kernel:
1) The glibc setcontext API as discussed here:
http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=alpine.DEB.1.10.0902282326580.4064%40tp.orcam.me.uk
2) libgcc's unwinder:
http://gcc.gnu.org/viewcvs/trunk/gcc/config/mips/linux-unwind.h?revision=145841&view=markup
>
> I don't know mips-linux, but something looked funny to me: You avoid
> the use of SIGFRAME_CODE_OFFSET to compute the address where the sigcontext
> structure is located, but you still use it to compute the frame base
> address (used when building the frame ID). Is the frame base address
> still a constant offset from FUNC, or does the frame ID base address
> also needs to be changed.
Right, I missed that part. When it started working, I stopped patching.
I will take another look at that part.
>
> I believe that Daniel J has a good knowledge of mips-linux, and would be
> an ideal reviewer. If he doesn't have time, though, I'm OK with approving
> a patch for the HEAD branch. For the 7.1 branch, though, I'd rather have
> a more knowledgeable opinion.
>
Thanks,
David Daney
next prev parent reply other threads:[~2010-02-25 18:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-22 18:36 David Daney
2010-02-25 17:47 ` Joel Brobecker
2010-02-25 18:49 ` David Daney [this message]
2010-02-26 18:23 ` David Daney
2010-02-26 20:50 ` Daniel Jacobowitz
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=4B86C5EB.6090303@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=Andrew.Pinski@caviumnetworks.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=linux-mips@linux-mips.org \
--cc=ralf@linux-mips.org \
/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