So I've been looking into the odd hacks in c++rt0 and ld/ld.so for PIC
code on the ARM.

There are multiple levels of bogosity here.

1) The linker has been hacked in a way that causes the [CD]TOR_LIST
   entries to be PLT-relative addresses rather than absolute
   addresses.  This is why c++rt0 (and the interface thereto) has been
   hacked to take a base address, which it adds to each entry.

   While it's true that we control the use of [CD]TOR_LIST, and can
   therefore do such a hack in this case, it indicates a general
   brokenness in the way set symbols are compiled, and should be
   fixed.

2) After removing the hacks that cause that, I got back to the
   original bug that inspired the hacks.  Sometimes -Bshareable will
   output an extern|baserel relocation for a symbol in the same module
   (usually for a static variable inside a function) which already has
   the offset of the symbol within the module added.  The offset is
   added a second time by ld.so due to the extern bit, and this causes
   obvious lossage.

   Worse than that, the hacks that `fix' this work by destroying any
   addend that might already be at the location pointed to by the
   relocation entry.  Although I haven't seen any obvious signs of it,
   this could probably cause references with an offset to fail in
   interesting ways.

   Obviously, this is a bug in ld, and needs to be fixed.

Unfortunately, fixing these problems will break compatibility with old
shared libraries.  I don't think there's anything I can reasonably do
about that.

Given how frequently the ARM code has changed in the past, and the
fact that we've never fully integrated the PIC support, it seems to me
that a flag day would not be a major problem at this point.  I can
supply the code and a working snapshot for people to switch over.