public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: "Carlos O'Donell" <carlos@redhat.com>
To: Will Newton <will.newton@linaro.org>
Cc: "libc-ports@sourceware.org" <libc-ports@sourceware.org>,
	       Patch Tracking <patches@linaro.org>
Subject: Re: [PATCH v2] ARM: Add SystemTap probes to longjmp and setjmp.
Date: Thu, 06 Feb 2014 16:54:00 -0000	[thread overview]
Message-ID: <52F3BE5F.9050005@redhat.com> (raw)
In-Reply-To: <CANu=Dmja7gft7WMXC1Km77e1XP9S29itiVai2S3AAtmYQ7bz9w@mail.gmail.com>

On 02/06/2014 11:48 AM, Will Newton wrote:
> On 6 February 2014 16:26, Carlos O'Donell <carlos@redhat.com> wrote:
>> On 02/05/2014 04:56 AM, Will Newton wrote:
>>> Now the ARM port implements pointer encryption for jmpbufs, gdb needs
>>> a SystemTap probe point in longjmp to determine the target PC of
>>> a call to longjmp. This patch implements the probe points in longjmp
>>> and a similar probe point in setjmp.
>>>
>>> In order to have all the appropriate registers available to pass to the
>>> probe this reorders the layout of jmpbuf, putting the sp and lr registers
>>> at the start rather than the end.
>>>
>>> Tested on armv7, no new failures in the glibc testsuite and confirmed
>>> that this fixes the gdb.base/longjmp.exp failures in the gdb testsuite.
>>
>> This looks good to me.
>>
>> If it's considered a bug, please check this in immediately and CC Allan
>> to keep him in the loop for these last minute bug fixes.
>>
>> We are about to freeze so the 2.19 branch can be cut. If there is anything
>> else like this please bring it to his attention immediately.
> 
> Sorry I should have been clearer, I am proposing this patch for 2.20.
> 
> It is a regression of functionality to add pointer encryption without
> this patch as gdb now cannot deal with longjmp calls as well as it
> could previously but I agree with Jospeh that it's not appropriate to
> push a change of this nature so late in the freeze.

As long as gdb isn't broken by not having the patch then you are
correct that this is inappropriate for 2.19.

Cheers,
Carlos.

  reply	other threads:[~2014-02-06 16:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-05  9:56 Will Newton
2014-02-06 16:26 ` Carlos O'Donell
2014-02-06 16:41   ` Joseph S. Myers
2014-02-06 16:48   ` Will Newton
2014-02-06 16:54     ` Carlos O'Donell [this message]
2014-02-06 22:11 ` Roland McGrath
2014-02-07 12:38   ` Will Newton
2014-02-07 14:16     ` Andreas Schwab
2014-02-07 15:45       ` Jonathan S. Shapiro
2014-02-07 17:04       ` Joseph S. Myers
     [not found]       ` <CAAP=3QP6_TvyFdpmO9Or5E2=NFCdcUVrCGBHT3rMozRXLT4mmw@mail.gmail.com>
2014-02-10  8:54         ` Will Newton

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=52F3BE5F.9050005@redhat.com \
    --to=carlos@redhat.com \
    --cc=libc-ports@sourceware.org \
    --cc=patches@linaro.org \
    --cc=will.newton@linaro.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).