Quick summary:

	The  toolchain in the snapshots is binutils 2.8.1
	and gcc 2.7.2.2. Rebuilding those won't help.
	The source of one the bugs below is arguably in gas;
	the others may be in ld.so.


>I'm running a 'make build' on a DECStation 5000/25 now, and I noticed a
>bunch of the following (assembler) warnings while building the profiled
>libc:
>
>        Warning: No .cprestore pseudo-op used in PIC code
>
>Does anyone know exactly what this means?  I'm relatively new to
>NetBSD/pmax (I am more familiar with NetBSD/mac68k :-).  I'm also
>curious why -DPIC is being used for profiling code.

This means the assembler is seeing code compiled as PIC, that isn't
emitting the mips svr4 PIC pseudo-ops to save and restore the [sic]
``segment register'' used to set up GP-relative addressing.  It's
probably part of the reason profiling is broken.

The reason profiled libraries are compiled as PIC is because both the
non-shared (.a) and shared (_pic.a and .so) libraries are compiled as
PIC.  They have to be, so that users can link user-code as either
static or dynamic *without* having to recompile all the user code as
static.  (Because that's what binutils and the mips svr4 ABI insist on.)

We could punt on the svr4 ABI, but that basically means we'd have to
support our own toolchain back-end.  Time, time...

>I've also run into problems with perl, tcsh and bash where it appears
>that their private versions of malloc(), free(), etc. are not fully
>overriding the ones in the shared libc.  That's a guess.  If I compile
>them dynamic, they don't work right (bad block messages from their
>private allocators--or just failure in the perl tests).  When I link
>them statically, the work fine.

At least some of this _seems_ to be a bug in the toolchain.  There are
two problems here: the malloc() problems and modf.S.  

The OpenBSD modf.S source looks the same as ours, but when I
disassemble modf.so, it's quite obviously using GP-relative addressing
for the "li.d" operation. I think (but I'm not sure) that's a gas/gcc
bug: I don't think it do that for immediate operands. The fix is to
change modf.S to do the svr4-ABI .cpload dance.
I've committed a fix for that, and Simon Burge reports that it works.

I don't have a clue about  malloc()/free(). I'm guessing it's ld.so....



>So I'm wondering if the toolchain and/or ld.so/rtld is operating
>properly and if I should be looking at rebuilding the toolchain right
>now instead of the NetBSD sources.

No, I don't think rebuliding the toolchain would help.  We really need
to get the `standard' NetBSD ld.elf_so working.  I haven't had time to
work on that in ages. All the kernel support is there, though.

The ld.so we're using appears to be one Manuel Bouyer compiled from
the GNU elf ld.so. Maybe the problem lies there...