• Use self.process()
• Check for overlapping regions instead of just the base addresses.

Follow up to https://discourse.llvm.org/t/unexplained-memory-regions-on-windows/62662.

Turns out there was a much simpler soloution: https://reviews.llvm.org/D129147

clang-format

Thanks for implementing this!

LGTM

My intent was to express that the issue is present where it's the 9th or later arguments.

From reading the release note my understanding is that before this fix the caller of a function would store z0-z7 in situations where it did not need to. Which seems low impact unless you were doing something that read the previous stack frame (but nevertheless a difference from the AAPCS).

Some random comments.

I currently don't quite understand how to configure the build bot, and how to set the test configuration, I went through this article but didn't find useful information for me, could someone help me.

LGTM

FWIW I do get the same error in a clean directory without this patch applied:

-- LLDB version: 15.0.0git
CMake Error at /home/david.spickett/llvm-project/lldb/cmake/modules/LLDBConfig.cmake:289 (message):
  Expected directory for clang-resource headers not found:
Call Stack (most recent call first):
  /home/david.spickett/llvm-project/lldb/CMakeLists.txt:28 (include)

I tried to fix this error with gdb, but the debugging process was too slow, so I'm sorry for not being able to provide a test patch for verification of my commit.

Overall this looks fine. Without the ability to test it I don't think we would accept it yet, so I didn't look into the details too much.

I can confirm this fixes the reproducer I posted on https://reviews.llvm.org/D126771.

The reproducer:

I also bisected an lldb failure down to this: https://lab.llvm.org/buildbot/#/builders/96/builds/25038/steps/6/logs/stdio

I've reverted this due to failures on our bots: https://lab.llvm.org/buildbot/#/builders/96/builds/25032/steps/6/logs/stdio

LGTM. I like the ifs the way I suggested but up to you, either way it's not the easiest logic to parse.

LGTM

LGTM

Now since the addition of the new setting in 25c8a061c5739677d2fc0af29a8cc9520207b923, ObjectFile::GetModuleSpecifications can return i386-pc-windows-gnu and i686-pc-windows-gnu, while PlatformWindows provides a list containing i386-pc-windows (which is normalized to i386-pc-windows-msvc) and i686-pc-windows (...-msvc). Due to the differing environments, these are deemed incompatible, and LLDB flat out refuses to load the file, with the error message error: no matching platforms found for this file.

However, after this commit, if the object file is advertised with the different environment (either when built in a mingw environment, or if that setting is set), the fat binary validation won't accept the file any longer.

Having this on by default in some configs on linux and off on others seems like it'd be very confusing. Let's please either have it on or off uniformly per OS?

I'll give this a more thorough read later just one comment for now.

Are there public docs for these numbers?

LGTM

LGTM

Any reason to #if 0 this instead of just removing it and maybe adding a one line comment like "nested exceptions are not supported"? So that someone can git blame that and find this commit with the removal.

FYI this broke our armv7 and v8 bots https://lab.llvm.org/buildbot/#/builders/178/builds/2293 (as it did last time it landed).

Why not use objdump? If we only check that instructions get disassembled, it will work fine.

Now I think about it, tests could do something like "-mattr=-all" to remove it, right?

conflicting instructions with the same encoding in different extensions, but it doesn't seem possible within one archeticture

Is it easy to test this?

This LGTM.

This exposed a failure on our (Linaro's) test suite bot for Armv7. I've opened an issue for it: https://github.com/llvm/llvm-project/issues/55899

Generating test output seems like a good change but I have no experience with it myself.

I won't have time to comment much more but Omair might be able to help.

Can you include some links to documentation of the debuglink feature in the commit message? I assume https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html is what you'd want.

There is an arch setting to target create but I doubt passing the whole triple there will make a difference (truncated to arch only at best).

LGTM

This changes the PE/COFF and PDB plugins to set the module triple according to the default target triple used to build LLDB.

Is it worth updating flang/docs/ReleaseNotes.md ? Though it seems to have been abandoned.

DBUILD_SHARED_LIBS being the key setting in the config that causes the issue.

I'm basing this on what psuedo/lib/grammar does, so I'm not totally sure this is the place to fix it.

This is now present on the bots:

2022-06-06 05:50:50 INFO:   CMAKE_Fortran_COMPILER: '/home/tcwg-buildbot/worker/clang-aarch64-full-2stage/stage2.install/bin/flang-to-external-fc'

Pushed: https://github.com/llvm/llvm-zorg/commit/6a33c8666f619103a5b733a0e9f73001cfea8f59

If I'm not around to land this myself, go ahead then email Galina (address on this page https://llvm.org/docs/HowToAddABuilder.html) to ask for a buildbot restart to include the change.

LGTM

I'm a bit early landing this but I'll forget otherwise.

(I also keep an eye on the bots Omair was referring to) You can just reland this change as is (revert your revert) and if something else goes wrong you'll either get a failure email or we'll let you know.

LGTM

Looks good to me. Can you just clarify how the tests are split? My guess is that one is stuff that doesn't vary with hard/soft float and the other is the bits that change when hardfloat is enabled. If so is it worth checking those situations with soft float too or have you already done that.

Can you reupload with more context? See https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface

In https://reviews.llvm.org/rG38eb4fe74b38 I moved the generic test into the X86 folder as it uses an X86 triple. You could think of the folder names there having 2 meanings, 1: the tests look at things specific to that arch and 2: they use that arch's triple (I think X86 is usually the one people choose if they want to test something generic anyway).

I know very little about the interpreter so someone else can comment there.

Much clearer now, thanks. LGTM with the one nit fixed.

Relanded in https://reviews.llvm.org/rG13e1cf806567bc4987817e14a774198c3e3f2709.

Use the new name.