Anyone is working on LLDB?

Development
1

I’m struggling on debugging too bloated libxul.so of Firefox (it is virtually the body of the Firefox) these days.

I tried using system libraries rather than in-tree ones as many as possible, but it shrunk just tens of MBs instead of hundreds of MBs.

I thought using LLDB may help this situation, but there is no LLDB or even GDB in HaikuDepot.

I’ve reached this info (again PulkoMandy here!), I know LLDB needs some patches to talk with Haiku binaries.

I want to spend some time to try porting those changes to LLDB rather than spending hours to step over on assembly with no variable info, but are there anyone tried (or done!) already?

3 Likes
2

There is a patch for a not too old GDB in HaikuPorts which gets close to working, but doesn’t quite. There is discussion on this ticket.

There is a very old GDB (6.8) which actually does work, or used to. You can try building that, probably.

2 Likes
3

Not sure how hard it is to get Debugger to support newer DWARF formats. I think I heard they reduced memory a lot in the newer ones?

2 Likes
4

Used to. It can probably still debug apps, but it is not able to read debug info generated by modern GDB, so it is quite useless.

Probably not so hard, it is just a file format. But it needs some time looking at the spec and testing things. And I don’t know if you can run Debugger inside Debugger to investigate problems…

3 Likes
5

Thank you input, folks!

@waddlesplash Thanks info. I found those patches in the linked forum topic, but the ticket may have more details. I’ll read that.

I have almost no knowledge about how to implement (and how should it work) debuggers. And I suspect there is difficulty @PulkoMandy says:

So, making LLDB to work with Haiku may be easier to me and more reasonable option for debugging Firefox because:

  1. LLDB itself should be built with GCC(4+) toolchain as the current LLVM/Clang port does, this means debugging LLDB with Debugger should work (at least with -gdwarf-3).
  2. Firefox contains binary part built with Rust, which I believe it is built with LLVM backend even if I instruct to build Firefox with GCC. If the Rust part of the binary was the root cause of the current situation, it seems to require more work on Debugger to handle that.

Making LLDB buildable by referring current patchset for LLVM/Clang in Haikuports should be relatively easy task, after that start debugging and fixing how LLDB loads trivial Haiku program (e.g. HelloWorld) with Debugger.

6

You will need to implement a full debugging backend in LLDB for Haiku. The patchset for GDB at HaikuPorts implements such a backend for GDB, so you can get an idea of how much code is involved.

1 Like
7

Thank you. I skimmed the patch for GDB, but didn’t read deeply, because just porting GPL code will require resulting LLDB changes to be licensed under GPL.

I’ll see how the built LLDB fails to load Haiku binary, then I refer how the GDB haiku backend resolved it as minimum. If the part of Haiku backend in resulting patch became the almost same code, then I’ll ask original contributors (of GDB haiku porting) to re-license that part under LLDB compatible license.

8

Before just starting task, I’m reading current Debugger’s source code.

It has clear structure and looks clean implementation.

I should read its source code than GCC patch to know how Haiku’s debuggers should work if I care about licensing issue.

9

For this, I found Debugger has --cli option when exploring its source code, Debugger CLI looks debuggable with Debugger GUI (I tested with release build so no symbols available but can be attached and step in/over/out worked).

The Debugger GUI quits shortly after launched as debug target.

10

I’ve actually debugged debuggers that were debugging debuggers! The trick is to compile the Debugger that you are working on with a different signature.

The --cli Debugger is not as complete as the GUI Debugger. For example, you can’t set breakpoints.

2 Likes
11

Thanks @Zardshard for helpful information.

You encouraged me to tackle debbugging and fixing the Debugger. I looked around LLDB, maybe adding Haiku support to it is workable. But it will take weeks than days.

I will end up debugging LLDB with almost no debugger knowledge. If so, debugging the Debugger should be easier.

1 Like
12

I have a file for use with Umbrello, a UML editor. It details the parts of the Debugger’s class structure that I encountered. Now, if only I could figure out how to upload it…

That’s what my first impression was too. The author of the code clearly spent a lot of time designing it. After working with it more, I think it could be better. The Debugger kit, for example, seems to be tailor-made for the Debugger application, and only the Debugger application. I’m not sure that it would be very useful for, say, porting GDB. Some classes seem to have multiple responsibilities, making it harder to wrap your head around what they do. Maybe if I were to continue reading, my opinion would change once again. I’d be interested in hearing what your impression of the code is after reading/coding it for a while.

1 Like
13

You can add it to docs/develop/ in the Haiku sourcetree and add it in one of the rst files there. Then it will be available at Welcome to Haiku internals’s documentation! — Haiku internals documentation

14

Ok, I uploaded it. See https://review.haiku-os.org/c/haiku/+/6483. Feel free to make changes and add your notes.

1 Like
15

The Debugger kit used to be part of Debugger itself and was only split off a few years ago, indeed.

2 Likes
16

The UML diagram has been merged. You can view it in your browser here. Note that there is a class diagram at the bottom of the page.

1 Like