[lldb-dev] [Bug 38453] New: lldb: new (unit)test failures in 7.0
https://bugs.llvm.org/show_bug.cgi?id=38453 Bug ID: 38453 Summary: lldb: new (unit)test failures in 7.0 Product: lldb Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: mgo...@gentoo.org CC: llvm-b...@lists.llvm.org Blocks: 38406 Created attachment 20643 --> https://bugs.llvm.org/attachment.cgi?id=20643&action=edit dev-util:lldb-7.0.:20180806-071614.log.xz The following tests are repeatedly failing for me in the new branch (amd64; Gentoo Linux): Failing Tests (12): lldb :: tools/lldb-mi/breakpoint/break-insert.test lldb :: tools/lldb-mi/data/data-info-line.test lldb :: tools/lldb-mi/exec/exec-continue.test lldb :: tools/lldb-mi/exec/exec-finish.test lldb :: tools/lldb-mi/exec/exec-interrupt.test lldb :: tools/lldb-mi/exec/exec-next-instruction.test lldb :: tools/lldb-mi/exec/exec-next.test lldb :: tools/lldb-mi/exec/exec-run-wrong-binary.test lldb :: tools/lldb-mi/exec/exec-step-instruction.test lldb :: tools/lldb-mi/exec/exec-step.test lldb :: tools/lldb-mi/symbol/symbol-list-lines.test lldb-Unit :: Utility/./UtilityTests/VMRange.CollectionContains The lldb-mi issue looks like #28253. The VMRange I didn't see a bug for: TEST 'lldb-Unit :: Utility/./UtilityTests/VMRange.CollectionContains' FAILED Note: Google Test filter = VMRange.CollectionContains [==] Running 1 test from 1 test case. [--] Global test environment set-up. [--] 1 test from VMRange [ RUN ] VMRange.CollectionContains /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./unittests/Utility/VMRangeTest.cpp:146: Failure Value of: VMRange::ContainsRange(collection, VMRange(0x100, 0x104)) Actual: false Expected: true /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./unittests/Utility/VMRangeTest.cpp:147: Failure Value of: VMRange::ContainsRange(collection, VMRange(0x108, 0x100)) Actual: false Expected: true [ FAILED ] VMRange.CollectionContains (0 ms) [--] 1 test from VMRange (0 ms total) [--] Global test environment tear-down [==] 1 test from 1 test case ran. (0 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] VMRange.CollectionContains 1 FAILED TEST Attaching complete build & test log. Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=38406 [Bug 38406] [meta] 7.0.0 Release Blockers -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 38456] New: LLDB: TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase failed: no member named '__value_' in 'std::__1::__list_node_base'
https://bugs.llvm.org/show_bug.cgi?id=38456 Bug ID: 38456 Summary: LLDB: TestDataFormatterLibcxxListLoop.LibcxxListDataFormatte rTestCase failed: no member named '__value_' in 'std::__1::__list_node_base' Product: lldb Version: 7.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: mgo...@gentoo.org CC: llvm-b...@lists.llvm.org Blocks: 38406 TEST 'lldb-Suite :: functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/TestDataFormatterLibcxxListLoop.py' FAILED lldb version 7.0.0 ( revision 70c4484ad65f92d9d59deedbef65705e46c6987c) LLDB library dir: /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/bin LLDB import library dir: /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/bin Skipping following debug info categories: ['dsym', 'gmodules'] Session logs for test failures/errors/unexpected successes will go into directory '/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/lldb-test-traces' Command invoked: /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./test/dotest.py -q --arch= -s /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/lldb-test-traces --build-dir /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS --executable /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/./bin/lldb --dsymutil /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/./bin/dsymutil -C /usr/lib/llvm/7/bin/clang --env ARCHIVER=/usr/bin/x86_64-pc-linux-gnu-ar --env OBJCOPY=/usr/bin/objcopy /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop -p TestDataFormatterLibcxxListLoop.py FAIL: LLDB (/usr/lib64/llvm/7/bin/clang-7-x86_64) :: test_with_run_command (TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase) == ERROR: test_with_run_command (TestDataFormatterLibcxxListLoop.LibcxxListDataFormatterTestCase) -- Error when building test subject. Build Command: make VPATH=/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop -C /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/lldb-test-build.noindex/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/TestDataFormatterLibcxxListLoop.test_with_run_command -I /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop -f /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/Makefile all ARCH=x86_64 CC="/usr/lib64/llvm/7/bin/clang-7" Build Command Output: /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/main.cpp:19:24: error: no member named '__value_' in 'std::__1::__list_node_base' assert(third_elem->__value_ == 3); ~~ ^ /usr/include/assert.h:90:27: note: expanded from macro 'assert' (static_cast (expr) \ ^~~~ /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop/main.cpp:21:24: error: no member named '__value_' in 'std::__1::__list_node_base' assert(fifth_elem->__value_ == 5); ~~ ^ /usr/include/assert.h:90:27: note: expanded from macro 'assert' (static_cast (expr) \ ^~~~ 2 errors generated. make: *** [../../../../../../make/Makefile.rules:576: main.o] Error 1 Test Directory: /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libcxx/list/loop -- Ran 1 test in 2.907s RESULT: FAILED (0 passes, 0 failures, 1 errors, 0 skipped, 0 expected failures, 0 unexpected successes) Referenced Bugs: https://bugs.llvm.org/show_bug.cgi?id=38406 [Bug 38406] [meta] 7.0.0 Release Blockers -- You are receiving this mail because: You are the assignee for the bug.___ lldb-dev mailing list lldb-dev@lists.llvm.
[lldb-dev] [Bug 38457] New: LLDB: TestDataFormatterStdSmartPtr.StdSmartPtrDataFormatterTestCase (and 1 more) failing with UnicodeDecodeError: 'utf8' codec can't decode byte 0xd0 in position 164: inval
https://bugs.llvm.org/show_bug.cgi?id=38457
Bug ID: 38457
Summary: LLDB:
TestDataFormatterStdSmartPtr.StdSmartPtrDataFormatterT
estCase (and 1 more) failing with UnicodeDecodeError:
'utf8' codec can't decode byte 0xd0 in position 164:
invalid continuation byte
Product: lldb
Version: 7.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: mgo...@gentoo.org
CC: llvm-b...@lists.llvm.org
Blocks: 38406
Created attachment 20644
--> https://bugs.llvm.org/attachment.cgi?id=20644&action=edit
Error-StdSmartPtrDataFoError-StdSmartPtrDataFormatterTestCase-test_with_run_command_dwarf.logrmatterTestCase-test_with_run_command_dwarf.log
FAIL: lldb-Suite ::
functionalities/data-formatter/data-formatter-stl/libstdcpp/smart_ptr/TestDataFormatterStdSmartPtr.py
(210 of 1188)
TEST 'lldb-Suite ::
functionalities/data-formatter/data-formatter-stl/libstdcpp/smart_ptr/TestDataFormatterStdSmartPtr.py'
FAILED
lldb version 7.0.0 ( revision 70c4484ad65f92d9d59deedbef65705e46c6987c)
LLDB library dir:
/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/bin
LLDB import library dir:
/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/bin
Skipping following debug info categories: ['dsym', 'gmodules']
Session logs for test failures/errors/unexpected successes will go into
directory
'/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/lldb-test-traces'
Command invoked:
/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./test/dotest.py -q
--arch= -s
/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/lldb-test-traces
--build-dir
/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/lldb-test-build.noindex
-S nm -u CXXFLAGS -u CFLAGS --executable
/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/./bin/lldb
--dsymutil
/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0._build/./bin/dsymutil
-C /usr/lib/llvm/7/bin/clang --env ARCHIVER=/usr/bin/x86_64-pc-linux-gnu-ar
--env OBJCOPY=/usr/bin/objcopy
/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libstdcpp/smart_ptr
-p TestDataFormatterStdSmartPtr.py
UNSUPPORTED: LLDB (/usr/lib64/llvm/7/bin/clang-7-x86_64) ::
test_with_run_command_dsym
(TestDataFormatterStdSmartPtr.StdSmartPtrDataFormatterTestCase) (test case does
not fall in any category of interest for this run)
FAIL: LLDB (/usr/lib64/llvm/7/bin/clang-7-x86_64) ::
test_with_run_command_dwarf
(TestDataFormatterStdSmartPtr.StdSmartPtrDataFormatterTestCase)
FAIL: LLDB (/usr/lib64/llvm/7/bin/clang-7-x86_64) :: test_with_run_command_dwo
(TestDataFormatterStdSmartPtr.StdSmartPtrDataFormatterTestCase)
UNSUPPORTED: LLDB (/usr/lib64/llvm/7/bin/clang-7-x86_64) ::
test_with_run_command_gmodules
(TestDataFormatterStdSmartPtr.StdSmartPtrDataFormatterTestCase) (test case does
not fall in any category of interest for this run)
==
ERROR: test_with_run_command_dwarf
(TestDataFormatterStdSmartPtr.StdSmartPtrDataFormatterTestCase)
--
Traceback (most recent call last):
File
"/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/lldbtest.py",
line 1757, in test_method
return attrvalue(self)
File
"/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/functionalities/data-formatter/data-formatter-stl/libstdcpp/smart_ptr/TestDataFormatterStdSmartPtr.py",
line 33, in test_with_run_command
self.expect("frame variable ssp", substrs=['ssp = "foobar"'])
File
"/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/lldbtest.py",
line 2185, in expect
inHistory=inHistory)
File
"/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/lldbtest.py",
line 2066, in runCmd
print(self.res.GetError(), file=sbuf)
File
"/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/test/lldbtest.py",
line 287, in __exit__
print(self.getvalue(), file=self.session)
File
"/var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./packages/Python/lldbsuite/support/encoded_file.py",
line 34, in impl
s = s.decode(encoding)
File "/usr/lib64/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xd0 in position 164:
invalid continuation byte
Config=x86_64-/usr/lib64/llvm/7/bin/clang-7
==
[lldb-dev] Pavel's status
Hello all, as some of you may know, this week is my last week at Google. However, I am not planning to disappear from the LLDB/LLVM communities as a result. You should still see me around, only with a new address (pavel AT labath DOT sk). I plan to continue looking out for the linux side of lldb (for any Android issues your best point of contact is Stephen Hines (srhines AT google DOT com)) and contributing some featurelets or cleanups. In particular, I will strive to resolve (help resolving) any issues that may fall out of the recent debug_names accelerator table work. Nonetheless, unless I find an LLDB job, I will certainly be less active than before, which means I won't be able to responds as promptly to code reviews. For that I apologize, and suggest to seek out alternative reviewers whereever possible. regards, Pavel ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [Release-testers] [7.0.0 Release] rc1 has been tagged
On Sun, Aug 5, 2018 at 5:49 PM, Dimitry Andric wrote:
> On 3 Aug 2018, at 13:37, Hans Wennborg via Release-testers
> wrote:
>>
>> 7.0.0-rc1 was just tagged (from the branch at r338847).
>>
>> It's early in the release process, but I'd like to find out what the
>> status is of the branch on our various platforms.
>>
>> Please run the test script, share the results, and upload binaries.
>
> Hmm, I'm running into a rather nasty snag now on i386-freebsd11, due to our
> lack of atomic 64 bit primitives; Phase2's configure dies with:
>
> -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB
> -- Performing Test HAVE_CXX_ATOMICS_WITHOUT_LIB - Success
> -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB
> -- Performing Test HAVE_CXX_ATOMICS64_WITHOUT_LIB - Failed
> -- Looking for __atomic_load_8 in atomic
> -- Looking for __atomic_load_8 in atomic - not found
> CMake Error at cmake/modules/CheckAtomic.cmake:75 (message):
> Host compiler appears to require libatomic, but cannot find it.
>
> Interestingly, Phase1 does *not* suffer from this, but there the "host
> compiler" is clang 6.0.0.
>
> Phase1 CMake output:
>
> Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB succeeded
> with the following output:
> Change Dir:
> /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/local/bin/gmake" "cmTC_845df/fast"
> /usr/local/bin/gmake -f CMakeFiles/cmTC_845df.dir/build.make
> CMakeFiles/cmTC_845df.dir/build
> gmake[1]: Entering directory
> '/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
> Building CXX object CMakeFiles/cmTC_845df.dir/src.cxx.o
> /usr/bin/c++-DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11
> -Werror=unguarded-availability-new -o CMakeFiles/cmTC_845df.dir/src.cxx.o
> -c
> /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp/src.cxx
> Linking CXX executable cmTC_845df
> /usr/local/bin/cmake -E cmake_link_script
> CMakeFiles/cmTC_845df.dir/link.txt --verbose=1
> /usr/bin/c++ -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11
> -Werror=unguarded-availability-newCMakeFiles/cmTC_845df.dir/src.cxx.o -o
> cmTC_845df -lm
> gmake[1]: Leaving directory
> '/home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
>
> Source file was:
>
> #include
> #include
> std::atomic x (0);
> int main() {
> uint64_t i = x.load(std::memory_order_relaxed);
> return 0;
> }
>
> Phase2 CMake output:
>
> Performing C++ SOURCE FILE Test HAVE_CXX_ATOMICS64_WITHOUT_LIB failed
> with the following output:
> Change Dir:
> /home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp
>
> Run Build Command:"/usr/local/bin/gmake" "cmTC_720f3/fast"
> /usr/local/bin/gmake -f CMakeFiles/cmTC_720f3.dir/build.make
> CMakeFiles/cmTC_720f3.dir/build
> gmake[1]: Entering directory
> '/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
> Building CXX object CMakeFiles/cmTC_720f3.dir/src.cxx.o
>
> /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.install/usr/local/bin/clang++
> -DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11
> -Werror=unguarded-availability-new -o CMakeFiles/cmTC_720f3.dir/src.cxx.o
> -c
> /home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp/src.cxx
> Linking CXX executable cmTC_720f3
> /usr/local/bin/cmake -E cmake_link_script
> CMakeFiles/cmTC_720f3.dir/link.txt --verbose=1
>
> /home/dim/llvm/7.0.0/rc1/Phase1/Release/llvmCore-7.0.0-rc1.install/usr/local/bin/clang++
>-DHAVE_CXX_ATOMICS64_WITHOUT_LIB -std=c++11
> -Werror=unguarded-availability-newCMakeFiles/cmTC_720f3.dir/src.cxx.o -o
> cmTC_720f3 -lm
> CMakeFiles/cmTC_720f3.dir/src.cxx.o: In function `main':
> src.cxx:(.text+0x33): undefined reference to `__atomic_load_8'
> clang-7: error: linker command failed with exit code 1 (use -v to see
> invocation)
> gmake[1]: *** [CMakeFiles/cmTC_720f3.dir/build.make:98: cmTC_720f3] Error
> 1
> gmake[1]: Leaving directory
> '/home/dim/llvm/7.0.0/rc1/Phase2/Release/llvmCore-7.0.0-rc1.obj/CMakeFiles/CMakeTmp'
> gmake: *** [Makefile:126: cmTC_720f3/fast] Error 2
>
> Source file was:
>
> #include
> #include
> std::atomic x (0);
> int main() {
> uint64_t i = x.load(std::memory_order_relaxed);
> return 0;
> }
>
> Apparently, with clang 6.0 it didn't generate libcalls to atomic functions,
> but just put in cmpxchg8b's, I guess? And with clang 7.0 this seems to have
> changed.
>
> For now, I can only test on amd64 due to this, since I don't have an easy
> workaround.
This doesn't sound so good, but I'm glad we found out early.
Did you file a bug to track this? (Sorry if you already did, I haven't
read through the list today.)
Thanks,
Hans
__
Re: [lldb-dev] [Bug 38453] New: lldb: new (unit)test failures in 7.0
This should be fixed by rL338949 On Mon, Aug 6, 2018 at 12:27 AM, via lldb-dev wrote: > Bug ID 38453 <https://bugs.llvm.org/show_bug.cgi?id=38453> > Summary lldb: new (unit)test failures in 7.0 > Product lldb > Version 7.0 > Hardware PC > OS Linux > Status NEW > Severity enhancement > Priority P > Component All Bugs > Assignee lldb-dev@lists.llvm.org > Reporter mgo...@gentoo.org > CC llvm-b...@lists.llvm.org > Blocks 38406 > > Created attachment 20643 <https://bugs.llvm.org/attachment.cgi?id=20643> > [details] <https://bugs.llvm.org/attachment.cgi?id=20643&action=edit> > dev-util:lldb-7.0.:20180806-071614.log.xz > > The following tests are repeatedly failing for me in the new branch (amd64; > Gentoo Linux): > > Failing Tests (12): > lldb :: tools/lldb-mi/breakpoint/break-insert.test > lldb :: tools/lldb-mi/data/data-info-line.test > lldb :: tools/lldb-mi/exec/exec-continue.test > lldb :: tools/lldb-mi/exec/exec-finish.test > lldb :: tools/lldb-mi/exec/exec-interrupt.test > lldb :: tools/lldb-mi/exec/exec-next-instruction.test > lldb :: tools/lldb-mi/exec/exec-next.test > lldb :: tools/lldb-mi/exec/exec-run-wrong-binary.test > lldb :: tools/lldb-mi/exec/exec-step-instruction.test > lldb :: tools/lldb-mi/exec/exec-step.test > lldb :: tools/lldb-mi/symbol/symbol-list-lines.test > lldb-Unit :: Utility/./UtilityTests/VMRange.CollectionContains > > The lldb-mi issue looks like #28253. The VMRange I didn't see a bug for: > > TEST 'lldb-Unit :: > Utility/./UtilityTests/VMRange.CollectionContains' FAILED > Note: Google Test filter = VMRange.CollectionContains > [==] Running 1 test from 1 test case. > [--] Global test environment set-up. > [--] 1 test from VMRange > [ RUN ] VMRange.CollectionContains > /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./unittests/Utility/VMRangeTest.cpp:146: > Failure > Value of: VMRange::ContainsRange(collection, VMRange(0x100, 0x104)) > Actual: false > Expected: true > /var/tmp/portage/dev-util/lldb-7.0./work/lldb-7.0./unittests/Utility/VMRangeTest.cpp:147: > Failure > Value of: VMRange::ContainsRange(collection, VMRange(0x108, 0x100)) > Actual: false > Expected: true > [ FAILED ] VMRange.CollectionContains (0 ms) > [--] 1 test from VMRange (0 ms total) > > [--] Global test environment tear-down > [==] 1 test from 1 test case ran. (0 ms total) > [ PASSED ] 0 tests. > [ FAILED ] 1 test, listed below: > [ FAILED ] VMRange.CollectionContains > > 1 FAILED TEST > > > > > Attaching complete build & test log. > > -- > *Referenced Bugs:* > >- [Bug 38406 <https://bugs.llvm.org/show_bug.cgi?id=38406>] [meta] >7.0.0 Release Blockers > > > -- > You are receiving this mail because: > >- You are the assignee for the bug. > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Handling of the ELF files missing build-ids?
>
> I am fine with all the above except some reservations about case C. No
> need to calculate something if it isn't useful. For case C it should be
> fine to never match as if a file has a UUID to begin with it typically
> isn't something that gets stripped in a stripped binary. So we should
> either have it or not. If breakpad does calculate a CRC32, then we need to
> know to ignore the UUID. The problem is we probably won't be able to tell
> what the UUID is: real from build ID, or from GNU debug info CRC, or CRC of
> entire file. So the minidump code will need to do something here. If a
> minidump has the linux auxv and memory map in them, then we might need to
> dig through the section information and deduce if a file matches or not
> based off the size of mapped program headers to further help with the
> matching.
>
> One other idea is to make a set of enumerations for the UUID type:
>
> class UUID {
> enum class Type {
> BuildID, // A build ID from the compiler or linker
> GNUDebugInfoCRC, // GNU debug info CRC
> MD5, // MD5 of entire file
> MD5NonDebug, // MD5 of the non debug info related bits
> CRC32, // CRC32 of entire file
> Other, // Anything else
> };
> };
>
> The eTypeMD5NonDebug is what apple does: it MD5 checksums only the parts
> of the file that don't change with debug info or any paths found in debug
> info or symbols tables. So if you build a binary in /tmp/a or in
> /private/var/local/foo, the UUID is the same if the binary is essentially
> the same (code, data, etc).
>
> Then we can make intelligent comparisons between UUID types. Might even be
> possible for a module to have more than 1 UUID then if a binary contains a
> eTypeBuildID and a eTypeGNUDebugInfoCRC. If a tool stores its UUIDs as a
> CRC32 or MD5, then those can be calculated on the fly. The GetUUID on
> lldb_private::Module might become:
>
> const lldb_private::UUID &Module::GetUUID(UUID::Type uuid_type);
>
> Thoughts?
>
> Greg
I like the idea of UUID sub-types! This solves the problem is a more
generic fashion and it's also extensible. Interestingly enough, for
Crashpad we're considering something similar (the fabricated UUIDs would
have a different CvRecord signature)
Case C. is a bit ugly so let me elaborate: this is specific to Breakpad
minidump + ELF binaries w/o build-id. So we'd still need to have a way to
force the match of the modules in the minidump with the local files. This
ought to be an off-by-default, sharp tool which you'd only need to deal
with Breakpad minidumps, and even then it would only be a fall-back that
must be explicitly requested.
1. .gnu_debuglink separate file pointer
> .
> This is where the choice of the crc algorithm comes from.
Thanks Pavel. As you noted yourself, this doesn't mean that the UUID has to
be tied to the checksum (they are exclusive options). In particular, for
performance reasons I think it's desirable to avoid calculating checksums
for every ELF module just in case.
I think we might have something already which could serve this
> purpose. Eugene added a couple of months ago a mechanism to force-load
> symbols for a given file regardless of the UUIDs
> . It requires an explicit "target
> symbols add" command (which seems reasonable, as lldb has no way to
> tell if it's doing things right). Would something like that work for
> you?
Nice. We may have to update the C++ API, but something like this would do
the trick for case C.
To summarize the conversation so far:
1. We can fix cases A, B independent of C: if real UUIDs are missing, don't
automatically use full file CRC32 as UUID.
2. Pay attention to make sure that we don't break .gnu_debuglink or remote
debugging (thanks Pavel)
3. Multiple types/namespaces for UUIDs would be a great feature!
4. Eugene's symbol forcing trick could be extended to handle case C
Did I miss anything?
My current plan is to start with #1, then look into #4 (force symbols
match).
On Sun, Aug 5, 2018 at 12:11 PM, Pavel Labath wrote:
> Hello Leonard,
>
> while I'm in principle supportive of this idea, I think it's not going
> to be as easy as you might imagine. There are currently at least two
> mechanisms which rely on this crc UUID.
>
> 1. .gnu_debuglink separate file pointer
> .
> This is where the choice of the crc algorithm comes from.
>
> In short, this mechanism for debug info location works like this: The
> stripped file contains a .gnu_debuglink section. The section contains
> a file path and a crc checksum. After reading this section the
> debugger is expected to look for the file at the given path, and then
> compute it's checksum to verify it is indeed the correct file (hasn't
> been modified).
>
> In LLDB, this is implemented somewhat differently. First we have a
> mechanism for assig
