LGTM, although I'm not sure if me saying that is enough. I'll commit this in few days if nobody says anything else.

I tried pretty hard to get a small repro for these failures, but couldn't.

In D86416#2286333, @JDevlieghere wrote:

Which tests are affected by this?

Ping.

Closing, I forgot to add the "Differential Revision:" line, but D86593 landed sooner anyway.

Ping.

Funny coincidence, the ctor has been broken for 5 years and that commit introducing my problem has been there for a year. Ok, closing, thank you for your help.

No, everything's fine :). See the updated patch. The UnwindPlan object already enters x86AssemblyInspectionEngine::AugmentUnwindPlanFromCallSite() with the lazybool uninitialized and fixing that fixes everything:

And it indeed was suspicious. 3fd917d8860e9bdcabc14c536da4377307906be0 didn't update the UnwindPlan copy ctor to copy the field.

In D86417#2239062, @JosephTremoulet wrote:

and let me know how that goes? I don't have a linux system here to try it on, but I have a feeling this may fix the problem you're seeing.

In D86417#2237602, @jasonmolenda wrote:

lldb thinks that both frames 1 & 2 are trap handler frames. They have full register context available for the frame above them on the stack (that is, frames 2 & 3) and frames 2 & 3 were interrupted asynchronously. This doesn't sound right? How do we decide what is a trap handler frame? One way is to look for the 'S' augmentation in the eh_frame / dwarf debug_frame CIE/FDE for the function -

...

The other way is from the Platform CalculateTrapHandlerSymbolNames method. PlatformLinux sets these to

...

is one of these wrong?

In D86417#2236337, @JosephTremoulet wrote:

And its parent 'raise' is set so as well because of 'GetNextFrame()->m_frame_type == eTrapHandlerFrame '.

Sorry, can you clarify what code path you're referring to here? I see two occurrences of GetNextFrame()->m_frame_type == eTrapHandlerFrame in the code, and three occurrences of m_frame_type = eTrapHandlerFrame, but it's not clear how one of the former leads to one of the latter, or if I'm misunderstanding what you're saying.

In D86416#2232966, @teemperor wrote:

Out of curiosity, will this also fix the TestPluginCommands.py ?

Updated to not use environment variable.

Ping.

Change also SetBackground() calls.

Use SteamString.

I personally don't particularly care where the tests are, I just wanted all the gui tests to be together to make it simpler to run them all.

Updated according to comments.

In D85145#2192716, @teemperor wrote:

I wonder if there is a reasonable way to test this. From what I understand these attributes aren't in any output buffer that we could expect (e.g., with a pexpect test).

In D85145#2191421, @teemperor wrote:

Btw, the highlighter supports any kind of delimiter string when 'highlighting' source. So you could add a parameter for a custom highlighter too and then pass a more convenient highlighter 'style' in to make the parsing simpler. See the only call MakeVimStyle (which generates the style that adds the color escapes) and the HighlighterStyle where you can set any kind of delimiter.

Handle properly also the "<<< Thread 1: breakpoint 1.1" marker.

Removed use of curses python module, lldbexpect hardcodes TERM=vt100, so the escape sequence should be actually hardcoded too. The previous version didn't work e.g. in Linux console.

In D85090#2189549, @dblaikie wrote:

Including <cstdint> is probably more correct - the clang warning points to the Flags module as one module that defines the typedef, but because this is probably being tested against an unmodularized standard library, the module chosen is somewhat arbitrary/not directly relevant to the issue (it's just one module that itself happens to include <cstdint> or some other standard header that pulls in a definition of uint16_t )

The DWARF in the source file appears to be broken, the test fails for me on openSUSE 15.2 x86_64, with errors about DIE references outside of its CU. It fails even if I try to manually compile and debug the file, with Clang git or 9, GCC 7.5 or 9, LLDB git or 9, GDB 9.2.

Adjusted according to the comments.

Updated for current git.

Updated for current git, and clang-format-ed.

Updated for current git, and clang-format-ed.

In D68908#2174222, @clayborg wrote:

If removing 'd' was only to make it available for "up" and "down" in https://reviews.llvm.org/D68541, then maybe we should switch 'D' to "detach and let run? Or is that what we did, but the comment on line 4331 is now out of date?

My usual experience with Clang submissions is that I have to be really persistent to get a reaction, let alone an approval, so I assumed it was the same here and I didn't feel like pushing this that much. I'll update the patches to match current git and have a look at the review that still has questions.

Updated driver test to just create a dummy file for PCH.

@llunak Would you be able to test this on anything you've got?

Used OptInFFlag and adapted to changes in D83716.

Moved driver test under test/Driver/.