• Roadmap
• Projects
• Coding
  • Module Owners
  • Hacking
  • Get the Source
  • Build It
• Testing
  • Releases
  • Nightly Builds
  • Report A Problem
• Tools
  • Bugzilla
  • Tinderbox
  • Bonsai
  • LXR
• FAQs

mozilla needs linux help

Contact: Chris Waterson (waterson@netscape.com)

This is a quick and dirty list of stuff that mozilla.org wishes were better for developers on Linux, and where our community is lacking for resources.

Tools. Tools! Tools! Tools! We need better (stronger, more) tools!

• Debugging. gdb (and ddd) suck! Here's what we want:

  • Make it understand XPCOM. More specifically, it could understand pure virtual interfaces better. For example: if v is a pointer to an nsISupports,

    (gdb) print *v 
    $2 = <nsISupports> = { 
         _vptr. = 0x41277140 <nsMsgAccountManager virtual table> 
      }, 
    }
    

    So gdb obviously knows what kind of object this is, and casting will display the object just fine. Can't gdb just do this automagically?

  • Make it handle shared libraries intelligently. Currently gdb only understands two modes of operation: 1) load/map every symbol in each library as it's loaded, and 2) load no libraries. When in "every symbol mode", gdb takes up so much memory that Mozilla is impossible to debug. When in "no library" mode, you can't set breakpoints or look at symbols on the stack until you manually load the library!

    It would be nice if there was some middle ground where gdb caches some information about the library at the time that it's loaded (such as the names of the files, or even just a list of symbols and the files they map to). Then, when a symbol or type actually needs to be inspected, gdb could load the library's symbol information.

• Profiling. Jim Nance has done a wonderful job cooking up a home-brewed sampling profiler for Mozilla called jprof. It'd be great to get more people working on this. There are rumors that SGI is open-sourcing "SpeedShop". Maybe Intel could port VTune to Linux. Maybe Rational could port Quantify to Linux. Or maybe we could just figure out how to get gprof to work with all of our shared libraries.

• Leak Detection. Also known as "Purifying", which includes leak detection, bounds checking, allocation matching. It'd be great if we could get Purify-like tools that are Open Source. Or, at least, get Purify to do a Linux port. Alternatively, it'd be great to integrate the Boehm collector so we can do leak analysis.

• Memory visualization. Who's using what? We've got an awful runtime footprint right now: knowing where the memory is going would help a lot!

• Compiling. The Visual C++ optimizer generates killer code. Rumor has it that Intel has a killer reference compiler for x86. Can we get it?

Graphics Optimization. Much of the core layout and rendering code was written by Windows hackers. There may be erroneous assumptions about what operations the underlying toolkit can perform quickly.

• General X11 Expertise. It'd be great if we could get some X wizards to help do Xserver usage analysis. Figure out where GFX, widget, and layout have made platform-specific assumptions about the toolkit. For example:

  • Optimize text measurement.

  • Use shared memory for bitmaps.

  • Examine and optimize clipping.

• Implement full-blown PNG support, including alpha channel, MMX optimization, and animated PNGs.

Miscellany. Other stuff I can't figure out how to break out yet.

• Per-user registry support. It'd be great if we could "merge" a user's registry with the root-installed registry. This would, among other things, allow "local" (e.g., user-installed) components/plugins. (See Bug 16599).

• Backward-adapter for Linux 4.x plugins Maybe this is almost done. See Bug 31012.

• Investigate alternative memory allocators.

• Performance Laundry List.

---