Re: [lldb-dev] Some API test failures are really opaque/could be improved
I just saw in your review comment that this is using
LLVM_ENABLE_RUNTIMES and not LLVM_ENABLE_PROJECTS for libcxx, so the
failure just comes from us setting the wrong RPATH due to the
different runtimes library directory (at least from what I can see).
Would it be possible to put libcxx in LLVM_ENABLE_PROJECTS for now? I
think this shouldn't be too hard to fix (famous last words?).
Am Mo., 18. Okt. 2021 um 22:30 Uhr schrieb David Blaikie :
>
> On Mon, Oct 18, 2021 at 9:45 AM Raphael Isemann wrote:
>>
>> I think https://reviews.llvm.org/D111978 ,
>> https://reviews.llvm.org/D111981 and the other patches Pavel & me put
>> up today should improve this situation IIUC.
>
>
> Thanks Raphael - really appreciate you & looking into this!
>
> With https://reviews.llvm.org/D111981 I still seem to not have that cxx
> dependency (building/running the test, then building libcxx, then running the
> test again goes from unsupported -> failing) - didn't seem to work for me?
>
> The diagnostic improvement sounds good to me (pity about whatever limitations
> it has re: remote or windows execution gathering the stdout). I guess
> gathering the logs in the remote execution case has the same problem (that
> the log is made on the remote machine/non-trivial to retrieve?)?
>
> & yeah, have you got any patches/ideas about how to make the libcxx tests use
> the just-built libcxx library (using LD_LIBRARY_PATH, rpath, etc)? For now,
> even with both these fixes I'll just be seeing (consistent, which is nice)
> failures, rather than being able to run these tests successfully. I'll either
> have to get used to ignoring certain failures, or disable the tests by not
> building libcxx in that build tree, which would also be unfortunate. (or
> maybe there's some other workarounds?) Any idea how this works for other
> folks?
>
> - Dave
>
>> - Raphael
>>
>> Am Mo., 18. Okt. 2021 um 05:54 Uhr schrieb David Blaikie via lldb-dev
>> :
>> >
>> > Wondering if anyone else has encountered/dealt with debugging lldb test
>> > failures like the one shown at the end of this email ("AssertionError: 10
>> > != 5" in "test.assertEqual(process.GetState(), lldb.eStateStopped)" while
>> > checking that a breakpoint was reached)
>> >
>> > Is there anything that could be done to improve the debuggability of such
>> > failures? Logging standard output/error from the lldb process or any other
>> > logging it might have? At least for one of these I managed to figure it
>> > out by running lldb directly on the binary and finding that the binary
>> > couldn't find libc++.so (that's a story for another bug/email thread,
>> > looks like maybe lldb libc++ pretty printer tests are using the system
>> > installed libc++, not the just-built libc++ (& thus not running if there
>> > is no system installed libc++)). But my current failure like this seems a
>> > bit more inscrutible and I'm still looking into it.
>> >
>> > Looks like dotest.py has some sense of logging (it has a --log-success
>> > option which says preserves the logs even on failure - though the output
>> > of dotest.py, at least for me, has no mention of logs, log files, or where
>> > they might be located, and looking at the source points to some sort of
>> > ".log" files... ah, found some)
>> >
>> > So, yeah, there do seem to be some Failure.log, SkippedTest.log, etc -
>> > should dotest print something about the paths to those files when it exits
>> > with failure, maybe?
>> >
>> >
>> >
>> > FAIL: lldb-api ::
>> > functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py
>> > (23 of 23)
>> >
>> > TEST 'lldb-api ::
>> > functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py'
>> > FAILED
>> >
>> > Script:
>> >
>> > --
>> >
>> > /usr/bin/python3
>> > /usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/dotest.py -u
>> > CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env
>> > OBJCOPY=/usr/bin/objcopy --env
>> > LLVM_LIBS_DIR=/usr/local/google/home/blaikie/dev/llvm/build/release/./lib
>> > --arch x86_64 --build-dir
>> > /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex
>> > --lldb-module-cache-dir
>> > /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/module-cache-lldb/lldb-api
>> > --clang-module-cache-dir
>> > /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/module-cache-clang/lldb-api
>> > --executable
>> > /usr/local/google/home/blaikie/dev/llvm/build/release/./bin/lldb
>> > --compiler
>> > /usr/local/google/home/blaikie/dev/llvm/build/release/./bin/clang
>> > --dsymutil
>> > /usr/local/google/home/blaikie/dev/llvm/build/release/./bin/dsymutil
>> > --llvm-tools-dir
>> > /usr/local/google/home/blaikie/dev/llvm/build/release/./bin
>> > --lldb-libs-dir
>> > /usr/local/google/home/blaikie/dev/llvm/build/release/./lib
>> > /usr/local/go
Re: [lldb-dev] Some API test failures are really opaque/could be improved
Actually the RPATH theory is wrong, but the LLVM_ENABLE_PROJECT
workaround *should* still work.
Am Di., 19. Okt. 2021 um 18:02 Uhr schrieb Raphael Isemann
:
>
> I just saw in your review comment that this is using
> LLVM_ENABLE_RUNTIMES and not LLVM_ENABLE_PROJECTS for libcxx, so the
> failure just comes from us setting the wrong RPATH due to the
> different runtimes library directory (at least from what I can see).
> Would it be possible to put libcxx in LLVM_ENABLE_PROJECTS for now? I
> think this shouldn't be too hard to fix (famous last words?).
>
> Am Mo., 18. Okt. 2021 um 22:30 Uhr schrieb David Blaikie :
> >
> > On Mon, Oct 18, 2021 at 9:45 AM Raphael Isemann wrote:
> >>
> >> I think https://reviews.llvm.org/D111978 ,
> >> https://reviews.llvm.org/D111981 and the other patches Pavel & me put
> >> up today should improve this situation IIUC.
> >
> >
> > Thanks Raphael - really appreciate you & looking into this!
> >
> > With https://reviews.llvm.org/D111981 I still seem to not have that cxx
> > dependency (building/running the test, then building libcxx, then running
> > the test again goes from unsupported -> failing) - didn't seem to work for
> > me?
> >
> > The diagnostic improvement sounds good to me (pity about whatever
> > limitations it has re: remote or windows execution gathering the stdout). I
> > guess gathering the logs in the remote execution case has the same problem
> > (that the log is made on the remote machine/non-trivial to retrieve?)?
> >
> > & yeah, have you got any patches/ideas about how to make the libcxx tests
> > use the just-built libcxx library (using LD_LIBRARY_PATH, rpath, etc)? For
> > now, even with both these fixes I'll just be seeing (consistent, which is
> > nice) failures, rather than being able to run these tests successfully.
> > I'll either have to get used to ignoring certain failures, or disable the
> > tests by not building libcxx in that build tree, which would also be
> > unfortunate. (or maybe there's some other workarounds?) Any idea how this
> > works for other folks?
> >
> > - Dave
> >
> >> - Raphael
> >>
> >> Am Mo., 18. Okt. 2021 um 05:54 Uhr schrieb David Blaikie via lldb-dev
> >> :
> >> >
> >> > Wondering if anyone else has encountered/dealt with debugging lldb test
> >> > failures like the one shown at the end of this email ("AssertionError:
> >> > 10 != 5" in "test.assertEqual(process.GetState(), lldb.eStateStopped)"
> >> > while checking that a breakpoint was reached)
> >> >
> >> > Is there anything that could be done to improve the debuggability of
> >> > such failures? Logging standard output/error from the lldb process or
> >> > any other logging it might have? At least for one of these I managed to
> >> > figure it out by running lldb directly on the binary and finding that
> >> > the binary couldn't find libc++.so (that's a story for another bug/email
> >> > thread, looks like maybe lldb libc++ pretty printer tests are using the
> >> > system installed libc++, not the just-built libc++ (& thus not running
> >> > if there is no system installed libc++)). But my current failure like
> >> > this seems a bit more inscrutible and I'm still looking into it.
> >> >
> >> > Looks like dotest.py has some sense of logging (it has a --log-success
> >> > option which says preserves the logs even on failure - though the output
> >> > of dotest.py, at least for me, has no mention of logs, log files, or
> >> > where they might be located, and looking at the source points to some
> >> > sort of ".log" files... ah, found some)
> >> >
> >> > So, yeah, there do seem to be some Failure.log, SkippedTest.log, etc -
> >> > should dotest print something about the paths to those files when it
> >> > exits with failure, maybe?
> >> >
> >> >
> >> >
> >> > FAIL: lldb-api ::
> >> > functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py
> >> > (23 of 23)
> >> >
> >> > TEST 'lldb-api ::
> >> > functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py'
> >> > FAILED
> >> >
> >> > Script:
> >> >
> >> > --
> >> >
> >> > /usr/bin/python3
> >> > /usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/dotest.py -u
> >> > CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env
> >> > OBJCOPY=/usr/bin/objcopy --env
> >> > LLVM_LIBS_DIR=/usr/local/google/home/blaikie/dev/llvm/build/release/./lib
> >> > --arch x86_64 --build-dir
> >> > /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex
> >> > --lldb-module-cache-dir
> >> > /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/module-cache-lldb/lldb-api
> >> > --clang-module-cache-dir
> >> > /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/module-cache-clang/lldb-api
> >> > --executable
> >> > /usr/local/google/home/blaikie/dev/llvm/build/release/./bin/lldb
> >> > --compiler
> >
[lldb-dev] [Bug 52223] New: GNU extension for DW_TAG_interface_type produces an error instead of ignoring it
https://bugs.llvm.org/show_bug.cgi?id=52223
Bug ID: 52223
Summary: GNU extension for DW_TAG_interface_type produces an
error instead of ignoring it
Product: lldb
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: cont...@lsferreira.net
CC: jdevliegh...@apple.com, llvm-b...@lists.llvm.org
GNU compilers generate a `DW_AT_containing_type` pointing to either the base
class or it self if no base class to point to for `DW_TAG_interface_type` tags.
This produces the following error on LLDB while trying to read DWARF:
error: a.out {0x0287}: unhandled type tag 0x0038 (DW_TAG_interface_type),
please file a bug and attach the file at the start of this error message
--
You are receiving this mail because:
You are the assignee for the bug.___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Some API test failures are really opaque/could be improved
On Tue, Oct 19, 2021 at 9:08 AM Raphael Isemann wrote:
> Actually the RPATH theory is wrong, but the LLVM_ENABLE_PROJECT
> workaround *should* still work.
>
I'll give that a go (it's running at the moment) though I guess this is
inconsistent with the direction libcxx is moving in for building, re:
https://groups.google.com/g/llvm-dev/c/tpuLxk_ipLw
>
> Am Di., 19. Okt. 2021 um 18:02 Uhr schrieb Raphael Isemann
> :
> >
> > I just saw in your review comment that this is using
> > LLVM_ENABLE_RUNTIMES and not LLVM_ENABLE_PROJECTS for libcxx, so the
> > failure just comes from us setting the wrong RPATH due to the
> > different runtimes library directory (at least from what I can see).
> > Would it be possible to put libcxx in LLVM_ENABLE_PROJECTS for now? I
> > think this shouldn't be too hard to fix (famous last words?).
> >
> > Am Mo., 18. Okt. 2021 um 22:30 Uhr schrieb David Blaikie <
> dblai...@gmail.com>:
> > >
> > > On Mon, Oct 18, 2021 at 9:45 AM Raphael Isemann
> wrote:
> > >>
> > >> I think https://reviews.llvm.org/D111978 ,
> > >> https://reviews.llvm.org/D111981 and the other patches Pavel & me put
> > >> up today should improve this situation IIUC.
> > >
> > >
> > > Thanks Raphael - really appreciate you & looking into this!
> > >
> > > With https://reviews.llvm.org/D111981 I still seem to not have that
> cxx dependency (building/running the test, then building libcxx, then
> running the test again goes from unsupported -> failing) - didn't seem to
> work for me?
> > >
> > > The diagnostic improvement sounds good to me (pity about whatever
> limitations it has re: remote or windows execution gathering the stdout). I
> guess gathering the logs in the remote execution case has the same problem
> (that the log is made on the remote machine/non-trivial to retrieve?)?
> > >
> > > & yeah, have you got any patches/ideas about how to make the libcxx
> tests use the just-built libcxx library (using LD_LIBRARY_PATH, rpath,
> etc)? For now, even with both these fixes I'll just be seeing (consistent,
> which is nice) failures, rather than being able to run these tests
> successfully. I'll either have to get used to ignoring certain failures, or
> disable the tests by not building libcxx in that build tree, which would
> also be unfortunate. (or maybe there's some other workarounds?) Any idea
> how this works for other folks?
> > >
> > > - Dave
> > >
> > >> - Raphael
> > >>
> > >> Am Mo., 18. Okt. 2021 um 05:54 Uhr schrieb David Blaikie via lldb-dev
> > >> :
> > >> >
> > >> > Wondering if anyone else has encountered/dealt with debugging lldb
> test failures like the one shown at the end of this email ("AssertionError:
> 10 != 5" in "test.assertEqual(process.GetState(), lldb.eStateStopped)"
> while checking that a breakpoint was reached)
> > >> >
> > >> > Is there anything that could be done to improve the debuggability
> of such failures? Logging standard output/error from the lldb process or
> any other logging it might have? At least for one of these I managed to
> figure it out by running lldb directly on the binary and finding that the
> binary couldn't find libc++.so (that's a story for another bug/email
> thread, looks like maybe lldb libc++ pretty printer tests are using the
> system installed libc++, not the just-built libc++ (& thus not running if
> there is no system installed libc++)). But my current failure like this
> seems a bit more inscrutible and I'm still looking into it.
> > >> >
> > >> > Looks like dotest.py has some sense of logging (it has a
> --log-success option which says preserves the logs even on failure - though
> the output of dotest.py, at least for me, has no mention of logs, log
> files, or where they might be located, and looking at the source points to
> some sort of ".log" files... ah, found some)
> > >> >
> > >> > So, yeah, there do seem to be some Failure.log, SkippedTest.log,
> etc - should dotest print something about the paths to those files when it
> exits with failure, maybe?
> > >> >
> > >> >
> > >> >
> > >> > FAIL: lldb-api ::
> functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py
> (23 of 23)
> > >> >
> > >> > TEST 'lldb-api ::
> functionalities/data-formatter/data-formatter-stl/libcxx/set/TestDataFormatterLibcxxSet.py'
> FAILED
> > >> >
> > >> > Script:
> > >> >
> > >> > --
> > >> >
> > >> > /usr/bin/python3
> /usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/dotest.py -u
> CXXFLAGS -u CFLAGS --env ARCHIVER=/usr/bin/ar --env
> OBJCOPY=/usr/bin/objcopy --env
> LLVM_LIBS_DIR=/usr/local/google/home/blaikie/dev/llvm/build/release/./lib
> --arch x86_64 --build-dir
> /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex
> --lldb-module-cache-dir
> /usr/local/google/home/blaikie/dev/llvm/build/release/lldb-test-build.noindex/module-cache-lldb/lldb-api
> --clang-module-cache-dir
> /usr/local/google/home/blaikie/dev/llvm/build/release/lld
