User Details
- User Since
- May 3 2018, 11:15 AM (216 w, 6 d)
Fri, Jun 24
I did some testing and verified that this commit is causing some of the Sanitizer issues we are seeing. Is there any chance of a revert?
Just FYI, this commit appears to cause lldb//test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py to fail. The error I'm seeing is:
I apologize; I was looking at several commits, and I accidentally added my comment to the wrong one. No, this commit is not the one that caused my problem (I am very sorry about the confusion).
Just FYI, this commit appears to cause lldb//test/API/commands/target/auto-install-main-executable/TestAutoInstallMainExecutable.py to fail. The error I'm seeing is:
Thu, Jun 23
Ignore my revert request; Your later commit seems to have fixed most of my issues.
This appears to have broken a lot of LLDB tests in our bootstrap as well. Is there any chance this might get reverted?
Wed, Jun 22
@philnik Ah, thanks for pointing that out. Ignore my previous comment. :-)
Just a heads up, this looks like it may have broken compiler-rt builds. I'm seeing errors like:
ERROR: third_party/stl/BUILD:57:11: Compiling third_party/stl/stl.cppmap failed: (Exit 1) wrapped_clang failed: error executing command (from target third_party/stl:stl) third_party/crosstool/v18/llvm_unstable/toolchain/bin/wrapped_clang '-frandom-seed=blaze-out/k8-opt/bin/third_party/stl/_objs/stl/stl.pcm' -iquote . -iquote blaze-out/k8-opt/genfiles -iquote ... (remaining 224 arguments skipped). [forge_remote_host=lmdw19]
While building module 'third_party/stl:stl':
In file included from <module-includes>:43:
./third_party/stl/cxx17/ext/functional:17:24: error: no template named 'unary_function' in namespace 'std'; did you mean '__unary_function'?
struct identity : std::unary_function<T, T> {
~~~~~^~~~~~~~~~~~~~ __unary_function
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/__functional/unary_function.h:46:1: note: 'unary_function' declared here
using unary_function = unary_function_keep_layout_base<_Arg, _Result>;
^
While building module '//third_party/stl:stl':
In file included from <module-includes>:43:
./third_party/stl/cxx17/ext/functional:22:25: error: no template named 'unary_function' in namespace 'std'; did you mean 'unary_function'?
struct select1st : std::unary_function<Pair, typename Pair::first_type> {
~~~~~^~~~~~~~~~~~~~ __unary_function
third_party/crosstool/v18/llvm_unstable/toolchain/bin/../include/c++/v1/__functional/unary_function.h:46:1: note: 'unary_function' declared here
using unary_function = __unary_function_keep_layout_base<_Arg, _Result>;
Feb 5 2022
When building/running third_party/llvm/llvm-project/clang/test/OpenMP/atomic_messages.c and third_party/llvm/llvm-project/clang/test/OpenMP/atomic_ast_print.cpp, we get use-of-uninitialized-variable error messages:
Feb 4 2022
Never mind; someone beat me to the fix. Abandoning this.
This commit is causing some of our builds to fail with these errors:
Feb 3 2022
Feb 2 2022
It looks like someone else fixed this issue while I was creating this patch: https://github.com/llvm/llvm-project/commit/4a6c9b5686.
Feb 1 2022
We're still working on getting you a reproducible test case, but this is definitely causing some bad codegen for us. Could you please revert it while we work on getting you the test case?
Just a heads-up: This commit appears to be breaking some of our tests. We're working on trying to get a reproducible test case.
Jan 31 2022
This change introduces a circular dependency: BitcodeWriters now depends on TransformUtils, but TransformUtils also depends on BitcodeWriters. This appears to be a layering violation.
Aug 12 2021
Just a heads up: We are seeing some new clang/llvm crashes, and we believe this CL is the culprit. I am working on trying to get a good reproducer. This CL may need to be reverted.
Jun 30 2021
Jun 26 2021
I have tried to build lldb-server for aarch64 inside Chrome OS following the instructions above, but due to the way things build in Chrome OS (using the Gentoo Linux portage system) this does not work. I also have not been able to find these definitions in ptrace.h files inside Chrome OS.
Jun 23 2021
Can we do this just using clang/llvm? We've stopped using GCC in Chrome OS and have pretty much removed it altogether.
To be clear, this is all elf/linux, and the builds happen on x86_64 machines.
I found a need for this change when I was trying to build (cross-compile) lldb/lldb-server for aarch64 inside Chrome OS -- the build I had was failing for aarch64 with all of these symbols "undefined". If you can tell me the cmake configs and/or build flags I should use to try to get these symbols from ptrace.h, I can try that instead. But since this is a cross-compile, they might not be available on the build system?
Apr 16 2021
Pavel's test case passed on my local machine (x86_64 linux workstation).
Hi Pavel,
Apr 15 2021
I had to revert this change because the test case broke the windows builder. What's the right way to update/mark the test case so that it is only run on appropriate architectures & operating systems?
Apr 14 2021
I did leave 'main' in the .s file, but it's not very big. Is this ok now?
Update test case to use lldb on .o file and not run the inferior.
Apr 13 2021
Pavel, your last comment lost me completely. How can I test the code I added to lldb if I don't run lldb? I am a complete newbie at writing test cases so there's probably something basic I'm missing? How would I observe the value of the variable without running lldb? Also, if the program doesn't contain 'main', won't the compiler complain? Is there an existing test that does what you're suggesting that I could look at?
Apr 8 2021
Add a test case.
Apr 7 2021
It has taken a bit of time to get through the GDB reviews, but the change to GDB was accepted and committed: https://sourceware.org/pipermail/gdb-cvs/2021-April/050267.html
Mar 7 2021
Mar 4 2021
Update to incorporate Pavel's suggested simplification.
I'm not sure about using target.debug-file-search-paths, and what the changes Pavel is suggesting would entail. But the real question I am trying to resolve here is not "what are all the places we should be searching for the .dwo files?" but "When we're given a *relative path* in the DWARF for finding the files, what should it be relative TO?".
Mar 2 2021
It is true that the compiler will not know where the final executable will be placed, and if the executable gets moved then debugging with .dwo files will probably not work anyway, However as it is currently written, LLDB will fail to find the .dwo files, *even when the binary has not been moved*, if the debugger is launched from any directory other than the one containing the binary.
Upload the correct patch this time. (sorry!)
Something went very wrong on the patch upload. This does NOT look like the
patch I intended!
Apr 23 2020
Nov 7 2019
Fix small typo in comments.
Nov 6 2019
Remove quotes from -NOT tests.
Fix NODEBUGINFO-NOT test.
Remove period from help text. Fix tests.
Nov 5 2019
Rename flag to -fdebug-default-version; add help text, mentioning DWARF. Update tests to use -### and add assembler tests.
Yes, I will change the flag name back to debug-default-version, and add help text mentioning dwarf. I'm in the process of trying to re-do the test cases as required (I'm a bit new to this so it's taking me a bit to figure this out).
Make second call to ParseDwarfDefaultVersion unconditional (to match the first and avoid errors with -Werror).
For the record, I double-checked and if we use the flag and don't check for it (i.e. if we move the parsing inside the EmitDwarf is True block) then -Werror does indeed complain about an unused command line argument.
dblaikie: The code, as written, parses the dwarf default version flag, whether or not DWARFVersion is 0, i.e. whether or not a -gdwarf-N flag was passed. It only USES the value if there's no overriding value.
re-try upload again.
Ok, I think the upload was correct this time.
Hmmm...I'm having upload issues.
Try uploading correct diff file?
Made requested changes:
- renamed option to be dwarf-specific
- fixed spelling & blank line issues
- only set version if emit-dwarf is true
- move test to Driver directory
Nov 4 2019
Made requested formatting changes.
Jun 5 2019
Ping? Is anybody looking at or working on this? The bug this fixes is one of the issues currently blocking Chrome OS from being able to adopt Dwarf v5, so we are hoping for a fix?
May 13 2019
Committed in r360380.
May 9 2019
Apr 1 2019
Test case has been committed, as of revision 357409.
Mar 1 2019
Ran clang-format on Statistics.cpp
Feb 7 2019
It appears to me that on line 131 we are already adding/counting the ConstantMembers in FnStats.VarsInFunction, so adding "+ Constants" would be counting them twice. Alternatively we can change the code on line 131 to not include ConstantMembers...
I was mistaken before: we were never counting the template parameters. What was happening was that we were counting the variables in both inlined instances, and we were also counting the variables for a concrete, out-of-line instance of the inlined function, even though in this particular case there was no concrete out-of-line instance. I have updated the patch now to only count vars in DW_TAG_subprogram DIEs if the subprogram DIE has PC addresses. I believe this is the correct fix for this issue.
This increases the version number, as requested.
Now we correctly count only real constant members as "constant members" and we count global variables with locations as part of the "vars with locs".
aprantl@, you were right, my original change was not correctly updating the variable counts to include variables occuring in inlined instances of functions. I have update the patch to fix this issue. There were two additional changes needed: one to make sure we were counting variables for functions that had no inlined instances at all; and one to avoid double-counting member constants.
Feb 6 2019
Sep 21 2018
Use Conf.CodeModel in LTO, if it exists.
Add comment explaining why mixing two code models is an error. Add missing Inputs/codemodel-3.ll file.
Move include statement from CodeGenModule.h to CodeGenModule.cpp
Remove incorrect "default" case statement.
Add test for "tiny" code model.
Sep 20 2018
Jul 20 2018
Simplify test case, as requested by Peter.
I just realized that my patch did not contain the actual move of RuntimeLibcalls.def from CodeGen to IR. This update includes that move.
Made requested fixes.
I've made Peter's suggested changes.
Jul 19 2018
pcc's original suggested fix did not work, because the real issue was the function definitions being initially internalized by LTO and later DCE'd. Peter's suggestion did not prevent them from being internalized. I consulted with him offline and we came up with this alternative solution. It fixes the issue for the new LTO implemention. The old LTO implementation still internalizes the function definitions, but they do not get Dead Code Eliminated. I have also fixed the test case, and have generalized the code to check for all builtin functions (as requested).