Re: [lldb-dev] Some API test failures are really opaque/could be improved

[Raphael Isemann via lldb-dev]

Is someone currently working on fixing this? FWIW, I think David's
change seems to go in the right direction (when I originally looked at
this I also ended up on the wrong rpath but I thought it was some
other code that set the wrong value. Didn't realize we have two places
where this happens). I think David's diff is better than we currently
have so maybe we should just turn this into a review?

Am Di., 26. Okt. 2021 um 06:43 Uhr schrieb David Blaikie :
>
> On Mon, Oct 25, 2021 at 1:28 PM Louis Dionne  wrote:
>>
>> I believe the issue is probably not related so much to LLVM_ENABLE_PROJECTS 
>> vs LLVM_ENABLE_RUNTIMES, but rather to the fact that LLVM_ENABLE_RUNTIMES 
>> uses per-target runtime directories now (hasn't always been the case), which 
>> basically means that libc++ ends up in 
>> `/lib//libc++.so` instead of `/lib/libc++.so`.
>
>
> Ish, yes. It's a bug in LLVM_ENABLE_RUNTIMES that isn't present in 
> LLVM_ENABLE_PROJECTS, so for now if I want to run the lldb pretty printer 
> tests for libc++ on Linux it seems the only way I can is by using the 
> deprecated functionality of libc++ in LLVM_ENABLE_PROJECTS.
>
> Consider this a bug report (looks like a bug in the lldb CMake configuration, 
> not in libc++'s build itself, but something to figure out if Linux lldb devs 
> are going to use libc++ +.ENABLE_RUNTIMES path) on that deprecation?
>
>>
>> I think you either want to specify the per-target library dir when running 
>> against libc++, or you want to disable that and use 
>> `LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=OFF` when configuring the runtimes. In 
>> all cases, you want to be using `LLVM_ENABLE_RUNTIMES` and not 
>> `LLVM_ENABLE_PROJECTS`, since the latter is deprecated now.
>
>
> I didn't enable LLVM_ENABLE_PER_TARGET_RUNTIME_DIR myself/in the root cmake 
> config. It looks like it's hardcoded(?) into the ENABLE_RUNTIMES sub-build? 
> https://github.com/llvm/llvm-project/blob/e5fb79b31424267704e9d2d9674089fd7316453e/llvm/runtimes/CMakeLists.txt#L76
>  I'm not sure there's any way to override that from the root? And in any case 
> I'd have thought the defaults would need to/be intended to work correctly on 
> supported platforms?
>
> So something in lldb's dir handling (maybe some general infrastructure in 
> LLVM could use some improvement to provide an LLVM_RUNTIME_LIBS_DIR, or 
> similar? that could then be used from other places - rather than libc++, for 
> instance, creating that directory for itself based on LLVM_LIBS_DIR and 
> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR, etc) needs some fixes to support the 
> current defaults/hardcoded modes on Linux?
>
>>
>> Cheers,
>> Louis
>>
>> On Oct 25, 2021, at 13:57, David Blaikie  wrote:
>>
>> +Louis Dionne - perhaps the libcxx and lldb folks would be interesting in 
>> finding a suitable way to address this issue, since currently either option 
>> (using libcxx in ENABLE_PROJECTS or using it in ENABLE_RUNTIMES) is 
>> incomplete - if I use ENABLE_RUNTIMES I get the libcxx testing run against 
>> the just-built clang and generally this is the "supported" configuration, 
>> but then some lldb tests fail because they can't find libcxx.so.1 (on Linux) 
>> - and using ENABLE_PROJECTS means not using the just-built clang for libcxx 
>> tests (so missing the libcxx breakages caused by my array name change) but 
>> do use the just-built libcxx in lldb tests and find failures there...
>>
>> On Wed, Oct 20, 2021 at 1:57 PM David Blaikie  wrote:
>>>
>>> On Tue, Oct 19, 2021 at 4:55 PM David Blaikie  wrote:

 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
>>>
>>>
>>> Yep, it does work with LLVM_ENABLE_PROJECT rather than LLVM_ENABLE_RUNTIME.
>>>
>>> Specifically the test binary is linked with an rpath to the just-built lib 
>>> directory that ensures the just-built libc++.so is found:
>>>
>>> /usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang main.o -g 
>>> -O0 -fno-builtin -m64  
>>> -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make/../../../../../include
>>>  
>>> -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/list
>>>  
>>> -I/usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make
>>>  -include 
>>> /usr/local/google/home/blaikie/dev/llvm/src/lldb/packages/Python/lldbsuite/test/make/test_common.h
>>>  -fno-limit-debug-info  -gsplit-dwarf-stdlib=libc++ 
>>> -Wl,-rpath,/usr/local/google/home/blaikie/dev/llvm/build/release/./lib 
>>> --driver-mode=g++ -o "a.out"
>>>
>>> Oh, actually it passes the same rpath when using LLVM_ENABLE_RUNTIME, but 
>>> the 

[lldb-dev] The two PDB plugins in LLDB

[Raphael Isemann via lldb-dev]

Hi all,

I'm currently working on a patch that requires updating to all our
debug information parsers and I noticed that we have two PDB plugins.
One seems to be 'native' and uses a LLVM-internal parser while the
non-native reuses parts of Microsoft DIA SDK from what I can see.

IIUC the native plugin is the more recently added one and it also
doesn't require the external Microsoft SDK (that only exists on
Windows). I wonder if there is a reason to keep the non-native PDB
plugin around in LLDB? Beside the expected additional burden of having
two independent PDB parsers, having a parser that only works on
Windows is making maintenance especially difficult.

Unless removing the non-native PDB plugin has some negative impact on
users (e.g., missing features in native plugin that work with the
non-native plugin), I would propose we delete it and only keep the
native PDB plugin in LLDB which seems far less work to maintain.

Thanks,
- Raphael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] Upstream an LLDB language plugin for D and support of custom expressions

[Raphael Isemann via lldb-dev]

I think having more language plugins in LLDB is in general a good
thing. Given the past experience with other plugins (that have been
since removed) there are probably a few things that should be
clarified before we merge new plugins:

1. Who is going to maintain it?

In the past we had to remove the Go plugin because we couldn't find a
single person on this planet that wanted to maintain it after the
original author stopped working on it. It would be good to have some
confidence that the plugin doesn't end up without a maintainer in the
near future. Having multiple people involved seems like a good way to
show that this isn't likely to happen. I think having another person
reviewing the patches and being willing to maintain the code seems
also fine IMHO.

2. How is it going to be tested?

The most straightforward way of testing seems to be to just have some
D sources checked in, we call the D compiler to compile them and then
have a normal API test that tests the language-specific parts. But
that also means we would have a dependency on the D compiler to run
the tests which makes maintaining LLDB overall harder. We currently
get away with this approach for C/C++/Obj-C because we have a compiler
for those languages in LLVM itself.

The other solution would be to check in some pre-generated YAML'ified
debug info similar to what we are currently doing in some shell tests.
That means we don't have a dependency on the D compiler to run the
test suite, but those pregenerated tests have a tendency to be hard to
maintain (some existing tests require me to change my local username,
run macOS/Xcode and do a bunch of manual cleanup to end up with the
same output). Also they often clutter the repository with random
strings that show up in grep (I'm pretty sure we have at least one
test that contains the Google-internal network proxy config or
something similar). I think we can get something maintainable with
some simple script that can post-process whatever the D compiler
emits. Requiring people to install the D compiler to regenerate the
tests is IMHO a reasonable requirement as that rarely happens.

3. How is this going to be implemented?

Bit of a broad topic, but it would be good to know what's the general
plan for implementing the plugin. From what I can see we need at least
a DWARF parser, a lldb_private::Language-based plugin and a
TypeSystem-based plugin. I believe that's enough to get most of the
functionality in LLDB working (the only exception is the expression
parser), but there's a good chance I forgot something in that list.
The expression evaluator will probably be a whole topic on its own,
but I would expect it to be some small evaluator for simple D
expressions (+ maybe something relying on the Clang expression
evaluator for things like function calls, etc.).

Regarding the custom expression: I don't think there are any plans in
that direction, but I think having support for hooking in custom
expression evaluators seems like a reasonable idea.

- Raphael

Am Mo., 25. Okt. 2021 um 18:50 Uhr schrieb David Blaikie via lldb-dev
:
>
> +lldb-dev
>
> On Mon, Oct 25, 2021 at 9:36 AM Luís Ferreira via llvm-dev 
>  wrote:
>>
>> Hi llvm-dev,
>>
>> I'm writing here to discuss the addition of D language plugin to LLDB.
>> Following the issue #52223 from Bugzilla, we are currently using C/C++
>> language plugin for D. This project is part of the Symmetry Autumn of
>> Code 2021, which proposes to implement better integration for D into
>> LLDB.
>>
>> This project is a highly requested feature for D developers who use
>> Apple-based devices since configuring GDB requires extra configuration
>> and self signing binaries.
>>
>> One possible solution is to write a plugin using the Python public API,
>> although it has some limitations, since, AFAIK, custom expressions are
>> not currently well supported.
>>
>> More context about the project milestones can be found
>> [here](lsferreira.net/public/assets/posts/d-saoc-2021-
>> 01/milestones.md).
>>
>> I would like to discuss the possibility of upstreaming the plugin in
>> C++ to the official tree and if there is anything in the roadmap to
>> support custom expressions via Python.
>>
>> --
>> Sincerely,
>> Luís Ferreira @ lsferreira.net
>>
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
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

[Raphael Isemann via lldb-dev]

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 
> 

Re: [lldb-dev] Some API test failures are really opaque/could be improved

[Raphael Isemann via lldb-dev]

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 
>> > 

Re: [lldb-dev] Some API test failures are really opaque/could be improved

[Raphael Isemann via lldb-dev]

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.

- 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/google/home/blaikie/dev/llvm/src/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libcxx/set
>  -p TestDataFormatterLibcxxSet.py
>
> --
>
> Exit Code: 1
>
>
> Command Output (stdout):
>
> --
>
> lldb version 14.0.0 (g...@github.com:llvm/llvm-project.git revision 
> 6176fda3f992b5086302b3826aa0636135cc4cc0)
>
>   clang revision 6176fda3f992b5086302b3826aa0636135cc4cc0
>
>   llvm revision 6176fda3f992b5086302b3826aa0636135cc4cc0
>
> Skipping the following test categories: ['dsym', 'gmodules', 'debugserver', 
> 'objc']
>
>
> --
>
> Command Output (stderr):
>
> --
>
> UNSUPPORTED: LLDB 
> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: 
> test_ref_and_ptr_dsym 
> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) (test case does 
> not fall in any category of interest for this run)
>
> FAIL: LLDB 
> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: 
> test_ref_and_ptr_dwarf 
> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase)
>
> FAIL: LLDB 
> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: 
> test_ref_and_ptr_dwo 
> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase)
>
> UNSUPPORTED: LLDB 
> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: 
> test_ref_and_ptr_gmodules 
> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) (test case does 
> not fall in any category of interest for this run)
>
> UNSUPPORTED: LLDB 
> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: 
> test_with_run_command_dsym 
> (TestDataFormatterLibcxxSet.LibcxxSetDataFormatterTestCase) (test case does 
> not fall in any category of interest for this run)
>
> FAIL: LLDB 
> (/usr/local/google/home/blaikie/dev/llvm/build/release/bin/clang-x86_64) :: 
> test_with_run_command_dwarf 
> 

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Code Review Process

[Raphael Isemann via lldb-dev]

Just two comments on the process here:

1. I don't think we can really make a 'wrong' decision regarding what
code review platform we use. While Github's review interface has its
own problems, it's not so bad that it would actually prevent people
from reviewing code. Having said that, the only way we could mess up
is if we end up with the situation that James describes, where we have
two groups in the community using different review platforms. And the
only way I can see this could happen is if we do the same thing we did
with Discord or Discourse where we just push some new system but we
don't have the consensus or critical mass to make everyone switch.
Both Discord and Discourse were IMHO good ideas in general and were
well intentioned, but the way we switched to them split & hurt the
community in the end. Given how critical code review is, I would
rather wait until we have enough consensus for the switch than just do
it and hope it works out well.

2. I do appreciate that the foundation/infrastructure group is trying
to improve our infrastructure, but I am not sure why the code review
system has become an apparently urgent issue. While Phabricator is
clearly going the way of the Dodo, from my own experience it at least
still works. Meanwhile both the mailing list and the bug tracker are
pretty much completely broken (the mailing list in the weird legal
spam limbo and the bugtracker having a disabled user registration). I
don't want to be the person that tells other people what to do, but if
we have resources/time to spend on fixing up our infrastructure, I
hope we could spend it on fixing the things that currently don't work.
Having a working bug tracker or some new mailing list system where I
(and other moderators) don't have to manually approve messages 24/7
and actually accept subscribers would be nice.

Thanks,
- Raphael

Am Mi., 6. Okt. 2021 um 19:34 Uhr schrieb Philip Reames via cfe-dev
:
>
> Since I think we're risking confusion on the point here, let me clarify that 
> at least my response to this thread should not be read as opposition (or 
> support) for a migration to github.  I am expressing no opinion on that 
> matter.  I see the primary point being discussed in this thread being the 
> decision making process proposed, not the decision itself.
>
> Philip
>
> On 10/6/21 10:26 AM, Chris Tetreault via llvm-dev wrote:
>
> > … nothing's really changed from the previous conversations on PRs versus 
> > Github, apart from the announcement of end of support by the upstream 
> > company, but that was quite a while ago now, and even with the stale 
> > Arcanist issue, there hasn't been a big push from community members to 
> > change …
>
>
>
> James, If you’ll forgive me for cherry-picking a small part of your point, I 
> think it bears mentioning that human beings tend to ignore future problems 
> until they become current problems. Most of us here want to work on 
> compilers, not deal with infrastructure. This doesn’t mean that the status 
> quo is ok.
>
>
>
> As I see it, it would be a mistake to just continue on with 
> zombie-phabricator as we have. Perhaps the board of directors could have 
> taken a different tone when presenting this issue, but I think they are doing 
> the right thing by forcing a change soon. Tools are degrading, and security 
> fixes are not being implemented. If we do nothing we’re all going to wake up 
> some day and find that the github repo has had its owner changed or somesuch 
> catastrophe. We need to do *something*, and I think setting a deadline for a 
> change was the right call.
>
>
>
> From my perspective, there are 4 reasonable things we can do, in order of 
> disruptiveness:
>
>
>
> Investigate a community replacement for phabricator. Does Phorge meet our 
> needs? Is there a maintained fork of phabricator? Can we just drop in some 
> replacement?
> Fork Phabricator, and take on the maintenance burden ourselves. This sounds 
> like work.
> Move to github PRs. As others have mentioned, there are pros and cons to this.
> Something else? We’d have to figure out what this is, and justify it over 
> options 1-3.
>
>
>
> If the deadline the board has set is unpalatable to the community, then 
> perhaps it makes sense to fork Phabricator, and then decide on a longer term 
> migration plan. But we need to do something and we need to do it now, not 
> when there’s an actual fire.
>
>
>
> Personally, I like Phabricator, and find github PRs to be tedious to work 
> with. If we went with github PRs, I would be able to work, but I would prefer 
> something more like phabricator.
>
>
>
> thanks,
>
>Chris Tetreault
>
>
>
> From: cfe-dev  On Behalf Of James Henderson 
> via cfe-dev
> Sent: Wednesday, October 6, 2021 1:47 AM
> To: Tanya Lattner 
> Cc: llvm-dev ; Renato Golin ; 
> clang developer list ; openmp-dev 
> (openmp-...@lists.llvm.org) ; LLDB Dev 
> 
> Subject: Re: [cfe-dev] [llvm-dev] RFC: Code Review Process
>
>
>
> WARNING: This email originated from 

Re: [lldb-dev] SB API questions

[Raphael Isemann via lldb-dev]

I think patches are always welcome and I don't see any problems with
the proposed new API (haven't really checked though if they are all
unavailable* through the SB API). The only downside to extending the
SB API is that we have to maintain it forever. So if we add an API
then it should be abstract enough that it doesn't restrict future
development of LLDB too much. Future development = internal
refactoring or porting to new platforms.

And I think the best way to propose a new API is maybe just making a
dummy patch that adds the API + documentation (doesn't need an actual
implementation or tests). And if everyone agrees the new API is fine
you can add the tests and implementation. By making a patch you also
automatically get everyone subscribed to your patch via Herald rules
or people reading the mailing list.

If you don't want to make patches, I think bug reports on
bugs.llvm.org could also work. Most of the thing you describe sound
like they don't need a lot of effort to implement/test, so there's a
good chance someone will implement it for you.

Cheers,
- Raphael

*Without falling back to the CommandInterpreter

Am Sa., 29. Mai 2021 um 11:12 Uhr schrieb Bruce Mitchener via lldb-dev
:
>
> Hello,
>
> I've recently been working on and with my Rust bindings to the public LLDB 
> API after a break of a couple of years.
>
> A couple of things that I'm noticing or re-noticing:
>
> We need more SB API coverage of logging functionality. We can't list 
> channels, categories via the SB API. We also don't have a call for disabling 
> log output once it has been enabled. These seem fairly straightforward to add.
>
> While the underlying platform objects support finding processes, this isn't 
> exposed to the SB API, so there's no way to get a nice list of the running 
> processes using only the SB API. Has anyone looked at this or thought about 
> the API?
>
> It would be helpful in some cases, especially with the above, to extend 
> SBProcessInfo to include arguments / argv, environment, and architecture. 
> These are already present in the underlying data, just not exposed via 
> SBProcessInfo.
>
> Any thoughts or objections on the above? Would patches be welcome?
>
> Are there others using the SB API a lot that might be willing to discuss this 
> sort of stuff more?
>
>  - Bruce
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Help fixing deadlock in DWARF symbol preloading

[Raphael Isemann via lldb-dev]

We could also just give the Module a std::string with the description
and update it in the few places where we actually update it. The
m_arch already has a setter in place that just needs to be used in a
few more places, so the infrastructure is kind of already there (at
least for m_arch). The description would just have its own mutex.


Am Fr., 5. Feb. 2021 um 00:39 Uhr schrieb Jorge Gorbe Moya via
lldb-dev :
>
> Wouldn't it be preferable to try_lock in GetDescription (which is the one 
> currently acquiring the mutex) instead? ReportError doesn't touch any mutex 
> itself and will happily report the rest of the error if GetDescription bails 
> out. For the test case I sent it would look like this:
>
> error:  {0x000b}: invalid abbreviation code 123, please file a bug and 
> attach the file at the start of this error message
> error:  {0x000b}: invalid abbreviation code 123, please file a bug and 
> attach the file at the start of this error message
> error:  {0x000b}: invalid abbreviation code 123, please file a bug and 
> attach the file at the start of this error message
>
> which is way better than a deadlock IMO.
>
>
>
>
> On Thu, Feb 4, 2021 at 12:16 PM Pavel Labath  wrote:
>>
>> Please have a look at
>> ,
>> which is the last time this came up.
>>
>>
>> One quick'n'dirty solution would be to have `Module::ReportError` _try_
>> to get the module lock, and if it fails, just bail out. That obviously
>> means you won't get to see the error message which triggerred the
>> deadlock (though we could also play around with that and try printing
>> the error message without the module description or something), but it
>> will at least get you past that point...
>>
>> pl
>>
>> On 04/02/2021 21:04, Jorge Gorbe Moya via lldb-dev wrote:
>> > Hi,
>> >
>> > I've found a deadlock in lldb (see attached test case, you can build it
>> > with just `clang -o test test.s`), but I'm a total newbie and I have no
>> > idea what's the right way to fix it.
>> >
>> > The problem happens when an error is found during DIE extraction when
>> > preloading symbols. As far as I can tell, it goes like this:
>> >
>> > 1. Module::PreloadSymbols locks Module::m_mutex
>> > 2. A few layers below it, we end up in ManualDWARFIndex::Index, which
>> > dispatches DIE extractions to a thread pool:
>> >
>> > |for (size_t i = 0; i < units_to_index.size(); ++i)
>> > pool.async(extract_fn, i); pool.wait(); |
>> >
>> > 3. extract_fn in the snippet above ends up executing
>> > DWARFDebugInfoEntry::Extract and when there's an error during
>> > extraction, Module::GetDescription is called while generating the error
>> > message.
>> > 4. Module::GetDescription tries to acquire Module::m_mutex from a
>> > different thread, while the main thread has the mutex already locked and
>> > it's waiting for DIE extraction to end, causing a deadlock.
>> >
>> > If we make Module::GetDescription not lock the problem disappears, so
>> > the diagnosis looks correct, but I don't know what would be the right
>> > way to fix it. Module::GetDescription looks more or less safe to call
>> > without locking: it just prints m_arch, m_file, and m_object_name to a
>> > string, and those look like fields that wouldn't change after the Module
>> > is initialized, so maybe it's okay? But I feel like there must be a
>> > better solution anyway. Any advice?
>> >
>> > Best,
>> > Jorge
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> >
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Evaluating the same expression at the same breakpoint gets slower after a certain number of steps

[Raphael Isemann via lldb-dev]

The test 
lldb/packages/Python/lldbsuite/test/lang/cpp/member-and-local-vars-with-same-name/main.cpp
is testing this feature, so you should get a 10 (instead of a correct
12345) when you break in main.cpp:31 in this test and eval "expr a"
while you have this feature disabled. At least for me that's the case.

- Raphael

Am Do., 22. Aug. 2019 um 16:31 Uhr schrieb Scott Funkenhauser via
lldb-dev :
>
> Hey Jim,
>
> We just noticed that 'target.experimental.inject-local-vars' is true by 
> default. If we disable that experimental the performance for expression 
> evaluation is significantly better.
>
> From the flag description:
> "If true, inject local variables explicitly into the expression text. This 
> will fix symbol resolution when there are name collisions between ivars and 
> local variables. But it can make expressions run much more slowly."
>
> I put together a simple example:
> class bar {
>  public:
>   int foo = 2;
>   int Run(int foo) {
> return foo + 1;
>   }
> };
>
> Evaluating 'foo' when stopped in bar.Run() seems to work as expected. Is 
> there something I'm not capturing in my example? Do you have an example of a 
> name collision that the experimental flag fixes?
>
>
> On Mon, Jul 15, 2019 at 1:53 PM Guilherme Andrade via lldb-dev 
>  wrote:
>>
>> Gábor,
>> Thanks for pointing this out to me. The AST changes - the resulting log 
>> increases from 7k lines to 11k. I also verified that the fallback branch is 
>> executed. 18k iterations during the first evaluation and 93k afterwards. 
>> However, that only results in a couple extra milliseconds slowness (~ 4 ms), 
>> whereas the overall performance hit is in the order of hundreds.
>>
>> Jim,
>> Thank you for the explanation. I think I understand the lazy approach for 
>> types realization, but it is still not clear to me how that could cause the 
>> performance to degrade. If we encounter an already realized type, won't that 
>> save us work and make things run faster? Do you know of other points in the 
>> code that could be particularly sensitive to the realized types pool size 
>> (something like the branch Gábor mentioned)?
>>
>> On Fri, Jul 12, 2019 at 6:08 AM Gábor Márton  wrote:
>>>
>>> Guilherme,
>>>
>>> Could you please check if you have any structural differences between the 
>>> ASTs you see when
>>> 1) you first evaluate your expression at breakpoint A
>>> 2) you evaluate your expression the second time at breakpoint A ?
>>> The AST of the expression evaluator's context is dumped once a TagDecl is 
>>> completed, but you need to enable a specific logging: (log enable lldb ast).
>>>
>>> I have a theory about the root cause of the slowness you experience, but it 
>>> requires proof from your test scenario.
>>> There are known problems with the lookup we use in LLDB [1].
>>> If the lookup mechanism cannot find a symbol then clang::ASTImporter will 
>>> create a new AST node.
>>> Thus I am expecting a growing AST in your case at 2) with duplicated and 
>>> redundant AST nodes.
>>> Why would the grown AST results in any slowness?
>>> Because the lookup we use is in `clang::DeclContext::localUncachedLookup()` 
>>> and it has a fallback branch which I assume is executed in your case:
>>> ```
>>>   // Slow case: grovel through the declarations in our chain looking for
>>>   // matches.
>>>   // FIXME: If we have lazy external declarations, this will not find them!
>>>   // FIXME: Should we CollectAllContexts and walk them all here?
>>>   for (Decl *D = FirstDecl; D; D = D->getNextDeclInContext()) {
>>> if (auto *ND = dyn_cast(D))
>>>   if (ND->getDeclName() == Name)
>>> Results.push_back(ND);
>>>   }
>>> ```
>>> This for loop does a linear search on the list of the decls of a decl 
>>> context, which explains the slowing factor as the AST grows.
>>> I wounder if you could help proving this theorem by first checking if the 
>>> AST grows and if yes then checking if this linear search is executed or not.
>>>
>>> [1] If a symbol is in an `extern "C"` block then the existing lookup fails 
>>> to find it. I try to fix it in https://reviews.llvm.org/D61333
>>>
>>> Thanks,
>>> Gabor
>>>
>>> On Thu, Jul 11, 2019 at 8:24 PM Jim Ingham via lldb-dev 
>>>  wrote:

 lldb realizes types from DWARF lazily.  So for instance, if an expression 
 refers to a pointer to type Foo, we won't necessarily realize the full 
 type of Foo from DWARF to parse that expression.  Then if you write a 
 second expression that accesses a member of an object of type Foo, we will 
 realize the full type for Foo.  Then if you run the first expression 
 again, the pointer to Foo type in the lldb type system will now point to a 
 realized type of Foo.  That should not make any difference, since if we 
 were right the first time that we didn't need to know anything about Foo, 
 it shouldn't matter whether the full type is realized or not.

 Similarly, the "expression with no side effects" could have also 

Re: [lldb-dev] lldb-mi has been moved to its own GitHub repository

[Raphael Isemann via lldb-dev]

Agreed, I made a PR (which is work in progress):
https://github.com/lldb-tools/lldb-mi/pull/5 (I didn't try compiling
against a compiled LLDB, so that is subject to change).

Am Di., 13. Aug. 2019 um 19:29 Uhr schrieb Ted Woodward :
>
> The build instructions in README.md are a tad sparse:
>
> Build
>
> cmake . ; cmake --build .
>
>
>
>
>
> Where do we put it in relation to an lldb build?
>
> Does it need the llvm/lldb sources?
>
> Is it built against an lldb build, or an lldb install?
>
>
>
> Ted
>
>
>
> From: lldb-dev  On Behalf Of Raphael 
> “Teemperor” Isemann via lldb-dev
> Sent: Tuesday, August 13, 2019 3:18 AM
> To: LLDB 
> Subject: [EXT] [lldb-dev] lldb-mi has been moved to its own GitHub repository
>
>
>
> Hi all,
>
> lldb-mi has been moved out of the LLDB source tree into its own GitHub 
> repository here: https://github.com/lldb-tools/lldb-mi lldb-mi is now a 
> standalone tool that builds against LLDB, but is no longer build as part of 
> LLDB. The implications for users are:
>
> 1. Package maintainers need to package lldb-mi and no longer receive the 
> lldb-mi executable as a side product of LLDB. The lldb-mi build system is 
> very simple, so I don’t expect a lot of problems arising from this change. 
> Note: You can *NOT* drop in the lldb-mi source into the old folder inside the 
> LLDB source tree. You need to first build LLDB and then build lldb-mi against 
> it.
>
> 2. If you encounter bugs with lldb-mi, please file a report on the GitHub 
> project and *NOT* on the LLVM bugzilla. We closed all lldb-mi bugs on 
> bugzilla, so if you think your issue with lldb-mi still exists, please copy 
> your bug report to GitHub.
>
>
>
> In other news: lldb-mi is also in need of a maintainer!
>
>
>
> The good thing is that with this change lldb-mi you can now make pull 
> requests against the project, we set up a CI system and in general its easier 
> to get started with lldb-mi. Note that during the move lldb-mi lost its test 
> suit, meaning that there are currently no tests run in the CI. This was 
> mostly because we couldn’t port over the old test suit (which depended on the 
> internal LLDB python test suit) and because most of the tests we had were 
> anyway disabled due to random failures. If you want to get started, feel free 
> to make pull requests with tests (preferable more reliable than the old ones 
> we had).
>
>
>
> I’m mostly writing this as the change was buried in the RFC thread last month 
> and it seems all downstream folks are still completely unaware this.
>
>
>
> TL;DR: LLDB no longer provides the lldb-mi executable. You now need to 
> get lldb-mi from the GitHub repository above.
>
>
>
> Cheers,
>
> - Raphael
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bugzilla default-assignee vs default-cc

[Raphael Isemann via lldb-dev]

Yeah, the latter sounds more like what I had in mind.

And thanks for doing this by the way!

- Raphael

Am Fr., 12. Apr. 2019 um 11:12 Uhr schrieb Jonas Devlieghere
:
>
> On Fri, Apr 12, 2019 at 10:56 AM Raphael Isemann  wrote:
>>
>> Can't we just have a list like lldb-bugs (similar to llvm-bugs) as the
>> default-cc? This way I would have all the bugzilla talk also available
>> in my mail, which means I can use my mail client to read comments and
>> search them. And people that don't care about every bug update just
>> don't subscribe to this list.
>
>
> Would that be in addition to having lldb dev as the default assignee (as is 
> the case today) or instead (using unassigned) so Bugzilla traffic only goes 
> to that list? If you mean the latter, then +1 from me too.
>
>>
>> - Raphael
>>
>> Am Fr., 12. Apr. 2019 um 10:33 Uhr schrieb Pavel Labath via lldb-dev
>> :
>> >
>> > On 12/04/2019 10:25, Jonas Devlieghere via lldb-dev wrote:
>> > > I was talking to one of the Bugzilla admins (Kristof) earlier today and
>> > > he pointed out that the default assignee for lldb bugs in the lldb-dev
>> > > list, and that it might be better to change that from default-assignee
>> > > to default-cc. That way, when the bug gets assigned, the mailing list
>> > > continues to get updates.
>> > >
>> > > I guess changing this depends on what our intentions are: do we just
>> > > want to notify the mailing list of new bugs or if we want to keep the
>> > > list in the loop for every bug. The latter might mean more traffic,
>> > > depending on how many people actually assign bugs to themselves.
>> > >
>> > > Please speak up if you think this is worth changing!
>> > >
>> > > Cheers,
>> > > Jonas
>> > >
>> >
>> > I actually think the current behaviour strikes a good balance for the
>> > noise-to-signal ratio.
>> >
>> > Speaking for myself, I wouldn't want to get an email for every update to
>> > all lldb bugs out there. However, I like to have an overview of new bugs
>> > coming in, and when I find a particular bug interesting, I can always
>> > add myself to the cc list so I am notified of updates to the bugs I care
>> > about.
>> >
>> > pl
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Bugzilla default-assignee vs default-cc

[Raphael Isemann via lldb-dev]

Can't we just have a list like lldb-bugs (similar to llvm-bugs) as the
default-cc? This way I would have all the bugzilla talk also available
in my mail, which means I can use my mail client to read comments and
search them. And people that don't care about every bug update just
don't subscribe to this list.

- Raphael

Am Fr., 12. Apr. 2019 um 10:33 Uhr schrieb Pavel Labath via lldb-dev
:
>
> On 12/04/2019 10:25, Jonas Devlieghere via lldb-dev wrote:
> > I was talking to one of the Bugzilla admins (Kristof) earlier today and
> > he pointed out that the default assignee for lldb bugs in the lldb-dev
> > list, and that it might be better to change that from default-assignee
> > to default-cc. That way, when the bug gets assigned, the mailing list
> > continues to get updates.
> >
> > I guess changing this depends on what our intentions are: do we just
> > want to notify the mailing list of new bugs or if we want to keep the
> > list in the loop for every bug. The latter might mean more traffic,
> > depending on how many people actually assign bugs to themselves.
> >
> > Please speak up if you think this is worth changing!
> >
> > Cheers,
> > Jonas
> >
>
> I actually think the current behaviour strikes a good balance for the
> noise-to-signal ratio.
>
> Speaking for myself, I wouldn't want to get an email for every update to
> all lldb bugs out there. However, I like to have an overview of new bugs
> coming in, and when I find a particular bug interesting, I can always
> add myself to the cc list so I am notified of updates to the bugs I care
> about.
>
> pl
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Test suite failures on Fedora Linux?

[Raphael Isemann via lldb-dev]

Sorry, was traveling and the internet wasn't good enough for git.
Thanks for pushing a fix Pavel!

- Raphael

Am Mi., 27. März 2019 um 16:37 Uhr schrieb Pavel Labath via lldb-dev
:
>
> On 26/03/2019 14:48, David Zarzycki via lldb-dev wrote:
> >
> >> On Mar 26, 2019, at 3:07 AM, Jan Kratochvil
> >>  wrote:
> >>
> >> On Mon, 25 Mar 2019 19:47:36 +0100, David Zarzycki via lldb-dev
> >> wrote:
> >>> Also, given that two of the test failures are Intel specific (the
> >>> mxcsr register write failures), what class of hardware do you
> >>> use? My workstation is Skylake-SP based, if it matters.
> >>
> >> OK, I agree it PASSes for me on Haswell-EP (E5-2630v3) but it also
> >> FAILs for me on Kaby Lake Refresh (i7-8650U).  Also
> >> kernel-5.0.3-200.fc29.x86_64.
> >
> > It looks like this is a known issue:
> >
> > https://bugs.llvm.org/show_bug.cgi?id=39958
> >
>
> Ok, so I've managed to get a hold of a machine which reproduces this
> problem. It's a debian based system running linux 4.19, which should
> confirm that this is a hardware issue.
>
> I'll try to find some time to diagnose this later this week. My guess is
> that we're just setting some mxcsr value that these CPUs don't like, and
> we need to be more conservative in what we write in the tests.
>
>
> > Any ETA on renaming the variables? The bug you mentioned also had
>  > someone offer to rename the variables in late 2017, but that seemingly
>  > never happened.
>
> I believe the rename that bug is referring to really did happen. What
> you are seeing is a new test, which also uses "a" as a meaningless
> identifier.
>
> I'll do the rename right away.
>
> pl
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Test suite failures on Fedora Linux?

[Raphael Isemann via lldb-dev]

The import-std-module patches are probably just llvm.org/pr35043, so
I'll rename the variables there and that should fix it. Not sure about
the others.

- Raphael

Am Mo., 25. März 2019 um 12:06 Uhr schrieb David Zarzycki via lldb-dev
:
>
> Hello,
>
> I’m trying to build/test/run the latest lldb on the latest Red Hat Fedora, 
> but I’m seeing four failures. Is this expected? What operating system do the 
> LLVM build bots run? Thanks!
>
> Dave
>
> [1+3] Python script sym-linking LLDB Python API
> [1+2] Preparing lit tests
> [1+1] cd /home/dave/s/lc/clang/bindings/python && /usr/bin/cmake -E env 
> CLANG_LIBRARY_PATH=/home/dave/s/lc/t/lib /usr/bin/python2.7 -m unittest 
> discover
> ..LIBCLANG TOOLING ERROR: 
> fixed-compilation-database: Error while opening fixed database: No such file 
> or directory
> json-compilation-database: Error while opening JSON database: No such file or 
> directory
>
> ..ss.s...s...s.s
> --
> Ran 126 tests in 0.775s
>
> OK (skipped=6)
> [0+1] Running all regression tests
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> clang: /home/dave/s/lc/t/bin/clang
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> ld.lld: /home/dave/s/lc/t/bin/ld.lld
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> lld-link: /home/dave/s/lc/t/bin/lld-link
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> ld64.lld: /home/dave/s/lc/t/bin/ld64.lld
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> wasm-ld: /home/dave/s/lc/t/bin/wasm-ld
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> clang: /home/dave/s/lc/t/bin/clang
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> ld.lld: /home/dave/s/lc/t/bin/ld.lld
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> lld-link: /home/dave/s/lc/t/bin/lld-link
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> ld64.lld: /home/dave/s/lc/t/bin/ld64.lld
> llvm-lit: /home/dave/s/lc/llvm/utils/lit/lit/llvm/config.py:337: note: using 
> wasm-ld: /home/dave/s/lc/t/bin/wasm-ld
> llvm-lit: /home/dave/s/lc/t/utils/lit/tests/lit.cfg:67: note: Found python 
> psutil module
> Deleting module cache at 
> /home/dave/s/lc/t/./lib/../lldb-test-build.noindex/module-cache-clang.
> Deleting module cache at 
> /home/dave/s/lc/t/./lib/../lldb-test-build.noindex/module-cache-lldb.
> -- Testing: 48524 tests, 96 threads --
> Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.
> FAIL: lldb-Suite :: 
> expression_command/import-std-module/conflicts/TestStdModuleWithConflicts.py 
> (47488 of 48524)
>  TEST 'lldb-Suite :: 
> expression_command/import-std-module/conflicts/TestStdModuleWithConflicts.py' 
> FAILED 
> lldb version 9.0.0 (https://git.llvm.org/git/lldb.git revision 
> 1320ed17c93bf30b522dd71573a41e7d0a4950a8)
>   clang revision 805d58dd43c1329590299f37ad2f48efbae3c78b
>   llvm revision 6e821f01513dd49ed1668b65d10b2dbd07801d39
> LLDB library dir: /home/dave/s/lc/t/bin
> LLDB import library dir: /home/dave/s/lc/t/bin
> Skipping following debug info categories: ['dsym', 'gmodules']
>
> Session logs for test failures/errors/unexpected successes will go into 
> directory '/home/dave/s/lc/t/lldb-test-traces'
> Command invoked: /home/dave/s/lc/lldb/test/dotest.py -q --arch=x86_64 -s 
> /home/dave/s/lc/t/lldb-test-traces --build-dir 
> /home/dave/s/lc/t/lldb-test-build.noindex -S nm -u CXXFLAGS -u CFLAGS 
> --executable /home/dave/s/lc/t/./bin/lldb --dsymutil 
> /home/dave/s/lc/t/./bin/dsymutil --filecheck 
> /home/dave/s/lc/t/./bin/FileCheck -C /home/dave/s/lc/t/./bin/clang --env 
> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy --env 
> LLVM_LIBS_DIR=/home/dave/s/lc/t/./lib 
> /home/dave/s/lc/lldb/packages/Python/lldbsuite/test/expression_command/import-std-module/conflicts
>  -p TestStdModuleWithConflicts.py
> UNSUPPORTED: LLDB (/home/dave/s/lc/t/bin/clang-9-x86_64) :: test_dsym 
> (TestStdModuleWithConflicts.TestImportStdModuleConflicts) (test case does not 
> fall in any category of interest for this run)
> FAIL: LLDB (/home/dave/s/lc/t/bin/clang-9-x86_64) :: test_dwarf 
> (TestStdModuleWithConflicts.TestImportStdModuleConflicts)
> UNSUPPORTED: LLDB (/home/dave/s/lc/t/bin/clang-9-x86_64) :: test_dwo 
> (TestStdModuleWithConflicts.TestImportStdModuleConflicts) (skipping due to 
> the following parameter(s): debug info format)
> UNSUPPORTED: LLDB (/home/dave/s/lc/t/bin/clang-9-x86_64) :: test_gmodules 
> (TestStdModuleWithConflicts.TestImportStdModuleConflicts) (test case does not 
> fall in any category of interest for this run)
> 

Re: [lldb-dev] Stackoverflow crash when evaluating an invalid expression

[Raphael Isemann via lldb-dev]

You can also dump() the AST to a file on disk if that is easier to
capture than stderr. See the overload of `dump()` that takes a stream:
https://clang.llvm.org/doxygen/ASTDumper_8cpp_source.html#l00225

- Raphael

Am Do., 7. März 2019 um 19:20 Uhr schrieb Ben Ruthig :
>
> Hey Raphael,
>
> Yes, you did advise me to drop a D->dumpColor() call in to 
> getASTRecordLayout().  For frustrating reasons I still haven't been able to 
> capture those logs but when I do I will report back.
>
> Thanks so much for your help and quick response!
>
> Ben
>
> On Thu, Mar 7, 2019 at 12:56 PM Raphael Isemann  wrote:
>>
>> Hi Ben,
>>
>> I think I already answered this last week:
>> http://lists.llvm.org/pipermail/lldb-dev/2019-February/014789.html
>>
>> I don't think you'll get an answer here without posting the
>> problematic source or giving any more information as I described in my
>> mail.
>>
>> Cheers,
>> - Raphael
>>
>> Am Do., 7. März 2019 um 18:13 Uhr schrieb Ben Ruthig via lldb-dev
>> :
>> >
>> > Hello all,
>> >
>> > I am currently investigating an issue where LLDB is crashing due to a 
>> > stack overflow when attempting to evaluate an expression.  I have seen the 
>> > same issue in 6.0.1 and have reproduced it in 7.0.1.  Any help to diagnose 
>> > and fix would be greatly appreciated as I am trying to meet a release 
>> > deadline early next week!
>> >
>> > The facts:
>> > - The expression being evaluated is not a valid expression in the C++ 
>> > domain. For example the expression is a datatype like 'Foobar'.  (For 
>> > reasons unexplained I am constrained to supporting this use case.)
>> > - The crash occurs when using the C++ LLDB API but not when trying to 
>> > evaluate the expression via the LLDB shell or the LLDB Python script 
>> > shell.  However, when doing 'expr Foobar' there is no output and the 
>> > operation is completely silent.  It is similar when trying to do 
>> > 'lldb.frame.EvaluateExpression("Foobar")' in the Python shell as well.  I 
>> > would expect to get some error output or an SbValue in an error state but 
>> > no such luck.
>> > - I was able to capture a stack trace (attached) and it seems to be a 
>> > recursive loop bottoming out.  For brevity two 'loops' of stacktrace are 
>> > included here:
>> >
>> > 3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
>> > clang::RecordDecl * D) Line 2965C++
>> > 3388.  liblldb.dll!`anonymous 
>> > namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
>> > 3389.  liblldb.dll!`anonymous 
>> > namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
>> > Context, const clang::CXXRecordDecl * Class) Line 172C++
>> > 3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
>> > clang::RecordDecl * D) Line 2965C++
>> > 3391.  liblldb.dll!`anonymous 
>> > namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
>> > 3392.  liblldb.dll!`anonymous 
>> > namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
>> > Context, const clang::CXXRecordDecl * Class) Line 172C++
>> > 3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
>> > clang::RecordDecl * D) Line 2965C++
>> >
>> > Help please :S
>> >
>> > Thanks,
>> > Ben
>> >
>> >
>> > ___
>> > lldb-dev mailing list
>> > lldb-dev@lists.llvm.org
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
> --
> "Sometimes I've believed as many as six impossible things before breakfast" - 
> Alice in Wonderland
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Stackoverflow crash when evaluating an invalid expression

[Raphael Isemann via lldb-dev]

Hi Ben,

I think I already answered this last week:
http://lists.llvm.org/pipermail/lldb-dev/2019-February/014789.html

I don't think you'll get an answer here without posting the
problematic source or giving any more information as I described in my
mail.

Cheers,
- Raphael

Am Do., 7. März 2019 um 18:13 Uhr schrieb Ben Ruthig via lldb-dev
:
>
> Hello all,
>
> I am currently investigating an issue where LLDB is crashing due to a stack 
> overflow when attempting to evaluate an expression.  I have seen the same 
> issue in 6.0.1 and have reproduced it in 7.0.1.  Any help to diagnose and fix 
> would be greatly appreciated as I am trying to meet a release deadline early 
> next week!
>
> The facts:
> - The expression being evaluated is not a valid expression in the C++ domain. 
> For example the expression is a datatype like 'Foobar'.  (For reasons 
> unexplained I am constrained to supporting this use case.)
> - The crash occurs when using the C++ LLDB API but not when trying to 
> evaluate the expression via the LLDB shell or the LLDB Python script shell.  
> However, when doing 'expr Foobar' there is no output and the operation is 
> completely silent.  It is similar when trying to do 
> 'lldb.frame.EvaluateExpression("Foobar")' in the Python shell as well.  I 
> would expect to get some error output or an SbValue in an error state but no 
> such luck.
> - I was able to capture a stack trace (attached) and it seems to be a 
> recursive loop bottoming out.  For brevity two 'loops' of stacktrace are 
> included here:
>
> 3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> clang::RecordDecl * D) Line 2965C++
> 3388.  liblldb.dll!`anonymous 
> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
> 3389.  liblldb.dll!`anonymous 
> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
> Context, const clang::CXXRecordDecl * Class) Line 172C++
> 3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> clang::RecordDecl * D) Line 2965C++
> 3391.  liblldb.dll!`anonymous 
> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
> 3392.  liblldb.dll!`anonymous 
> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
> Context, const clang::CXXRecordDecl * Class) Line 172C++
> 3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> clang::RecordDecl * D) Line 2965C++
>
> Help please :S
>
> Thanks,
> Ben
>
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Stackoverflow crash when evaluating an invalid expression

[Raphael Isemann via lldb-dev]

The most likely explanation is that we somehow build a Clang AST where
a class has it's itself as a base class or as a field type. Not sure
how that happened, but I assume something like CRTP could maybe
trigger such a bug.

Please break in `getASTRecordLayout` and run `D->dumpColor()` in two
different frames and post the output. Otherwise if you have a Release
build which you can modify, you can also add `D->dumpColor()` as the
first statement in clang::ASTContext::getASTRecordLayout (the file is
`llvm-project/clang/lib/AST/RecordLayoutBuilder.cpp:2965` ). This
should print the class which we presumably incorrectly reconstructed
and it's structure.

- Raphael

Am Do., 28. Feb. 2019 um 16:48 Uhr schrieb Ben Ruthig via lldb-dev
:
>
> Hello all,
>
> I am currently investigating an issue where LLDB is crashing due to a stack 
> overflow when attempting to evaluate an expression.  I have seen the same 
> issue in 6.0.1 and have reproduced it in 7.0.1.  Any help to diagnose and fix 
> would be greatly appreciated as I am trying to meet a release deadline early 
> next week!
>
> The facts:
> - The expression being evaluated is not a valid expression in the C++ domain. 
> For example the expression is a datatype like 'Foobar'.  (For reasons 
> unexplained I am constrained to supporting this use case.)
> - The crash occurs when using the C++ LLDB API but not when trying to 
> evaluate the expression via the LLDB shell or the LLDB Python script shell.  
> However, when doing 'expr Foobar' there is no output and the operation is 
> completely silent.  It is similar when trying to do 
> 'lldb.frame.EvaluateExpression("Foobar")' in the Python shell as well.  I 
> would expect to get some error output or an SbValue in an error state but no 
> such luck.
> - I was able to capture a stack trace (attached) and it seems to be a 
> recursive loop bottoming out.  For brevity two 'loops' of stacktrace are 
> included here:
>
> 3387.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> clang::RecordDecl * D) Line 2965C++
> 3388.  liblldb.dll!`anonymous 
> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
> 3389.  liblldb.dll!`anonymous 
> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
> Context, const clang::CXXRecordDecl * Class) Line 172C++
> 3390.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> clang::RecordDecl * D) Line 2965C++
> 3391.  liblldb.dll!`anonymous 
> namespace'::EmptySubobjectMap::ComputeEmptySubobjectSizes() Line 216C++
> 3392.  liblldb.dll!`anonymous 
> namespace'::EmptySubobjectMap::EmptySubobjectMap(const clang::ASTContext & 
> Context, const clang::CXXRecordDecl * Class) Line 172C++
> 3393.  liblldb.dll!clang::ASTContext::getASTRecordLayout(const 
> clang::RecordDecl * D) Line 2965C++
>
> Help please :S
>
> Thanks,
> Ben
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [8.0.0 Release] Please write release notes

[Raphael Isemann via lldb-dev]

I'm not sure what to do with potential LLDB release notes. Should I
just add a LLDB section to the LLVM release notes or do we actually
have a separate file for LLDB like clang/libcxx/lld do?

- Raphael

Am Di., 19. Feb. 2019 um 16:26 Uhr schrieb Hans Wennborg via lldb-dev
:
>
> Hello everyone,
>
> This is your biannual release notes nag email.
>
> We're getting closer to the end of the release schedule for 8.0.0, but
> the release notes are still very thin for many parts.
>
> When the release happens, the first thing people look at are these
> notes, so it's a great opportunity to mention the work that's been
> done in the past six months.
>
> If you know anything that's worth adding, please commit to the release
> notes directly on the branch, or send me a patch, or even a plain
> email with some text and I'll happily commit it for you.
>
> Thanks,
> Hans
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [RFC] Using Sphinx to generate documentation

[Raphael Isemann via lldb-dev]

I think if we want to actually lower the entry barrier for
contributing/fixing things on the website, then the server should do
this. From what I know the other LLVM projects also generate the HTML
on the server (at least I've never seen anyone commit generated HTML
files), so this hopefully shouldn't be too complicated.

I think in general this approach is really nice. Thanks a lot for the
work @Jonas!

- Raphael


Am Fr., 7. Dez. 2018 um 09:06 Uhr schrieb Pavel Labath via lldb-dev
:
>
> On 06/12/2018 18:02, Jonas Devlieghere via lldb-dev wrote:
> > Hi everyone,
> >
> > The current LLDB website is written in HTML which is hard to maintain.
> > We have quite a bit of HTML code checked in which can make it hard to
> > differentiate between documentation written by us and documentation
> > generated by a tool. Furthermore I think text/RST files provide a lower
> > barrier for new or casual contributors to fix or update.
> >
> > In line with the other LLVM projects I propose generating the
> > documentation with Sphix. I created a patch
> > (https://reviews.llvm.org/D55376) that adds a new target docs-lldb-html
> > when -DLLVM_ENABLE_SPHINX:BOOL is enabled. I've ported over some pages
> > to give an idea of what this would look like in-tree. Before continuing
> > with this rather tedious work I'd like to get feedback form the community.
> >
> > Initially I started with the theme used by Clang because it's a default
> > theme and doesn't require configuration. If we want to keep the sidebar
> > we could use the one used by LLD.
> >
> > Please let me know what you think.
> >
> > Thanks,
> > Jonas
> >
>
> Woohoo!
>
> Just to be clear, is the idea to still check in the resulting html files
> to remain compatible with how http://lldb.llvm.org (I have no idea who
> maintains that) works, or do you want to change that as well (e.g., by
> having the server generate the html files locally).
>
> pl
> ___
> 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] The lit test driver gets killed because of SIGHUP

[Raphael Isemann via lldb-dev]

@Jonas: Did you confirm it is SIGHUP? I remember that we were not sure
whether the signal kind was SIGHUP or SIGINT.

- Raphael
Am Mi., 5. Dez. 2018 um 10:25 Uhr schrieb Pavel Labath via lldb-dev
:
>
> On 05/12/2018 03:49, Jonas Devlieghere via lldb-dev wrote:
> > Hi everyone,
> >
> > Since we switched to lit as the test driver we've been seeing it getting 
> > killed as the result of a SIGHUP signal. The problem doesn't reproduce on 
> > every machine and there seems to be a correlation between number of 
> > occurrences and thread count.
> >
> > Davide and Raphael spent some time narrowing down what particular test is 
> > causing this and it seems that TestChangeProcessGroup.py is always 
> > involved. However it never reproduces when running just this test. I was 
> > able to reproduce pretty consistently with the following filter:
> >
> > ./bin/llvm-lit ../llvm/tools/lldb/lit/Suite/ --filter="process"
> >
> > Bisecting the test itself didn't help much, the problem reproduces as soon 
> > as we attach to the inferior.
> >
> > At this point it is still not clear who is sending the SIGHUP and why it's 
> > reaching the lit test driver. Fred suggested that it might have something 
> > to do with process groups (which would be an interesting coincidence given 
> > the previously mentioned test) and he suggested having the test run in 
> > different process groups. Indeed, adding a call to os.setpgrp() in lit's 
> > executeCommand and having a different process group per test prevent us 
> > from seeing this. Regardless of this issue I think it's reasonable to have 
> > tests run in their process group, so if nobody objects I propose adding 
> > this to lit in llvm.
> >
> > Still, I'd like to understand where the signal is coming from and fix the 
> > root cause in addition to the symptom. Maybe someone here has an idea of 
> > what might be going on?
> >
> > Thanks,
> > Jonas
> >
> > PS
> >
> > 1. There's two places where we send a SIGHUP ourself, with that code 
> > removed we still receive the signal, which suggests that it might be coming 
> > from Python or the OS.
> > 2. If you're able to reproduce you'll see that adding an early return 
> > before the attach in TestChangeProcessGroup.py hides/prevents the problem. 
> > Moving the return down one line and it pops up again.
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
> Hi Jonas,
>
> Sounds like you have found an interesting issue to debug. I've tried
> running the command you mention locally, and I didn't see any failures
> in 100 runs.
>
> There doesn't seem to be anything in the TestChangeProcessGroup which
> sends a signal, though I can imagine that the act of changing a process
> group mid-debug could be enough to confuse someone to send it. However,
> I am having trouble reconciling this with your PS #2, because if
> attaching is sufficient to trigger this (i.e., no group changing takes
> place), then this test is not much different than any other test where
> we spawn an inferior and then attach to it.
>
> I am aware of one other instance where we send a spurious signal, though
> it's SIGINT in this case
> .
> The issue there is that we don't check whether the debug server has
> exited before we send SIGINT to it (which it normally does on its own at
> the end of debug session). So if the debug server does exit and its pid
> gets recycled before we get a chance to send this signal, we can end up
> killing a random process.
>
> Now this may seem unrelated to your issue, but SIGHUP is sent
> automatically as a result of a process losing its controlling tty. So,
> if that SIGINT ends up killing the process holding the master end of a
> pty, this could result in some SIGHUPs being sent too. Unfortunately,
> this doesn't fully stack up either, because the process holding the
> master pty is probably a long-lived one, so its pid is unlikely to match
> one of the transient debugserver pids. Nevertheless, it could be worth
> just commenting out that line and seeing what happens.
>
> For debugging, maybe you could try installing a SIGHUP handler into the
> lit process, which would dump the received siginfo_t structure. Decoding
> that may provide some insight into who is sending that signal (si_pid)
> and why (si_code).
>
> As for adding process group support into lit, I think that having each
> test run (*not* each executed command) in it's own group is reasonable.
> However, be aware that this changes the behaviour of how all signals (in
> particular the SIGINT you get when typing ^C) get delivered. AFAIK, lit
> doesn't have any special code for cleaning up the spawned processes and
> relies on the fact that ^C will send a SIGINT to the entire "foreground
> process group" and terminate stuff. If you start creating a 

Re: [lldb-dev] [cfe-dev] ASTImporter patches and improvements, please help

[Raphael Isemann via lldb-dev]

Hi Gábor,

I replied inline.

Am Sa., 1. Dez. 2018 um 17:00 Uhr schrieb Gábor Márton via cfe-dev
:
>
> Dear LLDB Developers,
>
> There is an ongoing activity to improve ASTImporter in Clang to make it 
> support
> C++ (and C) completely and correctly.  Our team works on cross translation 
> unit
> (CTU) static analysis where we use the in-tree Clang static analyzer in
> combination with the ASTImporter (via the scan-build.py script or 
> CodeChecker).
> In the past 18 months we have committed more than 70 patches to make the
> ASTImporter better.  Our primary target is Linux and we do run the LLDB tests
> on Linux before we commit.  Unfortunately, quite recently 3 of these patches
> broke the LLDB macOS buildbots (green.lab.llvm.org/green/view/LLDB) and this
> caused some turmoil.  We are very sorry about this and we are making actions 
> to
> avoid such inconveniences in the future: We ordered a Mac Mini, until it
> arrives we are using a borrowed Mac Book. We are going to create a CI job 
> which
> will execute the macOS LLDB test suite for a specific patch. Besides this, for
> every patch we are going to monitor the macOS buildbots once they are
> committed.

Thanks a lot! And no worries about breaking the bots.

> However, we are experiencing problems both with the buildbots and with the 
> LLDB
> tests, therefore we are asking help from the LLDB community in the following:
>
> (1) Apparently, the green lab macOS buildbots are not displayed in the build
> bot console (http://lab.llvm.org:8011/console). More importantly they are not
> capable of sending emails to the authors of the commit in case of failure.
> Would it be possible to setup the these buildbots to send out the emails for
> the authors?
>
> (2) We are facing difficulties with the LLDB lit tests both on macOS and on
> Linux. E.g. on a fresh macOS mojave install, checking out master LLVM, Clang,
> LLDB and then executing ninja check-lldb fails immediately.  On Linux we
> experienced that some tests fail because they try to read a non-existent
> register. Some tests fail non-deterministically because they can't kill a
> process or a timeout is not long enough. Some tests fail because of a linker
> error of libcxx. We would like to address all these issues. Would you like to
> discuss these issues on lldb-dev or should we create a bugzilla ticket for
> each?

I would just post about them on lldb-dev and then I think we can sort
out what are issues with the local setup and what are actual LLDB bugs
that should go to the bugtracker. The LLDB setup needs some small
extra attention that I don't think is really documented anywhere, so
that's a good chance for us to do so.

> (3) ASTImporter unit tests and lit tests in Clang for the LLDB specific usage
> are very-very limited.  LLDB uses the so called "minimal" import, but none of
> the unit tests exercises that (CTU uses the full import).  We should have a
> unit test suite where the LLDB use cases are covered, e.g. after a minimal
> import an `importDefinition` is called. Also, a test double which implements
> the ExternalASTSource could be used.  I believe it would be possible to cover
> with the unit tests all LLDB/macOS related scenarios and these tests could run
> on Linux too.  We do something similar in case of windows: we execute all unit
> tests with "-fdelayed-template-parsing" and with "-fms-compatibility" too. I
> think, the more unit tests we have in Clang the sooner we catch the LLDB
> specific importer errors.  I am asking the LLDB community's help here, because
> we lack the domain knowledge in LLDB so we don't know what expectations should
> we write in each unit test cases.  (About lit tests, there is 
> clang-import-test
> but its coverage seems pretty low and I don't know if that really exercises 
> all
> LLDB use cases.)

Yes, having full coverage of the ASTImporter in Clang would be very
nice. I started writing tests a few months back (with the help of
Aleksei who reviewed all of them!), but I currently don't have enough
time for doing the rest.

The clang-import-test tests are I think a good starting point. IIRC,
they actually do test the minimal import feature (as the first stage
of lazy building the AST). Their coverage should be ok-ish by now, but
it's obviously far from what we should have.

> I think that from a better ASTImporter the LLDB debugger can benefit too: the
> `expr` command might give better experience by supporting more C++ constructs
> and by giving better diagnostics.

Yes, I fully agree.

> Thank you,
> Gabor
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Am Sa., 1. Dez. 2018 um 17:00 Uhr schrieb Gábor Márton via cfe-dev
:
>
> Dear LLDB Developers,
>
> There is an ongoing activity to improve ASTImporter in Clang to make it 
> support
> C++ (and C) completely and correctly.  Our team works on cross translation 
> unit
> (CTU) static analysis where 

Re: [lldb-dev] TestExprCompletion failing

[Raphael Isemann via lldb-dev]

As is tradition, some "NFC" commit broke broke that :). Reverted it in
r341532. Thanks for the hint!

- Raphael

Am Do., 6. Sep. 2018 um 02:35 Uhr schrieb Davide Italiano
:
>
> Raphael, this test has been failing for a while.
>
> http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake/9755/console
>
> Testing Time: 466.83s
> 
> Failing Tests (1):
> lldb-Suite :: expression_command/completion/TestExprCompletion.py
>
> Can you please take a look?
>
> Thanks!
>
> --
> Davide
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLDB Phabricator project and review group

[Raphael Isemann via lldb-dev]

Hi all,

we now have a LLDB project on Phabricator[1][2].

You can tag your patches now as belonging to the LLDB project. This
will automatically add the respective commit mailing list (thanks
Ben!), so the number of steps for creating a LLDB review stay the
same. It will also automatically put your review in the news feed of
the project.

You can also add the project as a reviewer if you don't know what
specific person could review your patch (e.g. because it's changing
unmaintained code or the change is very general). Everyone in the LLDB
group will then get this review added to his/her review queue.

And finally, feel free to join this project on Phabricator if you want
to get these patches in your review queue.

Cheers,

- Raphael

[1] https://reviews.llvm.org/project/view/39/
[2] Technically, we just hijacked the old project, but that doesn't
sound as exciting.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB nightly benchmarks and flamegraphs

[Raphael Isemann via lldb-dev]

Am Fr., 3. Aug. 2018 um 16:42 Uhr schrieb Leonard Mosescu :
>
> +1, really nice. Any plans to add wall clock time? (I see you're using perf, 
> right?)

It's on my own VPS where I also run other things, so instruction count
is used for the long-term graph to prevent that other processes make
the graph jittery. But the daily flame graph is based on wall time.

>
> On Fri, Aug 3, 2018 at 3:59 PM, Zachary Turner via lldb-dev 
>  wrote:
>>
>> This is really cool.  Maybe you could do it for all of LLVM too?  It would 
>> be nice if, instead of cycling through each benchmark on a set interval, 
>> there were just a dropdown box where you could select the one you wanted to 
>> see.

Covering LLVM and Clang is what I want to do next, but first I want to
rewrite it in something else than the current nightmarish mix of
python/bash/GNUplot. That probably also will feature a nicer web
interface.

>>
>> On Fri, Aug 3, 2018 at 3:37 PM Raphael Isemann via lldb-dev 
>>  wrote:
>>>
>>> Hi everyone,
>>>
>>> I wanted to share a (hopefully useful) service for LLDB that I added 
>>> recently:
>>>
>>> If you go to https://teemperor.de/lldb-bench/ you'll now see graphs
>>> that show the instruction count and memory usage of the last LLDB
>>> nightlies (one per day). If you click on a graph you'll see a flame
>>> graph that shows how much time we spent in each function when running
>>> the benchmark. The graph should make it pretty obvious where the good
>>> places for optimizations are.
>>>
>>> You can see all graphs without the slide show under
>>> https://teemperor.de/lldb-bench/static.html.
>>>
>>> The source code of every benchmark can be found here:
>>> https://github.com/Teemperor/lldb-bench If you want to add a
>>> benchmark, just make a PR to that repository and I'll merge it. See
>>> the README of the repo for instructions.
>>>
>>> I'll add more benchmarks in the future, but you are welcome to add your own.
>>>
>>> Also, if you for some reason don't appreciate my amazing GNUplot
>>> markup skills and prefer your own graphs, you can just grab the raw
>>> benchmark data from here: https://teemperor.de/lldb-bench/data/ The
>>> data format is just the time, git-commit and the
>>> instruction-count/memoryInKB value (depending if it's a `.mem.dat` or
>>> a `.inst.dat`).
>>>
>>> On a side note: Today's spike in memory is related to changes in the
>>> build setup, not a LLDB change. I don't expect too many of these
>>> spikes to happen in the future because the benchmark framework is now
>>> hopefully stable enough.
>>>
>>> Cheers,
>>>
>>> - Raphael
>>> ___
>>> 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] LLDB nightly benchmarks and flamegraphs

[Raphael Isemann via lldb-dev]

Hi everyone,

I wanted to share a (hopefully useful) service for LLDB that I added recently:

If you go to https://teemperor.de/lldb-bench/ you'll now see graphs
that show the instruction count and memory usage of the last LLDB
nightlies (one per day). If you click on a graph you'll see a flame
graph that shows how much time we spent in each function when running
the benchmark. The graph should make it pretty obvious where the good
places for optimizations are.

You can see all graphs without the slide show under
https://teemperor.de/lldb-bench/static.html.

The source code of every benchmark can be found here:
https://github.com/Teemperor/lldb-bench If you want to add a
benchmark, just make a PR to that repository and I'll merge it. See
the README of the repo for instructions.

I'll add more benchmarks in the future, but you are welcome to add your own.

Also, if you for some reason don't appreciate my amazing GNUplot
markup skills and prefer your own graphs, you can just grab the raw
benchmark data from here: https://teemperor.de/lldb-bench/data/ The
data format is just the time, git-commit and the
instruction-count/memoryInKB value (depending if it's a `.mem.dat` or
a `.inst.dat`).

On a side note: Today's spike in memory is related to changes in the
build setup, not a LLDB change. I don't expect too many of these
spikes to happen in the future because the benchmark framework is now
hopefully stable enough.

Cheers,

- Raphael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Phabricator repository

[Raphael Isemann via lldb-dev]

Thanks a lot for adding this!

- Raphael
Am Do., 2. Aug. 2018 um 02:12 Uhr schrieb Eric Liu :
>
> Sorry for the late response. I have created a repository for LLDB on 
> phabricator: https://reviews.llvm.org/source/lldb/. Let me know if there is 
> anything else I could help with.
>
> On Wed, Aug 1, 2018 at 7:07 PM Raphael Isemann  wrote:
>>
>> Ah, my bad, that makes more sense. I dropped them an email with the request.
>>
>> - Raphael
>> Am Mi., 1. Aug. 2018 um 09:58 Uhr schrieb :
>> >
>> >
>> >
>> > > -Original Message-
>> > > From: Raphael Isemann [mailto:teempe...@gmail.com]
>> > > Sent: Wednesday, August 01, 2018 12:21 PM
>> > > To: Robinson, Paul
>> > > Cc: Pavel Labath; ioe...@google.com; LLDB Dev
>> > > Subject: Re: [lldb-dev] Phabricator repository
>> > >
>> > > The list is not public, so someone with access needs to mail them
>> > > (which is not true for me :) ).
>> >
>> > This is the prescribed method for admin-style requests.  If you're
>> > not subscribed to llvm-admin, the message goes to the moderation
>> > queue, and it will still be seen.  Anyone is supposed to be able
>> > to make a request.
>> > --paulr
>> >
>> > >
>> > > - Raphael
>> > > Am Mi., 1. Aug. 2018 um 09:11 Uhr schrieb :
>> > > >
>> > > > Email to llvm-admin should do it.
>> > > > --paulr
>> > > >
>> > > > > -Original Message-
>> > > > > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of
>> > > Pavel
>> > > > > Labath via lldb-dev
>> > > > > Sent: Wednesday, August 01, 2018 3:52 AM
>> > > > > To: Raphael Isemann; Eric Liu
>> > > > > Cc: LLDB
>> > > > > Subject: Re: [lldb-dev] Phabricator repository
>> > > > >
>> > > > > Sounds like a good idea, though I'm not sure what specifically needs
>> > > > > to be done to make that happen. Eric might know more...
>> > > > > On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev
>> > > > >  wrote:
>> > > > > >
>> > > > > > Could we get LLDB into this repository list here?
>> > > > > > https://reviews.llvm.org/diffusion/
>> > > > > >
>> > > > > > Beside that it's a bit confusing to the user that lldb is the only
>> > > > > > missing project there, it also breaks phabricator/arcanist which
>> > > seems
>> > > > > > to list LLDB commits as LLVM-repo commits (at least my commits get
>> > > > > > automatically an LLVM prefix and sometimes get assigned to the LLVM
>> > > > > > repo).
>> > > > > >
>> > > > > > - Raphael
>> > > > > > ___
>> > > > > > 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] Phabricator repository

[Raphael Isemann via lldb-dev]

The list is not public, so someone with access needs to mail them
(which is not true for me :) ).

- Raphael
Am Mi., 1. Aug. 2018 um 09:11 Uhr schrieb :
>
> Email to llvm-admin should do it.
> --paulr
>
> > -Original Message-
> > From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel
> > Labath via lldb-dev
> > Sent: Wednesday, August 01, 2018 3:52 AM
> > To: Raphael Isemann; Eric Liu
> > Cc: LLDB
> > Subject: Re: [lldb-dev] Phabricator repository
> >
> > Sounds like a good idea, though I'm not sure what specifically needs
> > to be done to make that happen. Eric might know more...
> > On Wed, 1 Aug 2018 at 03:17, Raphael Isemann via lldb-dev
> >  wrote:
> > >
> > > Could we get LLDB into this repository list here?
> > > https://reviews.llvm.org/diffusion/
> > >
> > > Beside that it's a bit confusing to the user that lldb is the only
> > > missing project there, it also breaks phabricator/arcanist which seems
> > > to list LLDB commits as LLVM-repo commits (at least my commits get
> > > automatically an LLVM prefix and sometimes get assigned to the LLVM
> > > repo).
> > >
> > > - Raphael
> > > ___
> > > 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] Phabricator repository

[Raphael Isemann via lldb-dev]

Could we get LLDB into this repository list here?
https://reviews.llvm.org/diffusion/

Beside that it's a bit confusing to the user that lldb is the only
missing project there, it also breaks phabricator/arcanist which seems
to list LLDB commits as LLVM-repo commits (at least my commits get
automatically an LLVM prefix and sometimes get assigned to the LLVM
repo).

- Raphael
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Moderator needed for lldb-commits

[Raphael Isemann via lldb-dev]

Hi Tanya,

I'm also in!

- Raphael
Am Mo., 9. Juli 2018 um 13:50 Uhr schrieb Jonas Devlieghere via
lldb-dev :
>
> Hi Tanya,
>
> I'd be happy to take care of this!
>
> Cheers,
> Jonas
>
> > On Jul 6, 2018, at 6:01 PM, Tanya Lattner via lldb-dev 
> >  wrote:
> >
> > LLDB Developers,
> >
> > Moderators are needed for the lldb-commits mailing list. Is anyone 
> > interested in helping out?
> >
> > Thanks,
> > Tanya
> > ___
> > 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