From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25893 invoked by alias); 11 Feb 2015 00:01:03 -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 25873 invoked by uid 89); 11 Feb 2015 00:01:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: glazunov.sibelius.xs4all.nl Received: from sibelius.xs4all.nl (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 11 Feb 2015 00:01:00 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id t1B00hGY015950; Wed, 11 Feb 2015 01:00:43 +0100 (CET) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id t1B00hKq019459; Wed, 11 Feb 2015 01:00:43 +0100 (CET) Date: Wed, 11 Feb 2015 00:01:00 -0000 Message-Id: <201502110000.t1B00hKq019459@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: jhb@freebsd.org CC: palves@redhat.com, gdb-patches@sourceware.org In-reply-to: <54DA9572.1010304@redhat.com> (message from Pedro Alves on Tue, 10 Feb 2015 23:34:10 +0000) Subject: Re: [PATCH] Fix signal trampoline detection/unwinding on recent FreeBSD/i386 and FreeBSD/amd64 References: <11386216.Yv1qECs4Mc@ralph.baldwin.cx> <1836606.R8FOmMR0ZG@ralph.baldwin.cx> <54DA3AFE.3060406@redhat.com> <1778386.0IyHlhpa5R@ralph.baldwin.cx> <54DA9572.1010304@redhat.com> X-SW-Source: 2015-02/txt/msg00282.txt.bz2 > Date: Tue, 10 Feb 2015 23:34:10 +0000 > From: Pedro Alves > > Thanks, updated patch looks good. Feel free to push. Same here. Although you guys should really make randomize the location signal trampoline page. In that case you should look at amd64obsd-tdep.c:amd64obsd_sigtramp_p(). > 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 ... > > 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. > > Looking at: > > https://github.com/freebsd/freebsd/blob/master/sys/amd64/amd64/sigtramp.S > > It looks pretty much the same. That should make it always work correctly > for (cross) core and remote debugging. > > -------------