MESSAGE
| DATE | 2015-03-20 |
| FROM | Ruben Safir
|
| SUBJECT | Subject: [NYLXS - HANGOUT] Mozilla Linux needs help **no shit**
|
http://www-archive.mozilla.org/unix/linux-help.html
Contact: Chris Waterson (waterson-at-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 = = {
_vptr. = 0x41277140
},
}
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.
|
|
