I gave this a spin with LLDB_USE_LLDB_SERVER=1, but there looks to be some pre-existing issues with the lldb-server implementation so I can't really test much normally using builds of Krita:

In D128541#3621364, @labath wrote:

Well.. most OSes don't have this kind of functionality, so we don't really have an exact match for this. I suppose the closest thing would be the way we handle darwin OS logs, so you could try to see if reusing some of that infrastructure makes sense (StructuredDataDarwinLog.cpp and surrounding code).

In D128600#3611043, @mstorsjo wrote:

I guess the more complete/proper way forward would make a mingw-w64 specific implementation of these (or some similar) functions too, if __USE_MINGW_ANSI_STDIO is set to 1. (No idea offhand how hard that would be though...)

long double is an issue though...

This is an alternative of D59525 and D59727 for mingw. I think this implementation using _vsnprintf_s_l and _vscprintf_l should replicate the expected behaviour of snprintf_l, with NULL terminator and such. @mstorsjo should be able to confirm whether These two functions are available on both UCRT and MSVCRT configuration of mingw.

It may be possible to stuff a pointer to an EXCEPTION_RECORD into another EXCEPTION_RECORD and use RtlRaiseException to generate the exception, but you'll have to test how it actually works.

Added Windows-specific test

Added test and improved setting description as suggested.

Yes, this (patch) looks right to me.

Remove old code instead of #if 0.

Any reason to #if 0 this instead of just removing it and maybe adding a one line comment like "nested exceptions are not supported"? So that someone can git blame that and find this commit with the removal.

Rebased

In D126367#3580683, @labath wrote:

Is there any difference in functionality between SymbolVendorELF and the new class introduced here? Could this have been achieved by teaching SymbolVendorELF (after renaming it to something else) to handle COFF files as well?

Does this test look good:

I suppose it is possible to have a Windows-only test for this. (Someone will need to verify them for me though as I don't have a build that runs tests on Windows.)

Rebased patch

Rebased patch

I agree with this change like I said in the linked review thread.

Ah I did not realize that GNU ld also has the option to add the same build id for mingw. I am fine with you committing these changes. Thanks!

Added the fix to the Minidump find-module test, also updated the commit message.

Thanks @mstorsjo for answering for me.

I guess you're right. MSVC's dumpbin /relocations helper.exe listed nothing at all.

Yeah, that seems fine as a workaround. https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#section-table-section-headers says:

Removed the changes for PDB, I don't think they actually affect anything.

The test https://github.com/llvm/llvm-project/blob/main/lldb/test/Shell/Minidump/Windows/find-module.test fails with this patch. That test opens a minidump and checks that the associated exe is loaded. The minidump contains a codeview PDB record for the exe which is used to generate the UUID, but the same codeview PDB record is missing from the exe. The test still worked because LLDB ignores the empty UUID (it skips the UUID equality check). However, when this patch adds a UUID using the CRC, that test fails because the UUIDs no longer match up.

Sorry, I just realized the crc change broke a test.

Applied suggested change

Thanks for the hint. I think I can add a setting, say plugin.object-file.pe-coff.abi. It needs some plumbing but should be doable.

Addressed comments, added CRC checking for debuglink (only applies if the object does not contain a PDB build id) and added tests for this.

In D126367#3560233, @DavidSpickett wrote:

Can you include some links to documentation of the debuglink feature in the commit message? I assume https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html is what you'd want.

In D127048#3559918, @mstorsjo wrote:

In D127048#3559866, @DavidSpickett wrote:

This changes the PE/COFF and PDB plugins to set the module triple according to the default target triple used to build LLDB.

I'm missing some context here but using triple used when *building* lldb seems to conflict with the idea that the same lldb (client at least) can be used to debug many architectures.

Yes, that's true. The idea here is that when doing local debugging in either the mingw or msvc ecosystems, the flavour of the lldb build itself could be a decent hint - but it's not indeed not a correct and faultproof fix.

Fixed tests again

Changed test requirement to be more accurate

Fixed tests

Debug--

Fixed loading gnu-debuglink for x86 Windows and added a test for it.

Applied suggestion to make code less clunky.

Replacing with https://reviews.llvm.org/D126898

Replacing with https://reviews.llvm.org/D126898

Changed GetPluginNameStatic to "PE-COFF", and rebased onto main.