I'm not very familiar with CFA information. I've been worried that
strip(1) removes those symbols. Is that worry meritless?
On Sun, Nov 21, 2021 at 9:32 AM Jason Thorpe wrote:
>
> > On Nov 21, 2021, at 6:35 AM, John Marino (NetBSD)
> wrote:
> >
> > Sorry, I
6:04 PM Jason Thorpe wrote:
>
>
> > On Nov 14, 2021, at 3:12 PM, John Marino (NetBSD)
> wrote:
> >
> > So for the purpose of the gdb unwinder, I would pass NULL for the sp
> argument?
> > The unwinder would only be checking the result to see
> __sigtramp_un
So for the purpose of the gdb unwinder, I would pass NULL for the sp
argument?
The unwinder would only be checking the result to see __sigtramp_unwind_np
returns null or not.
John
On Sun, Nov 14, 2021 at 2:49 PM Jason Thorpe wrote:
>
> > On Oct 28, 2021, at 8:49 AM, Valery Ushakov wrote:
> >
>
AM, John Marino (NetBSD)
> wrote:
> >
> > yes, it sounds like a __in_signal_trampoline function would work for
> > the GCC unwind, and I would think it would work for GDB as well.
>
> Ok, I have implemented a new function with this signature:
>
> /*
> * __sig
Valery Ushakov wrote:
>
> On Mon, Oct 18, 2021 at 10:41:48 -0500, John Marino (NetBSD) wrote:
>
> > How we did it with libc before is shown in the netbsd-unwind.h link in
> > the original post. This technique looks for __sigtramp_siginfo_2
> > assembly code but no long
I'm in no way a GDB expert. I believe it's currently using basic
dwarf debugging information, basically just looking for the
__sigtramp_siginfo_2 function name. If it finds that, it declares the
sigtramp found. I do not believe it's using the cfi notations which
are relatively recent if I
yes, it sounds like a __in_signal_trampoline function would work for
the GCC unwind, and I would think it would work for GDB as well.
Thanks,
John
On Mon, Oct 18, 2021 at 10:48 AM Jason Thorpe wrote:
>
>
>
> > On Oct 18, 2021, at 8:41 AM, John Marino (NetBSD) wrote:
> >
&
For GCC, we've got the return address (context->ra in the unwind
programs in the original post). The "problem" is that we want to
know if that address falls on a signal trampoline frame. If NO,
return "end of stack", otherwise unwind the frame.
The KERN_PROC_SIGTRAMP of FreeBSD and DragonFly
Alright, so I think we have established that it's impossible to
provide KERN_PROC_SIGTRAMP as it functions on FreeBSD and DragonFly.
The purpose of that sysctl is to get the address range of the single
signal trampoline.
Would it be possible to have a slightly different version on NetBSD
that
Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl?
TLDR;
For several years, the GNAT Ada compiler has not been able to unwind a
stack containing a signal trampoline. The unwinder I wrote for gcc
several years ago just stopped working on newer NetBSD release even
though the signal
10 matches
Mail list logo
