www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - SAOC LLDB D integration: 1st Weekly Update

reply =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
Hi D community!

I'm here to describe what I've done during the first week on the
Autumn of Code.

During the discussion for the milestones plan with my mentor, I decided
advance some work and wrote a simple C API around D runtime demangler
to expose
the D demangler API into a C interface. This would allow in the future
implement an LLDB language plugin into the LLVM. The source code is
on Github,

In the meanwhile, we decided to focus on porting libiberty demangler
to the LLVM upstream repository since it would provide much more
benefits and
acceptance to be upstreamed. So the `liblldbd` is a plan B if libiberty
is not
accepted by the LLVM team.

Right after we finished the plan, in which you can follow up
[here](https://pad.riseup.net/p/r.05c919765a66f89368a3fc28c98432db), I
porting `libiberty` and integrate the code into the LLVM core.
Similarly to
Rust demangler, I tried to follow up some patches on the [LLVM review
platform](https://reviews.llvm.org/) and the awesome documentation that

This ended up being relatively easy to plug into the LLVM codebase,
since most
of the demangler logic was isolated in one file, thanks to Iain
( ibuclaw) for
the excelent code. Because I didn't expect this to be so plug and play
decided to extensively test the code using the robust test suite that

First, I started to port the `libiberty` test suite for D demangling
and right
after wrote some `libfuzzer` tests and ran it with an address sanitizer
and UB

The `libfuzzer` results took some time to show up but I got some
outputs from there. The most interesting one was a heap/stack buffer
I also managed to find a null dereferencing.  Both, with a crafted
mangle name, can trigger a segmentation fault or undefined behaviour by
reading/writing to a protected memory space.

I wrote a patch to fix both issues and contacted MITRE for standard
vulnerabilities reporting procedure, since GCC is widely used and can
potentially cause some issues. I pushed those patches into the GCC
list, and I'm currently waiting for appreciation. You can check those

After patching the code I ran the fuzzer again and after some hours the
reported a timeout with a huge number of recursive calls. I carefully
the generated output mangle that the fuzzer created and found out that
it is a
very repetitive name. Doing some superficial analysis I found out that
recursive calls are creating exponential time complexity and can cause
demangler to wait for hours or even days to complete. I believe that
this can
also be used to maliciously cause a denial of service, although I
didn't have
much time to profile it yet.

To have some discussion about this I'm going to create a thread on the
security mailing list and express some solutions to mitigate those
such as integrating part of the codebase into the OSS fuzzer.

Before that, I'm waiting for a reply to the message I sent to MITRE,
which was
forwarded to Red Hat security team for further appreciation.

I don't really know if this is crucial to share now, but I saved the
result, if anyone is interested in researching more ideas of crafted
mangles to
feed the address/UB sanitizer.

The last task I was working on (today) was on finalizing the LLDB
I still need to write some tests but the most important fact is that it
already working! My LLDB tree can successfully pretty print the mangled
My fork is available on my Github,

=46rom the first time I built LLVM I found out that compiling it with
information is extremely costly in terms of memory usage, since linking
those symbols at once can consume a lot of RAM. I recommend you build
it with
`Release` flags.

Here is my `cmake` config so far, if someone wants to test my work at
cmake -S llvm -B build -G Ninja \
       -DLLVM_ENABLE_PROJECTS=3D"clang;libcxx;libcxxabi;lldb" \
       -DCMAKE_BUILD_TYPE=3DRelease \

To build LLDB, you can do something like:

cmake --build build -- lldb -j$(nproc --all)

Next week, I'm going to have an eye on the time complexity problem, try
solve it, restructure the code to look a bit more C++ish and finishing
the LLDB
test suite to finally start upstreaming my changes.  Although, this can
take a
while, since there is a challenge, described in the plan, which is
dual-licensing the GCC codebase with LLVM codebase. This is
cooperatively being
handled by Mathias (my mentor), Iain and GCC team.

Lu=C3=ADs Ferreira   lsferreira.net
Sep 22
parent reply user1234 <user1234 12.de> writes:
On Wednesday, 22 September 2021 at 20:11:56 UTC, Luís Ferreira 
 Hi D community!

 I'm here to describe what I've done during the first week on the
 Autumn of Code.

Nice project, I'll follow. so in theory LLMDB has the same "machine interface" as GDB ?
Sep 23
parent =?ISO-8859-1?Q?Lu=EDs?= Ferreira <contact lsferreira.net> writes:
What do you mean by "machine interface"? Can you elaborate a bit more,

On Thu, 2021-09-23 at 18:32 +0000, user1234 via Digitalmars-d wrote:
 On Wednesday, 22 September 2021 at 20:11:56 UTC, Lu=C3=ADs Ferreira=20
 Hi D community!
 I'm here to describe what I've done during the first week on the
 Autumn of Code.
=20 Nice project, I'll follow. so in theory LLMDB has the same "machine interface" as GDB ?
--=20 Sincerely, Lu=C3=ADs Ferreira lsferreira.net
Sep 23