This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Fix signal trampoline detection/unwinding on recent FreeBSD/i386 and FreeBSD/amd64
- From: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- To: jhb at freebsd dot org
- Cc: palves at redhat dot com, gdb-patches at sourceware dot org
- Date: Wed, 11 Feb 2015 01:00:43 +0100 (CET)
- Subject: Re: [PATCH] Fix signal trampoline detection/unwinding on recent FreeBSD/i386 and FreeBSD/amd64
- Authentication-results: sourceware.org; auth=none
- References: <11386216 dot Yv1qECs4Mc at ralph dot baldwin dot cx> <1836606 dot R8FOmMR0ZG at ralph dot baldwin dot cx> <54DA3AFE dot 3060406 at redhat dot com> <1778386 dot 0IyHlhpa5R at ralph dot baldwin dot cx> <54DA9572 dot 1010304 at redhat dot com>
> Date: Tue, 10 Feb 2015 23:34:10 +0000
> From: Pedro Alves <palves@redhat.com>
>
> 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.
>
> -------------