Bug in shared libraries

David Huggins-Daines dhd@linuxcare.com
20 Oct 2000 11:20:35 -0400


John Marvin <jsm@udlkern.fc.hp.com> writes:

> Here is a partial dump from ld-2.1.94.so. The instruction at offset 3c60
> below, "stw r6,0(r7)", is the first faulting instruction that is attempting
> to write into its own .rodata section. Once this is fixed, there may
> be others.

Yes, I know what this is now.  The problem is that the compiler places
static PLABELs in .rodata instead of .data.  This doesn't cause any
problems for static executables since all the relocations on these
PLABELs will be resolved in the final link.  However when building
shared objects they will get emitted as dynamic relocations.

That's actually not supposed to make the dynamic linker crash though,
because the linker will set a flag (and create a dynamic tag) to
indicate that the read-only segments in the object should be remapped
read-write during relocation processing.

I wonder if the problem is actually that the call to mprotect() that
ld.so makes in order to remap its text segment read-write is failing,
or not having the desired effect.

Still it is wrong to be putting relocatable stuff in the text segment
(duh :) I'd meant to fix this eventually but it never affected us
before, so I sort of ignored it.  Too bad we didn't have a working
page fault handler earlier... it would really have been nice to catch
it early.

I guess I will "fix" the compiler to put them in .data instead for the
ELF32 target.

-- 
dhd@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Support for the revolution.