Is it possible to get your IDE to record the module & the address?

@JDevlieghere: ping. Or are you saying you wouldn't consider landing such a change at all?

Hi Jim,
I think there's a bit of confusion going on here:
The original bug was opened by Ted Woodward, and I think his scenario was
motivated by embedded debugging. He also provided that example with a
breakpoint being set in main.

Added patch context.

In the future, can you generate patches with context (i.e. pass -U9999 to
"git diff" or "git show"), it's a lot easier to read patches with context.

Sure thing, will do.

Re-formatted

@mgorny Do your changes allow debugging both the parent and child processes after a fork?

Thanks,
What changed in SWIG 3.0.11?

Changing title as it looks like this is not a Windows-only problem: https://github.com/rust-lang/rust/issues/54126.

Maybe LLDB should use qAttached to determine if there's an active process? OpenOCD seems to implement that one correctly.

Sorry, for not catching this regression! I've checked that attaching to a standard gdbserver still worked, but was not aware of the other scenarios.

FYI - this broke at least Windows, because the default behavior of Process::WillResume() changed from success to an error and WindowsProcess does not override WillResume(). Not sure what other platforms are in the same boat.

This is what I see in the log:

<  16> send packet: $qfThreadInfo#bb
<   5> read packet: $l#6c

And here's code that generates it: https://github.com/gnu-mcu-eclipse/openocd/blob/b21ab1d683aaee501d45fe8a509a2043123f16fd/src/rtos/rtos.c#L370

Eli, I can commit this if you are busy. Just give a nod.

Tested Eli's version and was able to build all of rustc's standard library for the wasm32-... target.

I'm definitely not an expert on this part of LLVM, but to me this change seems very fragile, as it assumes things about the types of certain DAG nodes, which may be true now, but may change in the future.

Rust and Go are not the only missing languages. Looks like all of the newly-added DWARF5 language codes are not covered here.

Though... wouldn't "category_lang == valobj_lang" be a sane default behavior for any languages not mentioned specifically below?

Could we make CMAKE_INSTALL_UCRT_LIBRARIES the default when building for Windows? Would there be any downside to that?

Ping! Should I ask somebody else to review?

@rnk Can you please commit it? Thanks!

@rnk, Sounds like compiler-rt *is* a drop-in replacement for libgcc, so let's add 64-bit versions of chkstk/alloca for gcc objects.

In D14044#275303, @rnk wrote:

Here's how I understand the various functions:

• __chkstk from msvcrt: takes size in RAX, probes all pages, returns preserving all registers.
• __chkstk_ms from mingw: copies __chkstk from msvcrt
• _alloca / __chkstk from mingw: helpers for implementing C alloca() with custom conventions. They trash volatile registers (ECX/RCX), update the SP, and return a new object address in RAX.

Sorry, one more revision. Apparently chkstk needs triple underscore... <sigh>

On second thought, elimination of probe for the last page is not correct - that final push of the return address could land on the next page...
Also, I've figured out a better way to preserve eax.

After playing with this some more - it's no fun linking with gcc-generated libraries, because they actually do use __checkstk_ms, so you have to pull in libgcc as well, and end up with duplicate symbols. Let's add _chkstk as an extra, not as replacement.

Hi!
So apparently LLVM lowers alloca's of large buffers into a call to _alloca (makes sense I guess - if the buffer is larger than a page).
Why wasn't it added along with _chkstk? Is _alloca available from some other mingw library?

Dropped "-fPIC" part of the change, dropped #ifdef WIN32_ check.

Hi,
You guys seem to be the most active in compiler-rt repo. Can you please review and commit? (or suggest somebody more appropriate). Thanks!

This was committed by @rnk in r212081.

Implemented 'SEH_Epilogue' approach.

@chapuni, Which tests broke? Is there a PR?
I saw that MultiJitTest.JitPool fails, but it was failing before my change too, so I ignored it.

Hmm, something must be wrong at the MC layer. When I assemble the output of llc with gnu assembler (after replacing register numbers with names in seh directives), it seems to produce a correct .obj.

In D4081#42, @Twobit wrote:

Looks like something wrong with .pdata segment. It contains Function start address == Function end address and not always sorted by start address.

FYI - this commit broke LLVM build using win32 threads flavor of the mingw toolchain. I am getting error: 'recursive_mutex' in namespace 'std' does not name a type.
Not sure if this would be considered a problem for LLVM...

Fixed x86-64-static-relo-movl.ll and rebased.

Is 'x86_64-pc-win32-macho' a valid target? Windows 64 ABI in OSX object file seems like a weird combination.

Yes, please commit, if you don't mind running format yourself.

@rnk, ping...

Addressed review comments.

In D4081#16, @loladiro wrote:

I went and tried this out but ran into an assertion. This is odd because at that stage I wasn't actually using COFF, but rather ELF in memory for MCJIT. Maybe there's a check missing whether we are using COFF in addition to Win64? See below:

Program: C:\mingw-builds\msys64\home\kfischer\julia\usr\bin\julia.exe
File: C:/mingw-builds/msys64/home/kfischer/julia/deps/llvm-svn/lib/CodeGen/MachineInstr.cpp, Line 674

Expression: (isImpReg || Op.isRegMask() || MCID->isVariadic() || OpNo < MCID->getNumOperands() || isMetaDataOp) && "Trying to add an operand to a machine instr that is already done!"

Whoops, looks like I got .cfi_offset and .cfi_rel_offset mixed up. The original offsets in bigstructret2.ll test were actually correct.
Also, rebased on top of master.

Superceded by D4081

I ended up with an almost complete rewrite, so positing it as a new review: D4081

I've updated my patch. It should now solve your problem too.

@sanjoy, I wonder what happens with your patch in case of stack re-alignment.
Sorry, I can't figure out how to get git to apply your diff. Could you please try it on the following IR:

Looking at the llc output you provided in the bug, I notice that it spilled and emitted CFI info for XMM registers. What target was that compiled for? AFAIK, only Windows 64 ABI specifies XMMs as callee-saved. So if it was for Win64, my patch would directly address your problem.

With more context

Hi Sanjay,
Please take a look at my preliminary patch to support Win64 SEH I've put here: http://reviews.llvm.org/D4053 (specifically stuff in X86FrameLowering.cpp). Not directly related to 19905, however, it touches the same code, and could benefit from the same refactoring.

This patch doesn't work right. I am seeing stuff like this in the emitted code:

	pushq	%rbp
	.seh_pushreg %rdi

Which, I guess, makes sense, because MCAsmStreamer::EmitRegisterName performs DWARF->LLVM register index mapping before emitting the name.

@nrieck, you've said above "I believe it's not necessary to change the prologue emission for Win64". However I don't see how would one express 'and ..., %rsp' with SEH unwind instructions, because the effective RSP offset here is not a compile-time constant.

There's been much back-and-forth on the mailing list thread, so I am no longer sure which problems absolutely need to be fixed, and which were mentioned just in passing. It would be helpful to restate them in one place (here probably).

Ping... It's been a week since anything happened on this review. Is there any action that can be taken to un-stall this?