Do you have CMake commands that scudo causes build breakage on Armv7?

No issues with the patch. If you want to get it enabled on Linaro's lldb bots, email linaro-toolchain@lists.linaro.org and one of us will set it up for you.

So the better solution may be along the lines of a register formatting plugin that depends on TypeSystemClang.

I suppose it just depends on what you're trying to do, which I realize may not be the most helpful advice but I hope that with enough examples it becomes at least a little more clear how things in lldb are currently done...

But the command interpreter doesn't "depend" on these plugin commands, it

just vends them.

Landed as https://github.com/llvm/llvm-zorg/commit/04492075e696a126bf69967df3489f83eb77bd50.

Landed as https://github.com/llvm/llvm-zorg/commit/bb4152335dd9f16b0f679856bafed8434134a70b.

@dmgreen Okay, I rebased onto main and submited via arc. I hope this did the right thing, but it doesn't look broken. I guess my mistake in the other patch was to create a merge commit instead of rebasing. For future reference, I'll just always squash into in commit.

Use std::any_of.

Put back isVPTPredicableCDEInstr that I didn't move over.

This will perform probably slightly worse than repeated calls but that wasn't a concern in the first place, and is much easier to scan by eye if we needed to audit this function.

On second thought, let's refactor a bit.

Is this policy documented anywhere? Perhaps you can update one of the design pages if it isn't already there.

Remove the need for regex, with the tradeoff that you need
the X86 backend which is pretty common to have.

On second thought I think you can do this without XML, I'll figure that out.

The non XML way to do this is just reading bogus register names (and is already tested). However that's all or nothing so it doesn't prove that when there is a mix of available and unavailable registers the command works correctly.

It's not in that dir because it's testing how the register command handles missing registers, rather than how the gdb client does. It assumes that the gdb client is correctly doing its job.

ping!

On the subject of not using TypeSystemClang, looking around it seems like TypeSystem is purely used to look up basic types, never to make new ones. When new types are made the code asks the TypeSystem for its TypeSystemClang and then uses that to do it.

If anyone needs to figure out why these opt out, I hope a git blame and reading the commit message will be enough info. Let me know if I should include anything else.

Use LOG instead of LOGF.

Use LOG instead of LOGF.

Landed as https://github.com/llvm/llvm-zorg/commit/cf2edff0be6811e1d33aada3f17523429b1fda92

Rebase

Address review comments.

This is probably a very late report but I happened to be looking at openmp bots for a different reason, some of the error returns in this change are failing to compile:
https://lab.llvm.org/buildbot/#/builders/4/builds/32052/steps/5/logs/stdio

Address review comments.

The big assumption here is that the GDB process lasts longer than the higher level debug session does. I am keeping a map of register name to unique pointer in the GDB process, then giving out raw pointers to the higher level commands. The higher level is destroyed first, then the GDB process which frees all the unique pointers. This means that the register info struct remains trivial, it wouldn't be if we stored the registerfields type directly in it.

The shakiest aspect here is probably my use of the scratch type system. It works but I'm not 100% that there isn't a better choice.

LGTM

https://github.com/llvm/llvm-project/commit/9f93b71f20eaa0e480ce1a184c40b27dd86576d9

Likely the symlink isn't present, somehow. I did worry that this might happen.

I don't know anything about Objective C internals, perhaps you can provide some reference that talks about this?

Agreed, the original name sounds like a const method.

Correct Linux macro definition when not on Linux.

Remove SEGV_BNDERR defines from FreeBSD and NetBSD. I cargo culted these from CrashReason
but on checking the latest sources, they are not in either.

Rebase

Rebase

Thanks for the fix!

The standalone build didn't like this, https://github.com/llvm/llvm-project/commit/0b958fe41182c9040499e629e24cbdd250d73bf7 fixes that.

After talking to a colleague, yes, it does make sense. I've updated the comment https://github.com/llvm/llvm-test-suite/commit/099d3c1617e0bf30723c26de3fdb24df3fe797f1.

Update GetSignalDescription function name.

Thinking about it more, the test may also be using UB. Which would explain why a change to not require noundef would have caused this. Perhaps clang has always been able to create a tail call here, if the called function did not have UB. That restriction is now gone.

A colleague suggests that maybe there are other reasons clang shouldn't tail call here, but in the interests of getting the bot green I will land this.