User Details
- User Since
- Sep 24 2018, 3:51 AM (197 w, 3 d)
Today
- Use self.process()
- Check for overlapping regions instead of just the base addresses.
Yesterday
Tue, Jul 5
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).
Mon, Jul 4
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.
Wed, Jun 29
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)
Mon, Jun 27
Fri, Jun 24
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.
Thu, Jun 23
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
Wed, Jun 22
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
Tue, Jun 21
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
Mon, Jun 20
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).
Wed, Jun 15
Why not use objdump? If we only check that instructions get disassembled, it will work fine.
Tue, Jun 14
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
Fri, Jun 10
Is it easy to test this?
Jun 7 2022
This LGTM.
Jun 6 2022
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'
Jun 1 2022
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.
May 31 2022
May 30 2022
(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
May 26 2022
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).
May 25 2022
I know very little about the interpreter so someone else can comment there.
May 24 2022
Much clearer now, thanks. LGTM with the one nit fixed.
May 23 2022
May 19 2022
May 18 2022
Use the new name.