Page MenuHomeFreeBSD

mgorny_gentoo.org (Michał Górny)
User

Projects

User does not belong to any projects.

User Details

User Since
Oct 2 2020, 4:40 PM (37 w, 1 d)

Recent Activity

Apr 24 2021

mgorny_gentoo.org added a comment to D29955: ptrace(PT_COREDUMP).

It works for me, thanks!

Apr 24 2021, 9:07 AM

Apr 23 2021

mgorny_gentoo.org added inline comments to D29955: ptrace(PT_COREDUMP).
Apr 23 2021, 9:47 PM
mgorny_gentoo.org abandoned D29691: ptrace: Add PT_COREDUMP request (WIP).

Superseded by D29955.

Apr 23 2021, 9:04 PM
mgorny_gentoo.org added inline comments to D29955: ptrace(PT_COREDUMP).
Apr 23 2021, 9:04 PM
mgorny_gentoo.org updated the diff for D29691: ptrace: Add PT_COREDUMP request (WIP).

Disable coredump compression for the time being.

Apr 23 2021, 8:32 AM
mgorny_gentoo.org updated the diff for D29691: ptrace: Add PT_COREDUMP request (WIP).

Switched to td_dbgflags. Removed unnecessary OOM handling. Added locking for TDF_ASTPENDING update.

Apr 23 2021, 8:02 AM
mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).

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.

Apr 23 2021, 7:34 AM
mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).

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 23 2021, 6:35 AM

Apr 22 2021

mgorny_gentoo.org updated the diff for D29691: ptrace: Add PT_COREDUMP request (WIP).

Update keep state per thread, on the thread explicitly requested via ptrace(2) and malloc-ed rather than inline.

Apr 22 2021, 1:42 PM
mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).

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 22 2021, 1:13 PM

Apr 20 2021

mgorny_gentoo.org added inline comments to D29691: ptrace: Add PT_COREDUMP request (WIP).
Apr 20 2021, 7:49 PM
mgorny_gentoo.org updated the diff for D29691: ptrace: Add PT_COREDUMP request (WIP).

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).

Apr 20 2021, 2:32 PM
mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).
In D29691#670121, @kib wrote:

I suspect that my code might cause more than one thread to observe P2_COREDUMP, BTW. I believe something more involved needs to be done: either the flag should be set for specific thread, or the first thread that observes the flag in AST should clear it, and then you need some other flag (?) to sync this thread with debugger.

Apr 20 2021, 1:52 PM
mgorny_gentoo.org updated the diff for D29691: ptrace: Add PT_COREDUMP request (WIP).

First working version, with ability to set coredump size limit.

Apr 20 2021, 1:49 PM
mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).

Ok, so apparently I'm hitting this condition:

Apr 20 2021, 9:04 AM

Apr 19 2021

mgorny_gentoo.org updated the diff for D29691: ptrace: Add PT_COREDUMP request (WIP).

Thanks for your suggestions. I've had to make a few modifications, particularly regarding addr and data use.

Apr 19 2021, 7:08 PM

Apr 18 2021

mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).

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 18 2021, 5:23 PM

Apr 17 2021

mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).
In D29691#668838, @kib wrote:

And what is the panic message? I have to guess?

Apr 17 2021, 9:08 PM

Apr 15 2021

mgorny_gentoo.org updated the diff for D29691: ptrace: Add PT_COREDUMP request (WIP).

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 15 2021, 10:36 PM

Apr 14 2021

mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).
In D29691#667586, @kib wrote:

I'm personally not a fan of doing more in kernel space than is absolutely necessary

Agreed, but we already have the ability to compress core dumps in the kernel so it is probably straightforward to plumb it through into this interface.

It does not require any plumbing, compression just happens if elf sv_coredump is called and compression is enabled. It indeed should be connected to some argument if we want to manage it manually for PT_COREDUMP.

May be more interesting option is the control over errors when dumping segments. Right now code exits the dump if some segment cannot be read (this could happen if e.g. file was mapped and then truncated). It is reasonable to add a tweak to skip the rest of the segment and move ahead.

Apr 14 2021, 6:38 PM
mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).
In D29691#667524, @kib wrote:

@kib, so if I agree with the FD approach, is there anything left to decide? If not, could you start giving me some pointers?

I suppose the first thing to do would be splitting the 'core' of coredump() function dealing with the fd, correct?

I do not think that passing fd as data is a wise idea. It probably makes sense to define a structure that gets a pack of arguments for the call, one of them fd.

Apr 14 2021, 4:18 PM

Apr 13 2021

mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).

@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 13 2021, 4:52 PM

Apr 11 2021

mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).

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 11 2021, 6:50 AM

Apr 10 2021

mgorny_gentoo.org added a comment to D29691: ptrace: Add PT_COREDUMP request (WIP).
In D29691#665860, @kib wrote:

coredump(9) cannot work this way. It assumes that td == curthread, and that all other threads are stopped.

Apr 10 2021, 4:18 PM
mgorny_gentoo.org added inline comments to D29691: ptrace: Add PT_COREDUMP request (WIP).
Apr 10 2021, 11:42 AM
mgorny_gentoo.org requested review of D29691: ptrace: Add PT_COREDUMP request (WIP).
Apr 10 2021, 11:40 AM

Mar 30 2021

mgorny_gentoo.org added a comment to D29496: x86: clear %db registers in new process.

Do you know what Linux does?

Mar 30 2021, 7:09 PM
mgorny_gentoo.org added a comment to D29496: x86: clear %db registers in new process.
In D29496#661038, @kib wrote:

Clearing %db registers seems to be the right thing to do for forked process.

What is the opinion about new thread? Should we inherit or clear db state? [Patch currently clears]

Mar 30 2021, 4:23 PM

Feb 14 2021

mgorny_gentoo.org added a comment to D28561: arm64: handle watchpoint exceptions from EL0.

Thanks, I was able to get working hardware watchpoints with this patch.

Feb 14 2021, 1:11 PM

Feb 12 2021

mgorny_gentoo.org added inline comments to D28561: arm64: handle watchpoint exceptions from EL0.
Feb 12 2021, 6:07 PM

Feb 11 2021

mgorny_gentoo.org added inline comments to D28561: arm64: handle watchpoint exceptions from EL0.
Feb 11 2021, 9:49 PM

Feb 10 2021

mgorny_gentoo.org added a comment to D28415: arm64: extend struct db_reg to include watchpoint registers.

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 10 2021, 5:11 PM

Feb 9 2021

mgorny_gentoo.org added a comment to D28415: arm64: extend struct db_reg to include watchpoint registers.

That's because extract_user_id_field returns a default value of 0 for the watchpoint count field.

Feb 9 2021, 5:39 PM
mgorny_gentoo.org added a comment to D28415: arm64: extend struct db_reg to include watchpoint registers.

Ok, I'm starting to test this applied on top of 13.x and something seems off:

Feb 9 2021, 2:18 PM

Jan 30 2021

mgorny_gentoo.org added a comment to D28424: mips: fix early kernel panic when setting up interrupt counters.

It seems to work for me. Thanks!

Jan 30 2021, 9:16 AM

Jan 29 2021

mgorny_gentoo.org added a comment to D28415: arm64: extend struct db_reg to include watchpoint registers.

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 29 2021, 4:50 PM

Jan 27 2021

mgorny_gentoo.org added a comment to D27844: make maximum interrupt number tunable on ARM, ARM64, MIPS, and RISC-V.

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

Jan 27 2021, 8:34 PM

Dec 28 2020

mgorny_gentoo.org updated the diff for D27524: Developer's Handbook: add a section on remote debugging via LLDB.

Updated per @ygy/@emaste's suggestions.

Dec 28 2020, 4:14 PM
mgorny_gentoo.org added inline comments to D27524: Developer's Handbook: add a section on remote debugging via LLDB.
Dec 28 2020, 9:20 AM

Dec 14 2020

mgorny_gentoo.org updated the diff for D27524: Developer's Handbook: add a section on remote debugging via LLDB.

Does this look fine?

Dec 14 2020, 11:55 AM

Dec 10 2020

mgorny_gentoo.org added a comment to D27524: Developer's Handbook: add a section on remote debugging via LLDB.

Sure, this makes sense.

Dec 10 2020, 2:24 PM
mgorny_gentoo.org added a comment to D27524: Developer's Handbook: add a section on remote debugging via LLDB.
In D27524#615445, @bcr wrote:

Updated as requested. Note that this shouldn't be probably pushed yet, as it could confuse users before LLVM 12.0.0 is released.

But it does say "... starting with LLDB 12.0.0", so the confusion would be minimal, right?

Dec 10 2020, 12:57 PM
mgorny_gentoo.org added a comment to D27524: Developer's Handbook: add a section on remote debugging via LLDB.

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 10 2020, 12:46 PM
mgorny_gentoo.org updated the diff for D27524: Developer's Handbook: add a section on remote debugging via LLDB.
Dec 10 2020, 12:45 PM

Dec 9 2020

mgorny_gentoo.org requested review of D27524: Developer's Handbook: add a section on remote debugging via LLDB.
Dec 9 2020, 5:25 PM

Oct 21 2020

mgorny_gentoo.org added a comment to D26856: Improve FPU Tag Word reconstruction on i386 to indicate register states.

Thank you!

Oct 21 2020, 7:07 AM

Oct 20 2020

mgorny_gentoo.org updated the diff for D26856: Improve FPU Tag Word reconstruction on i386 to indicate register states.

Fixed per review comments.

Oct 20 2020, 8:53 PM
mgorny_gentoo.org updated the summary of D26856: Improve FPU Tag Word reconstruction on i386 to indicate register states.
Oct 20 2020, 6:02 PM

Oct 19 2020

mgorny_gentoo.org updated the summary of D26856: Improve FPU Tag Word reconstruction on i386 to indicate register states.
Oct 19 2020, 11:30 AM
mgorny_gentoo.org added a comment to D26856: Improve FPU Tag Word reconstruction on i386 to indicate register states.

That said:

  1. I'm wondering if there's a common place we could move this function too not to duplicate it.
  2. I suppose we could use a packed struct to look at the float80 instead of pointer hacks.
Oct 19 2020, 11:30 AM
mgorny_gentoo.org requested review of D26856: Improve FPU Tag Word reconstruction on i386 to indicate register states.
Oct 19 2020, 11:29 AM

Oct 3 2020

mgorny_gentoo.org added a comment to D26643: amd64 Store full 64bit of FIP/FDP for 64bit processes when using XSAVE..

I can confirm that the patch fixes the LLDB problem too!

Oct 3 2020, 6:13 PM
mgorny_gentoo.org added a comment to D26643: amd64 Store full 64bit of FIP/FDP for 64bit processes when using XSAVE..

I'm currently building the kernel with the new version and I should have some test results in an hour or so.

Oct 3 2020, 6:04 PM

Oct 2 2020

mgorny_gentoo.org added a comment to D26643: amd64 Store full 64bit of FIP/FDP for 64bit processes when using XSAVE..

Sure. Here you are:

Oct 2 2020, 8:04 PM
mgorny_gentoo.org added a comment to D26643: amd64 Store full 64bit of FIP/FDP for 64bit processes when using XSAVE..

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.

Oct 2 2020, 4:47 PM