public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: John Baldwin <jhb@freebsd.org>
Cc: gdb-patches@sourceware.org, Mark Kettenis <mark.kettenis@xs4all.nl>
Subject: Re: [PATCH] Fix signal trampoline detection/unwinding on recent FreeBSD/i386 and FreeBSD/amd64
Date: Mon, 23 Feb 2015 16:56:00 -0000	[thread overview]
Message-ID: <54EB5B95.90701@redhat.com> (raw)
In-Reply-To: <2144163.poMfT1VBCC@ralph.baldwin.cx>

On 02/23/2015 04:32 PM, John Baldwin wrote:
> On Monday, February 16, 2015 10:55:54 PM Pedro Alves wrote:
>> On 02/16/2015 04:37 PM, John Baldwin wrote:
>>> On Wednesday, February 11, 2015 04:40:17 PM Pedro Alves wrote:
>>>> On 02/11/2015 03:32 PM, John Baldwin wrote:
>>>>> Actually, this does sound far simpler.  I was simply updating the
>>>>> sigtramp
>>>>> code that was already present.  I can certainly work on changing both
>>>>> i386
>>>>> and amd64 to do this instead if that is the preferred method (and it
>>>>> seems
>>>>> to be from looking at other targets).
>>>>
>>>> Yep, that's the preferred method.  That'd be great.
>>>
>>> I've implemented this and attached the updated patch below.  I'm not quite
>>> sure if the updated Changelog is correct however.  I ran into one hiccup
>>> though which is that the signal trampoline code is not included in process
>>> core dumps in recent FreeBSD versions (after it was moved off of the stack
>>> and into a global shared page).  I've fixed this in FreeBSD so that
>>> future versions will include the trampoline in core dumps, but I've
>>> retained the change to use KERN_PROC_SIGTRAMP to support core dumps from
>>> the versions that do not include it in the core.  I've removed the
>>> support for specifying a signal trampoline location for older verions
>>> using either hardcoded offsets or ps_strings as it is no longer needed.
>>
>> Looks great to me!  Mark, any comments?
>>
>> (I see a couple minor formatting issues, but I can fix them up
>> for you before pushing.)
> 
> Just pinging about this (I haven't see a mail from Mark, so I assume you are
> waiting on that?)
> 

I think we can go ahead and push.  We can always address Mark's comments later,
if any.

Could you send the patch in "git am"able form (that is, along with an
updated git commit log)?

Thanks,
Pedro Alves

      reply	other threads:[~2015-02-23 16:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-04 15:47 John Baldwin
2015-02-10 14:51 ` [PATCH] " John Baldwin
2015-02-10 17:08   ` Pedro Alves
2015-02-10 19:14     ` John Baldwin
2015-02-10 23:34       ` Pedro Alves
2015-02-11  0:01         ` Mark Kettenis
2015-02-11 16:04         ` John Baldwin
2015-02-11 16:40           ` Pedro Alves
2015-02-16 18:25             ` John Baldwin
2015-02-16 22:56               ` Pedro Alves
2015-02-23 16:33                 ` John Baldwin
2015-02-23 16:56                   ` Pedro Alves [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=54EB5B95.90701@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jhb@freebsd.org \
    --cc=mark.kettenis@xs4all.nl \
    /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).