Progress on porting Firefox

[KENZ]

Short answer is, use GDB15 to debug firefox.

@DigitalBox

Why the Haiku Debugger tool is not displaying the source of the firexfox program even if it’s compiled with debug info ?

It is why I played with Haiku Native debugger. I was there last year:

Progress on porting Firefox

As first screenshot I shared, Debugger failed to find C++ symbols, this made debugging nightmare. This seems the same problem with the following topic, I searched around workaround about this but I have no luck. Finally, I tried building Firefox source with GCC (instead of default Clang). But it failed because libxul.so is too large (0x4864c809 bytes = 1,214,564,361 bytes = 1.2GiB). 75:48.07 toolkit/library/build/libxul.so 81:10.04 /boot/system/develop/tools/bin/../lib/gcc/x86_64-unknown-h…

There are two problem with Native Debugger:

1. Latest debugging info(DWARF) support was missing
   • it lacks DWARF v4/v5 support then
   • with DWARF v3, it was incompatible with firefox build output, so I hacked some:
     • Progress on porting Firefox - #63 by KENZ
     • https://cgit.haiku-os.org/haiku/commit/?id=f0e9ed4488b00cee222f17b190b0d415019ad17c
       • BTW, This was the my first commit to haiku repo
   • some people worked/is working to improve this
2. Too large debugging info of libxul.so(Firefox’s core/body library)
   • Native Debugger doesn’t have scalability for this of magnitude.
   • it took minutes to load debugging info, exausts 16GB ram then I had. And every stepping execution a few minutes, simply not usable.
     • Progress on porting Firefox - #69 by KENZ

So I tackled try porting LLDB but it didn’t succeed then by lacking both of my skill and my spare time

Anyone is working on LLDB?

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…

In this year’s GSoC, a student @trungnt2910 worked on improving this situation

[GSOC 2024] Proposal: Improving the userland debugging experience

Hi, it’s me @trungnt2910 again. Currently, the native Debugger app is having a monopoly for userland debugging on Haiku. However, as I have experienced while porting .NET, and probably other developers trying to port complex software to Haiku have as well, the inbox Debugger has many limitations, including: Annoying dialogs prompting to load symbols. Recently they have been updated to allow skipping all for the current session, yet these dialogs have not provided any option to silence for the…

and he did! He ported latest GDB again and made it very stable enough to debug the firefox.

His blog series on this is great to read.

[GSoC 2024] Improving the Userland Debugging Experience - Final Report

It can be used to debug C++/Rust mixed project. I’m using Qt Creator for GDB graphical frontend.

[GSoC 2024] Improving the Userland Debugging Experience - Progress Report #3 | Haiku Project

Thank you for all your hard work! Now I can use your latest GCC port to debug firefox. Currently Qt Creator is the best graphical GUI frontend which works for me as far as I tested. GCC consumes 2GB+ RAM to debug firefox, but it is greatly improved from the native Debugger days. It works for step-execution on C++/Rust mixed project, too. [screenshot16]

EDIT: I wrote GDB as GCC, I was sleeping in bed then.