I and Jason discussed this offline and he's fine with it, so, I'm going to land this now.

LGTM. It would be great if we can add a test.

LGTM

More than error handling, this allows us to distinguish with a type with zero alignment (if possible at all?) and an error getting the alignment from ASTContext/

Did you manage to file a rdar for this issue? If so, can you put the link here for future archeology?

I think this is definitely a good idea but Chandler or DBlaikie might want to take a look at this one too.

I seem to remember there was a bug where you run the expression twice and the second time it crashes/it's not evaluated correctly [at least this is what I remember talking to Lang ~18 months ago].
If that works, yay for more coverage!

You might want to check with Argyrios, maybe file a rdar against SourceKit.
Otherwise, this is fine to me.

In D65782#1615959, @alex wrote:

I was marked as a review on this, but I suspect you intended to get some other Alex :-)

Thanks!

[and Raphael for the clang vendor bits]

Really on the lldb side, Jonas is the right person to review this patch.

Other than that, I have no objections.

I wanted to remove it a while ago, but Jason told me he found this useful, so I would wait for his opinion.

LGTM.

Minor otherwise LGTM

See if you can write a pexpect test, as Pavel suggested.

No brainer.

This is good for now. I would add a comment explaining what you explained in the differential at the beginning of the macro section.
Great work!

I don't think it's worth adding a test for the logs.

This looks good. If it bothers you a lot (given you're probably one of the few users), you can do this only under verbose (although now that's a single line is very concise).

That real

LGTM. Thanks. I fear this might break some bots, but the best way to see if that's the case is trying.

This seems fairly straighforward and I'm in favor of it. We maybe should do the same thing with swift, I haven't checked in a while how we call the file there.
I wouldn't bother adding a test for something so minor.

Yeah, I'd rather have an explicit communication between debugger and debuggee.
We tried to put sleeps in the code [for e.g. lldb-mi tests in the past] and they end up failing anyway sporadically, which makes a pain to track the problem down.

This is adding a fair amount of complexity on something that just works fine on basically every platform but AIX.
If AIX has issue with psutil, maybe the fix should be submitted to psutil upstream instead of having this dance here?

Sorry for the long delay. I'm happy with this going in. @efriedma ?

LGTM

I thought about this a little more, and we discussed offline, but these are my two comments (we should understand what's the behaviour and add tests). We can address some of them as follow-up but I would like to understand what happens here.

Address feedback from many.

In D63745#1556941, @labath wrote:

This code should go to tools/debugserver/source/CMakeLists.txt so that it is next to the code which performs the actual code signing. Doing that will make it easier to keep it in sync with changes to code signing, as well as make it obvious that it is not in sync with them right now (there's a pretty complex interaction of various cmake options (LLDB_CODESIGN_IDENTITY, LLVM_CODESIGNING_IDENTITY, LLDB_USE_SYSTEM_DEBUGSERVER, etc.) which affects code signing, and this code is ignoring all of those)...

rdar://problem/52078735

LGTM.

In D63488#1548991, @probinson wrote:

I see the point; certainly when someone emails a patch, the first response is almost always "can you put this on Phab."

There was talk at some point about connecting Phab with github authentication, somehow? If people can use an existing account then the you-need-to-register-first objection goes away.