I have reverted this temporarily as It broke LLDB API test TestBadAddressBreakpoints.py

LGTM. With a minor nit fix about FixAnyAddress vs FixDataAddress if required.

Very corner case but Is there a possibility of masks changing positions during the life-time of an inferior ? So this makes me think that code/data masks are per process and cant be changes once set. Should we worry about it?AFAIK this is fine but just asking to clear any ambiguities.

Looks good to me.

In D118979#3448556, @jaykang10 wrote:

um... I have tried to reproduce it on a64fx machine. It looks it is failed with the big number of parallel tasks of ninja build. When I run the failed command manually, it is passed... If I reduce the number of the parallel tasks with ninja build like ninja -j16, the build is also passed... it could be memory allocation error from the bigger memory allocation than before...
The stage2 build and check-all are passed on Cortex-A72 machine...
To be safe, for now, I would like to disable shouldMaximizeVectorBandwidth for SVE...
Let me update this patch with it.

I did have a completely difference experience, here are steps to reproduce:

This broke LLVM AArch64 buildbot clang-aarch64-sve-vls-2stage
https://lab.llvm.org/buildbot/#/builders/176/builds/1515
llvm-tblgen crashes after applying this patch.

Thanks for good detailed explanation. I think from the code readability point of view, we may use FixAddress function which i believe already exists in ABI and if not then introduce FixAnyAddress may be. We can put all the comments about PAC/TBI code vs data address bits there in AArch64 ABI code instead of putting a comment about code/data address everytime we use FixDataAddress in generic code.

In D118794#3405724, @DavidSpickett wrote:

Switch to removing non-address bits in lldb instead of lldb-server.

The breakpoint issues I mention only really happen if you try to break on a tagged
function pointer. Which is pretty niche, but I hope to address it later anyway.

On the issue of whether to use FixData vs FixCode there's 2 maybe 3 ways to go:

• Assume that they're the same, which does work for Linux, for now.
• Add a method that does both fixes, on the assumption that the virtual address size for code and data is the same so no harm done and all bits will be removed either way.
• Extensively track whether addresses refer to code or data. In some situations this is possible (looking at the exec bits of a memory mapping for example) but I don't have a great idea what that looks like at this time.

Option 2 seems like a good way to go for now.

Hi I have temporarily reverted this change as it has caused LLVM buildbot failures with failing fuzzer-threaded.test with clang crashing over an assertion failure in llvm/lib/CodeGen/CFIFixup.cpp. Kindly look into it. Thanks
.

In D121786#3385619, @DavidSpickett wrote:

by python 11x release

Is this a typo or some numbering system not related to the 2.x/3.x cadence?

In D120274#3338565, @gkistanova wrote:

Are you sure you don’t want to skip watchpoint tests? They seem unreliable on Windows.

Hi @clayborg this rev has caused some lldb-vscode test failures across all LLDB/Linux buildbots.

Hi James, Thanks for highlighting this. I ve merged a fix.

ping!

looks good thanks

LGTM Thanks! for your patience

In D117676#3254662, @labath wrote:

FWIW, I consider the build.py script a failed experiment. The idea itself was not completely bad, but the lack of buy-in from sufficient amount of developers meant that it never really had a chance of fulfilling its (rather lofty) goals.

I think it should be removed or at least scaled back significantly. The only thing it's really used for these days is to invoke msvc and clang-cl, and I'm sure we can achieve the same thing with some lit substitutions as well...

I have still setting up the Arm WoA worker which requires a bit of tweaking with visual studio config as well. I have not found a final patch for it and going to commit this one while I work on a follow up.

This doesnt interfere with LLDB tests for SVE. Rather I have not used it in a while for SVE tests I ahve using setup similar to to one David has explained above.

In D117363#3245124, @gkistanova wrote:

I think they should be set in just one place to make the code more readable.

I was about to suggest the same.

It might be simpler and more straight forward to revert D116972 and just explicitly specify the needed LLVM_LIT_ARGS in the extra_cmake_args.
If you would like to set -v and -j by default, that could be done by something like this:

defult_lit_args = '-v'
if if jobs:
    defult_lit_args += " -j{jobs}".format(jobs=jobs)
CmakeCommand.applyDefaultOptions(cmake_options, [
        ('-DLLVM_LIT_ARGS=', defult_lit_args),
        ])

This is not a blocker for this patch, though.

A separate thing. The patch specifies the both s and v, which kinds of contradict each other, What's the point?

I conveniently copied lit args from arm lldb bot. AFAIK both giving and sv together shows output as well as a progress bar but I am not too sure.

Apologies for late response!!!

This breaks LLDB Linux buildbots:

This has broken all LLDB buildbots:

@lorenz are you still working on this issue? We are seeing this issue on LLVM for Windows on Arm while compiling TensorFlow with clang-cl.

Hi @clayborg
This breaks LLDB Arm/Linux buildbot. https://lab.llvm.org/buildbot/#/builders/17/builds/14035

This look great. Thanks for doing the legit fix.

These two are rare control paths so I thought not to infiltrate with
lambda arguments. Maybe we can readjust it if further logging needs arise
in future.

This addresses review comments converts printfs to log messages.