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...