If strip removes it, then you’re doomed anyway and trampoline assist via a
function won’t help you, because you won’t be able to get to the trampoline or
past it anyway.
-- thorpej
Sent from my iPhone.
> On Nov 21, 2021, at 7:54 AM, John Marino (NetBSD) wrote:
>
>
> I'm not very familiar
> On Nov 21, 2021, at 8:28 AM, Jason Thorpe wrote:
>
> If strip removes it, then you’re doomed anyway and trampoline assist via a
> function won’t help you, because you won’t be able to get to the trampoline
> or past it anyway.
Here’s a before/after of a “strip -s” of a binary on the
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 meant to answer and got
> On Nov 21, 2021, at 6:35 AM, John Marino (NetBSD) wrote:
>
> Sorry, I meant to answer and got overwhelmed.
> Actually, I had a typo in the previous response. I meant to say "GCC"
> unwinder, not gdb unwinder.
> I don't see how this helps support the GCC unwinder. The context information
>
Sorry, I meant to answer and got overwhelmed.
Actually, I had a typo in the previous response. I meant to say "GCC"
unwinder, not gdb unwinder.
I don't see how this helps support the GCC unwinder. The context
information to support the unwind is already provided, we just need the
boolean (is this
> 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_unwind_np
> returns null or not.
This would not work for the gdb unwinder — it
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:
> >
>
> On Oct 28, 2021, at 8:49 AM, Valery Ushakov wrote:
>
> It is ucontext for the siginfo trampoline and sigcontext for the older
> one, isn't it?
Ok, I’ve settled on the following:
void *__sigtramp_unwind_np(void *pc, void *sp, int *versp);
Given a program counter and stack pointer, return a
> On Oct 29, 2021, at 7:54 AM, Jason Thorpe wrote:
>
>
>
>> On Oct 29, 2021, at 2:45 AM, Martin Husemann wrote:
>>
>> On Thu, Oct 28, 2021 at 11:14:39AM -0700, Jason Thorpe wrote:
>>> We really just need to kill the sigcontext stuff completely. More to the
>>> point, we should version
> On Oct 29, 2021, at 2:45 AM, Martin Husemann wrote:
>
> On Thu, Oct 28, 2021 at 11:14:39AM -0700, Jason Thorpe wrote:
>> We really just need to kill the sigcontext stuff completely. More to the
>> point, we should version sigaction() before (or concurrently with) adding
>> whatever call
On Thu, Oct 28, 2021 at 11:14:39AM -0700, Jason Thorpe wrote:
> We really just need to kill the sigcontext stuff completely. More to the
> point, we should version sigaction() before (or concurrently with) adding
> whatever call we add here so as to ensure that it will only ever be a
>
> On Oct 28, 2021, at 8:49 AM, Valery Ushakov wrote:
>
> On Wed, Oct 27, 2021 at 20:59:12 -0700, Jason Thorpe wrote:
>
>>> On Oct 27, 2021, at 4:01 PM, Jason Thorpe wrote:
>>>
>>>
On Oct 27, 2021, at 3:44 PM, Valery Ushakov wrote:
On Wed, Oct 27, 2021 at 07:50:55 -0700,
On Wed, Oct 27, 2021 at 20:59:12 -0700, Jason Thorpe wrote:
> > On Oct 27, 2021, at 4:01 PM, Jason Thorpe wrote:
> >
> >
> >> On Oct 27, 2021, at 3:44 PM, Valery Ushakov wrote:
> >>
> >> On Wed, Oct 27, 2021 at 07:50:55 -0700, Jason Thorpe wrote:
> >>
> >> I was wondering if it might be
> On Oct 27, 2021, at 4:01 PM, Jason Thorpe wrote:
>
>
>> On Oct 27, 2021, at 3:44 PM, Valery Ushakov wrote:
>>
>> On Wed, Oct 27, 2021 at 07:50:55 -0700, Jason Thorpe wrote:
>>
>> I was wondering if it might be easier to not put the onus onto the
>> caller and instead have a function that
> On Oct 27, 2021, at 3:44 PM, Valery Ushakov wrote:
>
> On Wed, Oct 27, 2021 at 07:50:55 -0700, Jason Thorpe wrote:
>
> I was wondering if it might be easier to not put the onus onto the
> caller and instead have a function that returns the interrupted
> ucontext (or NULL, if the pc is not
On Wed, Oct 27, 2021 at 07:50:55 -0700, Jason Thorpe wrote:
> > On Oct 18, 2021, at 9:41 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
Hi Jason,
For the purpose of supporting GCC stack unwinding, the __sigtramp_check_np
function would work as a solution.
Backporting to NetBSD-9 branch would definitely be nice as well.
Thanks,
John
On Wed, Oct 27, 2021 at 9:51 AM Jason Thorpe wrote:
>
> > On Oct 18, 2021, at 9:41 AM, John
> On Oct 18, 2021, at 9:41 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:
/*
* __sigtramp_check_np --
*
*
uwe,
I don't know much about CFI attributes. I had just assumed that
strip(1) would remove those symbols. Was that a bad assumption? I'm
still not sure if GCC unwind can use them but if they are permanent
and I took a look at gccgo, maybe it could work.
John
On Mon, Oct 18, 2021 at 12:41 PM
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
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 longer works. I don't know how to do this any
> other way. GDB
> On Oct 18, 2021, at 9:41 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.
Maybe I missed the GDB use case ... what is it that GDB needs to be able to do
here? This
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
> 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",
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
On Sat, 16 Oct 2021 at 09:12, John Marino (NetBSD) wrote:
>
> 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.
Backing
On Sat, Oct 16, 2021 at 08:11:47AM -0500, John Marino (NetBSD) wrote:
> 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.
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
> On Oct 15, 2021, at 1:19 PM, Valery Ushakov wrote:
>
> On Fri, Oct 15, 2021 at 23:14:39 +0300, Valery Ushakov wrote:
>
>> On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote:
>>
>>> Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl?
>>
>> It's been ages since
On Fri, Oct 15, 2021 at 23:14:39 +0300, Valery Ushakov wrote:
> On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote:
>
> > Is it possible for NetBSD to implement KERN_PROC_SIGTRAMP sysctl?
>
> It's been ages since I touched this area, but don't we have
> per-sigaction
On Fri, Oct 15, 2021 at 14:44:16 -0500, John Marino (NetBSD) wrote:
> 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
>
31 matches
Mail list logo
