Created attachment 1526893 [details] find-basic-namespace.cpp.tmp.xz Description of problem: LLDB testsuite can FAIL for: LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp It fails with F-29 GCC but it works fine with trunk GCC. Version-Release number of selected component (if applicable): FAIL: gcc-8.2.1-6.fc29.x86_64 FAIL: gcc-8.2.1-7.fc29.x86_64 FAIL: 9fb89fa845c1b2e0a18d85ada0b077c84508ab78 = gcc-8_2_0-release PASS: 934ccfef21c68278e81e5fe2015fb68ec39ed18a = trunk I have not tested Rawhide GCC. x FAIL: -DCMAKE_BUILD_TYPE=Release (the tests above) PASS: -DCMAKE_BUILD_TYPE=Debug (with gcc-8.2.1-6.fc29.x86_64) x FAIL: "" PASS: -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ (GCC not used) How reproducible: Always. Steps to Reproduce: git clone https://github.com/llvm/llvm-project.git llvm-monorepo mkdir llvm-monorepo-build cd llvm-monorepo-build export LD_LIBRARY_PATH=GCCPATH/lib64 cmake ../llvm-monorepo/llvm/ -DCMAKE_BUILD_TYPE=Release -DLLVM_USE_LINKER=gold -DLLVM_ENABLE_PROJECTS="lldb;clang;lld" -DCMAKE_C_COMPILER=GCCPATH/bin/gcc -DCMAKE_CXX_COMPILER=GCCPATH/bin/g++ make python2 ./bin/llvm-lit -sv tools/lldb/lit --filter find-basic-namespace OR ./bin/lldb-test symbols --name=foo --find=namespace ATTACHED/find-basic-namespace.cpp.tmp Actual results: Module: /home/jkratoch/t/find-basic-namespace.cpp.tmp Namespace not found. Expected results: Module: /home/jkratoch/t/find-basic-namespace.cpp.tmp Found namespace: foo Additional info: ff8064bd9580dd182c7d6a209be774a65c7fdbc7 is the first bad(=good) commit commit ff8064bd9580dd182c7d6a209be774a65c7fdbc7 Author: law <law@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Wed Jan 2 21:38:56 2019 +0000 * gimple-fold.c (gimple_fold_builtin_strlen): Use set_strlen_range ... git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@267531 138bc75d-0d04-0410-961f-82ee72b054a4 -> Message-ID: <0886b52b-92f0-f02d-d588-c43bcd0e806c> -> [committed] Be more conservative with string length range computations From: Jeff Law <law at redhat dot com> https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00069.html I have no idea what's wrongly compiled in lldb-test, I did not debug it. I guess RHEL-8 gcc is also affected.
Created attachment 1526894 [details] local GCC bisecting script
Let me make sure I understand what the results mean: the test failures happen with gcc-8_2_0-release and prior but not with GCC trunk, or with 8.2 and Jeff's patch applied. If that's close, the likely cause of the failures is assuming strings can span multiple members of a struct, like in this test case where GCC 8 returns 0 but GCC 9 returns 1: struct S { char a[4], b[8]; } s; int f (void) { for (int i = 0; i != 4; ++i) s.a[i] = 'x'; s.b[0] = 0; return strlen (s.a) == 4; // undefined, folded to 0 in GCC 8 and to 1 in GCC 9 }
Is this LLDB code behavior really undefined? I would say it does not matter what strlen() returns as there is that std::min() protection: #include <algorithm> #include <string.h> // lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1731 static struct section_64 { char sectname[16]; char segname[16]; } sect64 = { {'_','_','a','p','p','l','e','_','n','a','m','e','s','p','a','c'}, "__DWARF" }; int main() { return std::min<size_t>(strlen(sect64.sectname), sizeof(sect64.sectname)); } gcc-8.2.1-6.fc29.x86_64 g++ -o strlen strlen.C -Wall -g -O2;./strlen;echo $? Actual: 23 Expected: 16
(In reply to Jan Kratochvil from comment #3) > Is this LLDB code behavior really undefined? I would say it does not matter > what strlen() returns as there is that std::min() protection: https://en.wikipedia.org/wiki/Undefined_behavior "In general, any instance of undefined behavior leaves the abstract execution machine in an unknown state, and causes the behavior of the entire program to be undefined." So OK, I expect this will be CLOSED-NOTABUG and going to submit an LLDB fix.
Isn't strnlen what they are looking for?
It's definitely undefined. It doesn't matter that the value of strlen is clamped *after* running off the end of the array, that's too late. I thought we already fixed this in LLDB, but maybe that was something very similar in LLVM.
Created attachment 1527275 [details] LLDB strnlen.patch (In reply to Jakub Jelinek from comment #5) > Isn't strnlen what they are looking for? This is what I am going to submit. Maybe it was some microoptimization, they care about runtime performance a lot.
It was in LLD and tstellar fixed it: https://github.com/llvm-mirror/lld/commit/c0aa57c9cbaca0f14bde7a78b067e947ccfbd672#diff-00e2f6bb89e280599d22538d8533ae78
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.