Hack hack hack.
I would do well to take Ryan's advice I think. It is probably a crime against (something) to be sitting in the offices hacking glibc instead of doing something outside. Well, at least the offices are spacious and full of natural light (which is something I missed at the San Francisco office, which is in a basement).
Oh god our ELF32 ABI is bogus. Of course this is primarily because it reuses so much code in GCC and binutils from the SOM stuff, which is more bogus by far. Our goal was originally to follow the ELF64 conventions used by HP/UX 11, which sounds like a nice idea, except that there is very little useful documentation on them. Also of course, there is no non-PIC code model in PA ELF64, although I'm not sure that we get any benefit from having PIC code on ELF32 because the code generation is so bad and the conventions for common things like indirect function calls and long branches are so broken and slow.
On the bright side, not only do signals work now (for certain restricted values of "work"), but ld.so does run itself and manage to load and run simple programs (which then segfault in _dl_fini).
I guess in 1985, a segmented user space still seemed like a good idea, and the thought that the extra circuitry used to implement segmentation could have been more profitably used to implement things like, say, an indirect branch-and-link instruction, or a PC-relative branch range longer than 256k, never occured to HP's architects. We've taken to calling it PA-CISC.
That said, the 64-bit PA-RISC architecture (PA2.0w) is a lot more sane. Too bad the good bits are only available when running in 64-bit mode...