Re: [lldb-dev] [Openmp-dev] [cfe-dev] [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
On Sun, Feb 11, 2018 at 3:31 PM, Dimitry Andric wrote: > On 9 Feb 2018, at 22:30, Dimitry Andric wrote: >> >> On 9 Feb 2018, at 22:11, Dimitry Andric via Openmp-dev >> wrote: >>> >>> On 9 Feb 2018, at 20:40, Dimitry Andric via cfe-dev >>> wrote: > On 9 Feb 2018, at 10:20, Hans Wennborg wrote: >>> ... > What are all these test failures? Does it seems like they have a > common root cause and do we have a bug for it? >>> ... The Clang Tools and Extra Tools Unit tests all appear to crash with: exception_ptr not yet implemented >>> >>> This turns out to be caused by libc++ being compiled without -DLIBCXXRT. >>> (In the FreeBSD base system build, we always add this option, so libc++ >>> knows how to handle exceptions.) >>> >>> In the libc++ CMakeFiles, it appears to be governed by >>> LIBCXX_CXX_ABI_LIBNAME, but it isn't being set to the correct value of >>> "cxxrt" on FreeBSD. I am going to try the following diff: >>> >>> --- llvm.src/projects/libcxx/CMakeLists.txt >>> +++ llvm.src/projects/libcxx/CMakeLists.txt >>> @@ -135,6 +135,8 @@ >>> elseif (APPLE) >>>set(LIBCXX_CXX_ABI_LIBNAME "libcxxabi") >>>set(LIBCXX_CXX_ABI_SYSTEM 1) >>> + elseif (CMAKE_SYSTEM_NAME MATCHES "FreeBSD") >>> +set(LIBCXX_CXX_ABI_LIBNAME "libcxxrt") >>> else() >>>set(LIBCXX_CXX_ABI_LIBNAME "default") >>> endif() >> >> ... and unfortunately that didn't work, since the CMakeFiles are unable to >> find the libcxxrt headers: >> >> CMake Warning at projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:67 >> (message): >> Failed to find cxxabi.h >> Call Stack (most recent call first): >> projects/libcxx/cmake/Modules/HandleLibCXXABI.cmake:112 (setup_abi_lib) >> projects/libcxx/CMakeLists.txt:428 (include) > > Ok, this turned out to be easier than I thought. After applying > https://reviews.llvm.org/D43166, the number of failed tests drops roughly by > half (from 896 to 512): > > Expected Passes: 45381 > Expected Failures : 185 > Unsupported Tests : 2937 > Unexpected Passes : 1 > Unexpected Failures: 521 > > I am going to have a look at some other low hanging fruit, and I have also > created a few PRs to merge test changes into 6.0. Nice! It sounds like most of this is stuff that's always been failing, so I'm not going to worry too much, but it's very nice to see the error numbers go down. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] hashing pointers to strings
[ Clang's emission of pubnames/pubtypes is controlled by the "debugger tuning" parameter. With -glldb they don't get emitted, with -ggdb, they do. (-glldb is default on mac, -ggdb elsewhere). In dwarf5 these sections have been dropped in favour of the new .debug_names section. ] On 10 February 2018 at 02:25, Jim Ingham via lldb-dev wrote: > A quick glance indicates that this is all dead code. I can't see anything > that actually instantiates either of the pubnames classes. > > The DWARF pubnames tables were a previous attempt at producing DWARF indexes, > but they didn't contain enough information to actually forstall deep dives > into the DWARF, so they weren't actually useful. clang doesn't emit them on > macOS for sure, does it emit them on linux? They are superseded by the new > DWARF 5 accelerator tables, and I couldn't find any reference to pubnames in > the DWARF 5 draft standard. > > We should check with Greg about this, but I don't think we're ever likely to > get any use out of DWARF pubnames tables. We should just delete this code. > > Jim > > >> On Feb 9, 2018, at 4:35 PM, Adrian McCarthy via lldb-dev >> wrote: >> >> DWARFDebugPubnamesSet.h has a type definition like this: >> >> typedef std::unordered_multimap> std::hash, >> CStringEqualBinaryPredicate> >> cstr_to_index_mmap; >> >> In particular, note that the hasher will hash the pointer rather than the >> string it points to. >> >> It looks like this mostly works because the map is built once from string >> pointers that don't appear to be changed during the lifetime of the >> multimap. That's fragile, and I'm not sure it's really working in all >> cases. For example, there could be two different pointers to identical >> strings--since this is a multimap rather than a map, I assume we'd want >> those values merged under the same key, but since the pointers are distinct, >> they won't be. >> >> I'd like to change the key to a std::string or a StringRef for correctness >> and robustness, but that'll likely be a tad slower because hashing >> variable-length strings is more work than hashing fixed-length pointers. (I >> don't think it'll change comparisons much, since the comparator is checking >> the strings.) >> >> Objections or better suggestions? >> >> It's also hard for me to test, as most of the LLDB DWARF tests are still >> broken on Windows because the inferiors are generated with CodeView rather >> than DWARF. I'm working on that, but it'll take changes to the lld-link >> driver. >> >> Adrian. >> ___ >> 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 ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] hashing pointers to strings
> "Pavel" == Pavel Labath via lldb-dev writes: Pavel> [ Clang's emission of pubnames/pubtypes is controlled by the "debugger Pavel> tuning" parameter. With -glldb they don't get emitted, with -ggdb, Pavel> they do. gdb has never read .debug_pubnames, so this setting doesn't really make sense. Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] hashing pointers to strings
If it's dead code, that certainly simplifies things! I've sent a patch for review to remove the unused, untested code. https://reviews.llvm.org/D43202 On Mon, Feb 12, 2018 at 1:52 AM, Pavel Labath wrote: > [ Clang's emission of pubnames/pubtypes is controlled by the "debugger > tuning" parameter. With -glldb they don't get emitted, with -ggdb, > they do. (-glldb is default on mac, -ggdb elsewhere). In dwarf5 these > sections have been dropped in favour of the new .debug_names section. > ] > > On 10 February 2018 at 02:25, Jim Ingham via lldb-dev > wrote: > > A quick glance indicates that this is all dead code. I can't see > anything that actually instantiates either of the pubnames classes. > > > > The DWARF pubnames tables were a previous attempt at producing DWARF > indexes, but they didn't contain enough information to actually forstall > deep dives into the DWARF, so they weren't actually useful. clang doesn't > emit them on macOS for sure, does it emit them on linux? They are > superseded by the new DWARF 5 accelerator tables, and I couldn't find any > reference to pubnames in the DWARF 5 draft standard. > > > > We should check with Greg about this, but I don't think we're ever > likely to get any use out of DWARF pubnames tables. We should just delete > this code. > > > > Jim > > > > > >> On Feb 9, 2018, at 4:35 PM, Adrian McCarthy via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> > >> DWARFDebugPubnamesSet.h has a type definition like this: > >> > >> typedef std::unordered_multimap >> std::hash, > >> CStringEqualBinaryPredicate> > >> cstr_to_index_mmap; > >> > >> In particular, note that the hasher will hash the pointer rather than > the string it points to. > >> > >> It looks like this mostly works because the map is built once from > string pointers that don't appear to be changed during the lifetime of the > multimap. That's fragile, and I'm not sure it's really working in all > cases. For example, there could be two different pointers to identical > strings--since this is a multimap rather than a map, I assume we'd want > those values merged under the same key, but since the pointers are > distinct, they won't be. > >> > >> I'd like to change the key to a std::string or a StringRef for > correctness and robustness, but that'll likely be a tad slower because > hashing variable-length strings is more work than hashing fixed-length > pointers. (I don't think it'll change comparisons much, since the > comparator is checking the strings.) > >> > >> Objections or better suggestions? > >> > >> It's also hard for me to test, as most of the LLDB DWARF tests are > still broken on Windows because the inferiors are generated with CodeView > rather than DWARF. I'm working on that, but it'll take changes to the > lld-link driver. > >> > >> Adrian. > >> ___ > >> 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 > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] "print 0" produces "error: expected unqualified-id"
Firstly, here are the characters in our story:
* lldb
$ lldb --version
lldb version 5.0.1
* clang
$ p=/path/to/clang
$ file -L "$p"
/path/to/clang: ELF 64-bit LSB shared object, x86-64, version 1
(GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for
GNU/Linux 3.2.0, BuildID[sha1]=3a2da750e90367b294e4219896738fa9b0a285ad, with
debug_info, not stripped
$ "$p" --version
clang version 7.0.0 (trunk 324807)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /path/to
Launch "lldb" with the above "clang":
$ lldb "$p"
(lldb) target create "/path/to/clang"
Current executable set to '/path/to/clang' (x86_64).
(lldb)
Set a breakpoint:
(lldb) breakpoint set --name clang::driver::Compilation::ExecuteCommand
Breakpoint 1: where =
clang`clang::driver::Compilation::ExecuteCommand(clang::driver::Command const&,
clang::driver::Command const*&) const + 50 at Compilation.cpp:142, address =
0x034a9a9c
Launch the executable:
(lldb) process launch -- /dev/null
Process 18950 launched: '/path/to/clang' (x86_64)
Process 18950 stopped
* thread #1, name = 'clang', stop reason = breakpoint 1.1
frame #0: 0x589fda9c
clang`clang::driver::Compilation::ExecuteCommand(this=0x5fdd5ec0,
C=0x5fdae930, FailingCommand=0x7fffcd38) const at
Compilation.cpp:142
139
140 int Compilation::ExecuteCommand(const Command &C,
141 const Command *&FailingCommand) const
{
-> 142if ((getDriver().CCPrintOptions ||
143 getArgs().hasArg(options::OPT_v)) &&
!getDriver().CCGenDiagnostics) {
144 raw_ostream *OS = &llvm::errs();
145
Now, try to print an expression, even a simple constant expression:
(lldb) print 0
error: expected unqualified-id
Note that the initial attempt to run the command "print 0" causes an enormous
amount of computing to occur before the error is produced; subsequent attempts
to issue the command produce the error message much more quickly.
Sincerely,
Michael Witten
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
