Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
> 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 > to support the unwind is already provided, we just need the boolean (is this > a sigtramp frame?) to decide whether or not to use it. I thought Uwe's > suggestion to return the context was either an expansion for more general use > or a second function. All we have is the pc pointer. Well, getting back to a previous part of the conversation, there can be multiple kinds of contexts, either a “sigcontext” or a “ucontext_t”, and so telling you “it’s in a trampoline” isn’t necessarily useful — you need to know what kind it is. The idea behind __sigtramp_unwind_np() is that you would need less architecture-dependent logic (and that the API would be future-proof, in case the way the handlers work changes for some reason). However, Joerg correctly pointed out that the real correct solution already exists, which is to say “make sure DWARF CFA information exists for signal trampolines”, which is what I’ve been focusing on over the last couple of weeks. Only if that proves to be insufficient for some reason should we add a new non-portable API to assist unwind. DWARF unwind information doesn’t really work for FreeBSD trampolines, because the handler is supplied by the kernel, and so of course there’s not really a good way to look up the CIE / FDE for it. -- thorpej
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
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 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 a sigtramp frame?) to decide whether or not to use it. I > thought Uwe's suggestion to return the context was either an expansion for > more general use or a second function. All we have is the pc pointer. > > Well, getting back to a previous part of the conversation, there can be > multiple kinds of contexts, either a “sigcontext” or a “ucontext_t”, and so > telling you “it’s in a trampoline” isn’t necessarily useful — you need to > know what kind it is. The idea behind __sigtramp_unwind_np() is that you > would need less architecture-dependent logic (and that the API would be > future-proof, in case the way the handlers work changes for some reason). > > However, Joerg correctly pointed out that the real correct solution > already exists, which is to say “make sure DWARF CFA information exists for > signal trampolines”, which is what I’ve been focusing on over the last > couple of weeks. Only if that proves to be insufficient for some reason > should we add a new non-portable API to assist unwind. DWARF unwind > information doesn’t really work for FreeBSD trampolines, because the > handler is supplied by the kernel, and so of course there’s not really a > good way to look up the CIE / FDE for it. > > -- thorpej > >
Re: kaveri_mec2.bin file missing
Hello, Here is what I try to accomplish. I could not find the bios for the 0x1002/0x6604 device. So I thought that I could just disable this device, and use the Kaveri device (0x1002/0x1309), since I have that bios. I have put the two files listed above (by RVP) to the "src/sys/dev/microcode/radeon/" directory. I also changed the configuration to only include the radeon device that is the 0x1002/0x1309 Kaveri device. Did add the KAVERI_mec2.bin to the MODULE_FIRMWARE definitions in the radeon_cik.c file (since this was missing). But this failed to load the microcode. It does fail in the function "cik_init_microcode". I have put these bin files into "src/sys/dev/microcode/radeon/". Isn't this the correct path to put these bin files in? Are the file names in this directory case-sensitive? Although in the "src/sys/dev/microcode/radeon/" directory all the bin files begin with capital letters (KAVERI_mec.bin for instance). Also in the file radeon_cik.c there are MODULE_FIRMWARE declarations/definitions that have both KAVERI_*.bin files and kaveri_*.bin files. And the KAVERI_mec2.bin file was missing in that list, in which all the files start with KAVERI (with capital letters). Should this entry not be there? Although I tried it both ways. Adding KAVERI_mec2.bin in the MODULE_FIRMWARE definitions. And tried it also by removing that entry. It did not change anything. I might have not put these files in the correct directory maybe. Am I missing something? On Sun, Nov 21, 2021 at 9:20 AM Riza Dindir wrote: > > Thanks, I will copy both files to "src/sys/dev/microcode/radeon/" on > my system. Although "kaveri_mec.bin". > > Regards > Riza > > On Sun, Nov 21, 2021 at 12:29 AM matthew green wrote: > > > > Riza Dindir writes: > > > Hello > > > > > > I am using NetBSD 9.2 (amd64). Am trying to make the radeon driver work. > > > > > > In the file "sys/external/bsd/drm2/dist/drm/radeon/radeon_cik.c", > > > there is a reference to a kaveri_mec2.bin file. But this file is not > > > present in the "src/sys/dev/microcode/radeon/" directory. Is it > > > possible to comment out the reference to kaveri_mec2.bin? > > > > copy this out of the upstream "linux-firmware" package: > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/ > > > > we're planning on updating these files for netbsd-10, but for > > now this is the right process. > > > > > > .mrg.
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
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 a sigtramp frame?) to decide whether or not to use it. I thought Uwe's suggestion to return the context was either an expansion for more general use or a second function. All we have is the pc pointer. In the original post, I provided two implementations (current freebsd, former netbsd) of the gcc unwinding. Maybe I'm missing how __sigtramp_unwind_np is supposed to be used there. All I was asking for was to pass pc (context->return_address) and get a boolean answer if it were inside a signal trampoline. The rest is already done. Thanks, John On Sun, Nov 14, 2021 at 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_unwind_np returns null or not. > > This would not work for the gdb unwinder — it only works for unwinding > from within the same process, so for exception handling, etc. I.e. if the > unwinder in the compiler runtime wasn’t able to process the DWARF call > frame info for the signal trampoline, for example. The gdb unwinder may > have to operate on a process that’s no longer running (and, at the very > least, is not the current process), so it needs to rely only on DWARF call > frame info and/or heuristics based on the symbol name (which I added to gdb > quite some years ago now). > > The requirements for using this are: > > ==> In the frame that represents the handler itself, you are able to get > the return address the handler will return to. > > ==> In that same frame, you can compute what the stack pointer should be > when the handler returns (by either inspecting the instructions in the > function prologue that setup the handler’s stack frame, or by parsing the > DWARF call frame info). > > It’s that return address and stack pointer that you would pass to > __sigtramp_unwind_np(). > > Then the context returned by __sigtramp_unwind_np() would allow you to > then get the stack pointer, PC, etc. for the context that would be resumed > after the handler returns (because remember, signals can run on their own > stack). > > So, this is a little more than just “is this PC in the signal > trampoline?”. This is “If this PC is in the signal trampoline, then return > a pointer to the context that will be restored when the signal returns, > given this SP.” This was uwe’s suggestion. > > I can still expose just __sigtramp_check_np(), but the assumption was that > you would use a “YES!” result from that to to off an find the > context-to-restore… so we decided to encapsulate some of that work for you > as well. Does that make sense? > > If that assumption about how you would use __sigtramp_check_np() is > invalid, please let me know so I can adjust the proposal. > > -- thorpej > >
Re: kaveri_mec2.bin file missing
Riza Dindir wrote: >I have put the two files listed above (by RVP) to the >"src/sys/dev/microcode/radeon/" directory. I also changed the >configuration to only include the radeon device that is the >0x1002/0x1309 Kaveri device. Did add the KAVERI_mec2.bin to the >MODULE_FIRMWARE definitions in the radeon_cik.c file (since this was >missing). But this failed to load the microcode. It does fail in the >function "cik_init_microcode". > >I have put these bin files into "src/sys/dev/microcode/radeon/". Isn't >this the correct path to put these bin files in? It is the correct source directory for Radeon microcode files, unless you have added something to the Makefile they won't get copied to the destination directory which is /libdata/firmware/radeon. You could just copy files from the linux-firmware tree to /libdata/firmware/radeon to test things. >Are the file names in this directory case-sensitive? Although in the >"src/sys/dev/microcode/radeon/" directory all the bin files begin with >capital letters (KAVERI_mec.bin for instance). The filenames are case sensitive, you can see that the files are not the same. % diff -b KAVERI_me.bin kaveri_me.bin Binary files KAVERI_me.bin and kaveri_me.bin differ I would expect to use either the KAVERI* or the kaveri* files as a set.
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
> 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 DWARF unwind information: 12 .eh_frame_hdr 01a4 0001200077f0 0001200077f0 77f0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 13 .eh_frame 07a4 000120007998 000120007998 7998 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 12 .eh_frame_hdr 01a4 0001200077f0 0001200077f0 77f0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 13 .eh_frame 07a4 000120007998 000120007998 7998 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA I.e. strip does not effect the unwind information, because unwind information is not debugging information nor is it part of the symbol information; it is, in fact, required for correct operation of the program in the face of exceptions. And my test program still works: alpha-vm:thorpej 22$ ./test1 ^Cx 2 Backtrace 4 stack frames. 0x1200014e4 <_init+0x304> at ./test1 0x3fffdddbfd4 <__sigtramp_siginfo_2> at /usr/lib/libc.so.12 0x1200015e4 <_init+0x404> at ./test1 0x120001590 <_init+0x3b0> at ./test1 As you can see, because I stripped the symbols out of the program binary, the symbol names are wrong, but the unwind works and the program counter values are the same as an un-stripped copy of the program: alpha-vm:thorpej 23$ ./sigbttest ^Cx 2 Backtrace 4 stack frames. 0x1200014e4 at ./sigbttest 0x3fffdddbfd4 <__sigtramp_siginfo_2> at /usr/lib/libc.so.12 0x1200015e4 at ./sigbttest 0x120001590 at ./sigbttest So, I think your worry about it is unwarranted. >> On Nov 21, 2021, at 7:54 AM, John Marino (NetBSD) wrote: >> >> >> I'm not very familiar with CFA information. I've been worried that strip(1) >> removes those symbols. Is that worry meritless? -- thorpej
Re: Request for implementation of KERN_PROC_SIGTRAMP sysctl
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 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 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 a sigtramp frame?) to decide whether or not to use it. I >> > thought Uwe's suggestion to return the context was either an expansion for >> > more general use or a second function. All we have is the pc pointer. >> >> Well, getting back to a previous part of the conversation, there can be >> multiple kinds of contexts, either a “sigcontext” or a “ucontext_t”, and so >> telling you “it’s in a trampoline” isn’t necessarily useful — you need to >> know what kind it is. The idea behind __sigtramp_unwind_np() is that you >> would need less architecture-dependent logic (and that the API would be >> future-proof, in case the way the handlers work changes for some reason). >> >> However, Joerg correctly pointed out that the real correct solution already >> exists, which is to say “make sure DWARF CFA information exists for signal >> trampolines”, which is what I’ve been focusing on over the last couple of >> weeks. Only if that proves to be insufficient for some reason should we add >> a new non-portable API to assist unwind. DWARF unwind information doesn’t >> really work for FreeBSD trampolines, because the handler is supplied by the >> kernel, and so of course there’s not really a good way to look up the CIE / >> FDE for it. >> >> -- thorpej >>
