From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9783 invoked by alias); 11 Feb 2015 16:04:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9768 invoked by uid 89); 11 Feb 2015 16:04:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: bigwig.baldwin.cx Received: from bigwig.baldwin.cx (HELO bigwig.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 11 Feb 2015 16:04:22 +0000 Received: from ralph.baldwin.cx (pool-173-54-116-245.nwrknj.fios.verizon.net [173.54.116.245]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 5AABDB953; Wed, 11 Feb 2015 11:04:19 -0500 (EST) From: John Baldwin To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Fix signal trampoline detection/unwinding on recent FreeBSD/i386 and FreeBSD/amd64 Date: Wed, 11 Feb 2015 16:04:00 -0000 Message-ID: <1764587.lQfaPVNLAm@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54DA9572.1010304@redhat.com> References: <11386216.Yv1qECs4Mc@ralph.baldwin.cx> <1778386.0IyHlhpa5R@ralph.baldwin.cx> <54DA9572.1010304@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2015-02/txt/msg00313.txt.bz2 On Tuesday, February 10, 2015 11:34:10 PM Pedro Alves wrote: > Thanks, updated patch looks good. Feel free to push. Note that I do not have read/write access to git, so I believe I need someone to push this for me? > On 02/10/2015 07:14 PM, John Baldwin wrote: > > On Tuesday, February 10, 2015 05:08:14 PM Pedro Alves wrote: > >> On 02/10/2015 02:50 PM, John Baldwin wrote: > >>>> + sysctl that returns the location of the signal trampoline. > >>>> + Note that this fetches the address for the current (gdb) process. > >>>> + This will be correct for other 64-bit processes, but the signal > >>>> + trampoline location is not properly set for 32-bit processes. */ > >> > >> I'm not sure I understand what does "but the signal trampoline > >> location is not properly set for 32-bit processes" means. You mean > >> it's not properly set because GDB is 64-bit; or it's not properly set > >> in the kernel; or something else? > > > > The sysctl is designed to be used against the target process, but I did > > not > > see an easy way to hook into each run and ptrace attach to invoke the > > sysctl against the inferior directly. > > You'd do something like the patch below, on top of yours. Completely > untested. Just for illustration. > > However, unless this info is recorded in core dumps, this is all of course > broken for core file debugging ... Yes, it occurred to me that to make this really reliable I'd have to annotate it in core dumps instead. > Do we _really_ need to know the sigtramp location? What does the sigtramp > disassembly look like? How about just detecting the sigtramp > like other platforms do, by recognizing the instructions? On Linux, this > is just: > > mov $__NR_rt_sigreturn, %rax > syscall > > And is parsed in amd64_linux_sigtramp_p -> amd64_linux_sigtramp_start. 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). -- John Baldwin