Hi D community!

Sorry for being late. I’m here again, to describe what I’ve done during the seventeenth week of Symmetry Autumn of Code.

LLVM upstream updates

This week I finished working on the three patches I was working about demangling and finally merged them in the LLVM upstream:

I also added another trivial patch to pass values by reference instead of a pointer, requested by dblaikie:

Bug on LLVM + Clang 13

Before merging, I always run the sanitizer on the whole test suite and the fuzzer I integrated, although I found a regression on recent LLVM + Clang builds with the sanitizer arguments. You can read more about the issue in this patch. Briefly, the problem was that LLVM is compiled with -fPIC -fno-semantic-interposition on LLVM + Clang 13.0.0, although, when combined with -fsanitize flags, the generated binary has incorrect PC-relative relocation information on the generated calls making it fails on linking. Thanks to MaskRay by helping me diving into this and fixing the problem!

I got surprised by the fact that this was not caught by the buildbots. When comparing the LLVM released binaries and Arch Linux binaries the problem was not reproducible. Probably the patched version Arch Linux distributes had something to do with it but I didn’t get a clear answer. This makes some sense since Arch Linux compiles with SSP (strong stack protection) by default and that adds extra calls that, when compiled with -fPIC seem to be also PC-relative.

That regression made me creating two more trivial patches:

Extending dumping for derived types

I started tinkering with derived types, more specifically with alias. The same with built-in types the logic can be extended to other derived types as well. In DWARF DW_TAG_typedef_type is generated whenever a variable is typed with an alias. I did some basic logic to make it work, although I need to do some decoupling from Clang due to type forwarding.

I still need to understand how types are forwarded in DWARF, because the types are read sequentially and a DW_TAG_typedef_type can reference an address “in the future” that points to a DW_TAG_base_type which need to be resolved later. I tried to search how Go plugin did that (see diff) but dwarf->ResolveTypeUID got removed.

You can consult the source code here.

More decoupling on the Clang DWARF Parser

I was about to decouple GetContainingClangModuleDIE and GetContainingClangModule functions, although, my test suite is not running correctly. LLDB test suite is a nightmare to me and I’m trying to push forward on more clarity about which tests are marked as Unsupported or Expected to Fail. I always had this problem since I started working on the LLDB tree although I took the risk of ignoring them. I couldn’t contact lldb-dev since there is some restrictions on the mailing list due to spam and I got not answer on my subscription request. Finally LLVM moved to discourse, so I created two posts there to describe my problems:

The first one already got some attention and JDevlieghere already submitted a patch. I had no idea that the buildbot infrastructure was open source. I already have some patches to submit about this topic, including activating Lua tests, which is failing locally and not tested on the buildbots.

What is next?

Well, I plan to continue working on the custom DWARF Parser for D, including adding support for other basic stuff like functions. Even though this is the last weekly update, I’m going to try to keep up with some changes on the LLVM tree. My goal is to have some minimum support (roughly the same of GDB) on LLDB 14. I will try to submit the bare minimum support which need to include some workarounds on the Clang DWARF Parser. This may not be accepted due to that, but if it does, we can have custom formatters officially on LLDB. I will try to provide soon some builds for the community of this branch, although.

You can also read this on the D programming language forum, here, and discuss there!

Read about the previous week.