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

[David Blaikie via lldb-dev]

+lldb-dev

On Mon, Oct 25, 2021 at 9:36 AM Luís Ferreira via llvm-dev <
llvm-...@lists.llvm.org> 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

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

[David Blaikie via lldb-dev]

+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 libc++.so.1 is in a different place:
> ./lib/x86_64-unknown-linux-gnu/libc++.so.1
>
> Looks like this rpath setting happens here: (changing this to a junk
> argument causes the test to fail to build as expected)
>
> https://github.com/llvm/llvm-project/blob/618583565687f5a494066fc902a977f6057fc93e/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L400
>
> And it gets the LLVM_LIBS_DIR from here:
> https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/lldb/test/API/lit.cfg.py#L163
>
> So maybe we need to pass down the default target triple too, since that
> seems to be how libc++ is deciding where to put the library? (
> https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/libcxx/CMakeLists.txt#L424
> ) at least on non-apple :/ (or maybe there's some way to make the
> connection between the two less brittle - for libc++'s build to export some
> variable that lldb can use, or for LLVM to provide something for both to
> use?)
>
> Yeah, applying this change does work for me, but wouldn't work on Apple
> for instance (where libcxx doesn't add the default target triple to the
> path):
>
> $ git diff
>
> *diff --git lldb/test/API/lit.site.cfg.py.in 
> lldb/test/API/lit.site.cfg.py.in *
>
> *index 987078a53edb..e327429b7ff9 100644*
>
> *--- lldb/test/API/lit.site.cfg.py.in *
>
> *+++ lldb/test/API/lit.site.cfg.py.in *
>
> @@ -3,7 +3,7 @@
>
>  config.llvm_src_root = "@LLVM_SOURCE_DIR@"
>
>  config.llvm_obj_root = "@LLVM_BINARY_DIR@"
>
>  config.llvm_tools_dir = "@LLVM_TOOLS_DIR@"
>
> -config.llvm_libs_dir = "@LLVM_LIBS_DIR@"
>
> +config.llvm_libs_dir = "@LLVM_LIBS_DIR@/@LLVM_DEFAULT_TARGET_TRIPLE@"
>
>  config.llvm_shlib_dir = "@SHLIBDIR@"
>
>  config.llvm_build_mode = "@LLVM_BUILD_MODE@"
>
>  config.lit_tools_dir = "@LLVM_LIT_TOOLS_DIR@"
>
> Thoughts?
>
___
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

[Louis Dionne via lldb-dev]

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

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.

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 
> libc++.so.1 is in a different place: 
> ./lib/x86_64-unknown-linux-gnu/libc++.so.1
> 
> Looks like this rpath setting happens here: (changing this to a junk argument 
> causes the test to fail to build as expected)
> https://github.com/llvm/llvm-project/blob/618583565687f5a494066fc902a977f6057fc93e/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L400
>  
> 
> 
> And it gets the LLVM_LIBS_DIR from here: 
> https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/lldb/test/API/lit.cfg.py#L163
>  
> 
> 
> So maybe we need to pass down the default target triple too, since that seems 
> to be how libc++ is deciding where to put the library? ( 
> https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/libcxx/CMakeLists.txt#L424
>  
> 
>  ) at least on non-apple :/ (or maybe there's some way to make the connection 
> between the two less brittle - for libc++'s build to export some variable 
> that lldb can use, or for LLVM to provide something for both to use?)
> 
> Yeah, applying this change does work for me, but wouldn't work on Apple for 
> instance (where libcxx doesn't add the default target triple to the path):
> $ git diff
> diff --git lldb/test/API/lit.site.cfg.py.in  
> lldb/test/API/lit.site.cfg.py.in 
> index 987078a53edb..e327429b7ff9 100644
> --- lldb/test/API/lit.site.cfg.py.in 
> +++ lldb/test/API/lit.site.cfg.py.in 
> @@ -3,7 +3,7 @@
>  co

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

[David Blaikie via lldb-dev]

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 libc++.so.1 is in a different place:
>> ./lib/x86_64-unknown-linux-gnu/libc++.so.1
>>
>> Looks like this rpath setting happens here: (changing this to a junk
>> argument causes the test to fail to build as expected)
>>
>> https://github.com/llvm/llvm-project/blob/618583565687f5a494066fc902a977f6057fc93e/lldb/packages/Python/lldbsuite/test/make/Makefile.rules#L400
>>
>> And it gets the LLVM_LIBS_DIR from here:
>> https://github.com/llvm/llvm-project/blob/207998c242c8c8a270ff22a5136da87338546725/lldb/test/API/lit.cfg.py#L163
>>
>> So maybe we need to pass down the default target triple too, since that
>> seems to be how