Re: setting start-process environment, too much GC, debugging XEmacs

On Tue, 24 Oct 2006, stephen(a)xemacs.org mused: Not that I know of. I mean, there's no need to remind me of my *last* disastrous attempt to fix anything in that area (xemacs-21.4.7, anyone?). Of course there might be things I've forgotten about process handling because they aren't documented: but I'm afraid I've forgotten about them:/ That. Oh, good. I'll upgrade this evening then. (The idea of an XEmacs trunk existing for more than a week *without* Ben Wing submitting megapatches is oddly disturbing.) It also maintains some unimaginably vast variables and loops over *them* a lot, including checking their lengths frequently. (The group in question has well over *30Mb* of overview data, so it tends to point up slownesses in Gnus quite effectively. One of the reasons I've upgraded to 21.5.x is for the way-better profiler I vaguely recall noticing flying past on the list years ago, so I can try to stamp on some low-hanging sloth fruit.) On the list :) Docs are always good! stabs suck really quite notably. It's a terribly limited format which can just about describe the behaviour of C-based programs without breaking down and crying, and which can't even do that on some platforms (OK, so Itanium isn't exactly a very widely-used platform, but once upon a time people thought otherwise, and it triggered significant changes in GCC before it became obvious that it was a white elephant with about four serious users). Plus it's critical to C++ exception handling in GCC 3.0 and above (guess why EH improved so fast? That's why). DWARF2 is `less a debugging format, more a programming language' and can seemingly describe just about anything. Among other things it allows all live stack positions in all functions in the call stack to be identified without the need for frame pointers, so those major platforms which don't require FPs as part of the ABI and which are grossly slowed by them (i386, I'm looking at you) can now disable them by default (and will do as of GCC 4.2). (Downside: only very new versions of GDB can *use* location lists: if a new GDB isn't released in time, the -fomit-frame-pointer-by-default change will probably have to be reverted and pushed back to GCC 4.3.) Even the Linux kernel now provides backtraces by parsing DWARF2. (Aside: the new GC is crashed by -fomit-frame-pointer. This may be intrinsic to the new GC or it may be a codegen bug in GCC 4.1.1. I'll look at it soon.) The *downside* of DWARF2 is that it's much bigger unless you optimize the redundancy out of it, which GCC is slowly starting to do because there are people out there who generate enormous executables, and they get annoyed when their 2Gb binary is supplemented by 500Gb of debugging info! (-feliminate-dwarf2-dups -feliminate-unused-debug-types -feliminate-unused-deubg-symbols turns this on, but don't try it before GCC 4.2 and binutils 2.18 because there have been really rather nasty bugs in the DWARF2 dup elimination that tend to break linking if you turn it on... not every time, and the failure is obvious, but still.) DWARF2 support was added around 5.0 (but is not *fully* supported by any release of GDB: but that's OK, because GCC doesn't emit all of DWARF2 yet, nor does anyone that I know of.) For things that don't think the same way, they get on quite well That is also on my list. I dropped away from preview-latex development a *long* time ago because I simply had too much else on my plate. I'm no longer accepting that excuse from myself :)) OK. -- `When we are born we have plenty of Hydrogen but as we age our Hydrogen pool becomes depleted.' _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta