- User Since
- Oct 2 2020, 4:40 PM (139 w, 4 d)
Jan 2 2022
Use a while loop.
Dec 29 2021
I don't have commit access. Could you push it for me, please?
Dec 28 2021
Dec 7 2021
I've opened https://github.com/freebsd/freebsd-src/pull/570 for that.
Dec 5 2021
Could you push this for me, as I don't have push access?
Nov 7 2021
Apr 24 2021
It works for me, thanks!
Apr 23 2021
Superseded by D29955.
Disable coredump compression for the time being.
Switched to td_dbgflags. Removed unnecessary OOM handling. Added locking for TDF_ASTPENDING update.
Hmm, this makes me wonder if we're not going to hang if we're trying to get a coredump from a thread that's PT_SUSPEND-ed.
Thanks for the input, I'll do that in a minute. In the meantime, I've been thinking how to unsuspend one thread only. A primitive solution I can think of is using both process and thread flags, and assuming that if P2_COREDUMP is set, then only threads having TDF_COREDUMP are resumed.
Apr 22 2021
Update keep state per thread, on the thread explicitly requested via ptrace(2) and malloc-ed rather than inline.
I'm sorry, I've had a newer version locally but I've forgotten to update the diff here. Lemme implement the newest comments, retest and update.
Apr 20 2021
Enable enabling coredump per LWP. It mostly works — when passed PID, or LWPIDs of two spawned threads. However, if I pass the LWPID of the initial thread, the test program hangs (haven't verified if it's hanging in ptrace() yet or somewhere else).
First working version, with ability to set coredump size limit.
Ok, so apparently I'm hitting this condition:
Apr 19 2021
Thanks for your suggestions. I've had to make a few modifications, particularly regarding addr and data use.
Apr 18 2021
Ok. I'd use a few more pointers. I think I'm supposed to add a flag to td_flags (reusing one of the values marked as unused?), add new fields to struct proc to pass the necessary data, and then do the work inside ast() function. What I can't figure out is how to block the ptrace(2) call and trigger the context switch.
Apr 17 2021
Apr 15 2021
Ok, so I was trying to reimplement it to write into a fd. I've managed to make it successfully dump the core... of the debugger ;-). However, when I tried to make it dump the right core, my guesswork lead me to this version… which unfortunately panics:
Apr 14 2021
Apr 13 2021
@kib, so if I agree with the FD approach, is there anything left to decide? If not, could you start giving me some pointers?
Apr 11 2021
Passing of a file descriptor was something I've been considering initially but using the path was an easier way to get a working prototype. I suppose we can switch to using an fd (passed via data, I guess?) to make things simpler and more robust. Since we lose any compatibility with NetBSD, we can also rename it to PT_COREDUMP.
Apr 10 2021
Mar 30 2021
Feb 14 2021
Thanks, I was able to get working hardware watchpoints with this patch.
Feb 12 2021
Feb 11 2021
Feb 10 2021
Thank you. I get the correct number of watchpoints now ;-). I'm going to test them fully in the next few days and report back.
Feb 9 2021
Ok, I'm starting to test this applied on top of 13.x and something seems off:
Jan 30 2021
It seems to work for me. Thanks!
Jan 29 2021
Since you're breaking ABI anyway, could you maybe future-proof it by using data to pass sizeof(dbreg)? This would permit to add extra fields in the future without risking buffer overflows in clients.
Jan 27 2021
FYI, I believe that this commit broke the kernel on MIPS64, at least via qemu: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253051
Dec 28 2020
Dec 14 2020
Does this look fine?
Dec 10 2020
Sure, this makes sense.
Updated as requested. Note that this shouldn't be probably pushed yet, as it could confuse users before LLVM 12.0.0 is released.
Dec 9 2020
Oct 21 2020
Oct 20 2020
Fixed per review comments.
Oct 19 2020
- I'm wondering if there's a common place we could move this function too not to duplicate it.
- I suppose we could use a packed struct to look at the float80 instead of pointer hacks.
Oct 3 2020
I can confirm that the patch fixes the LLDB problem too!
I'm currently building the kernel with the new version and I should have some test results in an hour or so.
Oct 2 2020
Sure. Here you are:
To be honest, I think you can call 32-bit version for 32-bit programs unconditionally, independently of CPUID_STDEXT_NFPUSG. After all, 32-bit programs use 32-bit addresses, so they always fit in the shorter form.