Could you also add the switch test case from PR48812?

• Add testcase from PR48812

• Match comment to code

• Cast the terminator, not the block

This is meant to address a regression from rG7f69860243e8, which moved a check for whether dynamic cast to BranchInst succeeds in UnrollLoop from before to after the call to peelLoop. Adding a check to canPeel seemed like the most logical option to me.

• Fix comment

OK, I believe this is correct now.

• Ignore old modules not in target list

• Expand logging as suggested in D89157

But then you get to a point where you shouldn't really have multiple modules replacing a single one so you aren't really sure what to do about it. That part makes me a little uneasy.

Thanks for the review!

I'd been hoping to get this bugfix into 11.0.1, but it (and D89156, which is just some cleanup that occurred to me while working on this code) have been stalled for a few weeks, and I don't have any insight into the reason. If there's anything i can do to help either one along, please let me know. One idea I had is that I could rebase this on master so it doesn't depend on the other, would that help?

Ping

In D89156#2328772, @jingham wrote:

IIUC, the problem with ReplaceModule will get fixed in a dependent patch, right? So the last bit of this patch will get cleaned up by that change. If that's right, then this LGTM.

• Comment new parameter

Thanks for the speedy review! I've updated it to include a testcase that shows the problem you described, and include the fix you suggested.

• Handle finding wrong version before right one

Yeah, the potential for quadratic explosion is why I didn't hook this flag up to expensive checks when I added it. It occurs to me now that if we want, we could presumably have some cutoff counter so that after inserting 300 instructions or whatever limit is reasonable, we start hashing normally. We'd have to empty the table and repopulate it with the normal hash when we cut over, but that should be doable I think (it's similar to what the table does internally when it grows).

To clarify, the failure did not reproduce for me in the SUSE 15.02 container. I don't know what I'm doing differently. To create the environment, I just did docker run ... opensuse/leap:15.2, and then zypper in gcc-c++ python3-devel inside the container.

FWIW, I tried running the test in an SUSE 15.2 docker container (on an Ubuntu 18.04 host), and here's what I'm seeing. raise and abort indeed do not indicate that they had the S set in the augmentation:

eh_frame augmented UnwindPlan:
...
This UnwindPlan is for a trap handler function: yes.

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

LGTM, thanks.

• Use invalid_argument error code

• Change signature to return Expected<vector<BreakpointSP>>

• Rebase
• Use Twine instead of formatv

• punctuation fixes

• Move test

• Remove TODO, lit-ify negative test and tighten check

• ...and fix namespace...

• Fix Expected<> types

• Apply review feedback (-auto, -memset, +comments)

In D68096#1706258, @clayborg wrote:

If this patch is solely meant to fix this issue, then I remove my "Requires Changes" and this patch is good to go if it no longer hangs LLDB.

Just to make sure I'm understanding the feedback correctly, I'll try to summarize. Please let me know if this is off track:

Added Exception stream to minidump-basic.yaml as suggested.

• Remove useless comment and leftover debugging cruft

• Update test input yaml Exception stream

• Rebase
• Add testcase

In D68657#1703752, @labath wrote:

Therefore I think it would make sense to just spell out each member of that array as a separate member in the yaml representation, which should be a much simpler endeavour. We can use the "actual parameter count" field to suppress the fields that don't contain any value, if they really are zero, which should make the yaml output concise in the usual cases. I think something like this should be sufficient:
...
I think that would strike a good balance between code complexity, output brevity, and being able to generate interesting and potentially invalid inputs for other tools (which is one of the main goals of yaml2obj, and so interpreting the input too strictly is not desired/helpful).

• Add test with extraneous parameter

• Change Exception Information format per feedback

In D68656#1703711, @labath wrote:

Hmm.. maybe just keep those constants defined in lldb somewhere (e.g. right next to or inside the RefreshStateAfterStop function)? That's the place which does the decoding and also includes the OS switch, so it makes it easier to explain their purpose and why they are different for each OS...

• Define DumpRequested constant in-line, per feedback in D68656

• Remove ExceptionCode enumeration