Re: [PATCH] Fix signal trampoline detection/unwinding on recent FreeBSD/i386 and FreeBSD/amd64

[John Baldwin <jhb@freebsd.org>]

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