Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

2021-10-16 Thread John Marino (NetBSD)
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 accomplishes the same thing?
For example, call it KERN_PROC_SIGTRAMPS.  The first time it's called
with a null oldp argument to get the result size, and the second time
it's called with a properly sized buffer that is returned filled with
address ranges like an array, one range for each defined signal tramp.

It would be up to the program to iterate through the ranges to
determine if a stack pointer is within a signal tramp range.
And the gcc unwinder could be designed to only have to call it those 2
times since the result is static per process.

John


Questions about kernel driver for Radeon r7 m265

2021-10-16 Thread Riza Dindir
Hello,

I have a laptop that is using the NetBSD9.2 amd64 system. The laptop
has a radeon r7 m265 graphics card on it.

I am trying to revise the code for the kernel driver for the radeon
graphics card that I have on my laptop. I have a question regarding
the bus_space_* functions. Would this be the appropriate list to ask?

Regards,
Riza Dindir


Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl

2021-10-16 Thread Martin Husemann
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.

Is that compiler using libc at all?

You could make the address ranges available via library functions (or maybe
they already have usable symbol names, I didn't check).

Martin