Re: Bug in shared libraries

Re: Bug in shared libraries

[John Marvin]

FYI,

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.

John

00003c00 <_dl_start+0x4c0>:
    3c00:       0c 60 10 97     ldw  0(sr0,r3),r23
    3c04:       2a 60 00 00     addil 0,r19,%r1
    3c08:       48 21 00 78     ldw 3c(sr0,r1),r1
    3c0c:       6b c1 3f 99     stw r1,-34(sr0,sp)
    3c10:       6b c0 3f 91     stw r0,-38(sr0,sp)
    3c14:       34 1a 00 04     ldi 2,r26
    3c18:       2a 60 00 00     addil 0,r19,%r1
    3c1c:       48 38 00 80     ldw 40(sr0,r1),r24
    3c20:       e8 45 18 74     b,l f860 <_dl_sysdep_output>,rp
    3c24:       0a f5 0a 17     add,l r21,r23,r23
    3c28:       08 04 02 53     copy r4,r19
    3c2c:       4b d4 3e a9     ldw -ac(sr0,sp),r20
    3c30:       0c 70 10 98     ldw  8(sr0,r3),r24
    3c34:       0e 90 10 94     ldw  8(sr0,r20),r20
    3c38:       08 07 02 5a     copy r7,r26
    3c3c:       0b 14 b8 80     cmpclr,>> r20,r24,r0
    3c40:       08 14 02 58     copy r20,r24
    3c44:       e8 48 0a 3c     b,l 15168 <memcpy>,rp
    3c48:       08 06 02 59     copy r6,r25
    3c4c:       e8 00 00 20     b,l 3c64 <_dl_start+0x524>,r0
    3c50:       08 04 02 53     copy r4,r19
    3c54:       e8 44 1d 8c     b,l db20 <_dl_reloc_bad_type>,rp
    3c58:       34 18 00 00     ldi 0,r24
    3c5c:       08 04 02 53     copy r4,r19
    3c60:       0c e6 12 80     stw  r6,0(sr0,r7)
    3c64:       34 a5 00 18     ldo c(r5),r5
    3c68:       88 a9 bc 27     cmpb,>>,n r9,r5,3a80 <_dl_start+0x340>
    3c6c:       0c a8 10 97     ldw  4(sr0,r5),r23
    3c70:       e8 00 03 f8     b,l 3e74 <_dl_start+0x734>,r0
    3c74:       35 6b 00 02     ldo 1(r11),r11
    3c78:       80 a9 a3 e2     cmpb,<<=,n r9,r5,3e70 <_dl_start+0x730>
    3c7c:       0d 00 10 95     ldw  0(sr0,r8),r21
    3c80:       0c a0 10 94     ldw  0(sr0,r5),r20
    3c84:       0a 95 0a 07     add,l r21,r20,r7
    3c88:       0c a8 10 95     ldw  4(sr0,r5),r21
    3c8c:       d2 b4 1a e8     extrw,u r21,23,24,r20
    3c90:       d6 94 08 84     depw,z r20,27,28,r20
    3c94:       0a 8a 0a 14     add,l r10,r20,r20

Re: Bug in shared libraries

[David Huggins-Daines]

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.

Re: Bug in shared libraries

[Alan Modra]

On 20 Oct 2000, David Huggins-Daines wrote:

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

The problem occurs when ld.so is relocating itself, ie. during
ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0).  I looked at fixing the
dynamic linker, but it's a complete pain to do as a lot of things aren't
set up at bootstrap stage.  _Much_ easier to fix the compiler as per the
following diff.  I've tested this on hppa-linux, and a newly built glibc
has no .rela.rodata in ld.so or libc.so.

Alan
-- 
Linuxcare.  Support for the Revolution.


Index: gcc/config/pa/pa-linux.h
===================================================================
RCS file: /home/cvs/parisc/gcc/gcc/config/pa/pa-linux.h,v
retrieving revision 1.12
diff -u -p -r1.12 pa-linux.h
--- pa-linux.h	2000/10/11 20:38:49	1.12
+++ pa-linux.h	2000/10/24 04:51:08
@@ -146,6 +146,13 @@ while (0)
   else                                                          \
     fprintf (FILE, "\tb .L%d\n\tnop\n", VALUE)
 
+#undef SELECT_RTX_SECTION
+#define SELECT_RTX_SECTION(MODE,RTX)	\
+  if (flag_pic && function_label_operand (RTX, MODE))	\
+    data_section ();					\
+  else							\
+    readonly_data_section ();
+
 /* FIXME: The Linux/parisc gas does not enjoy labels without colons.
    We haven't really decided on all the details of our assembly
    dialect, and the ELF and Linux configuration we 'mix in' here does
Index: gcc/config/pa/pa-linux64.h
===================================================================
RCS file: /home/cvs/parisc/gcc/gcc/config/pa/pa-linux64.h,v
retrieving revision 1.4
diff -u -p -r1.4 pa-linux64.h
--- pa-linux64.h	2000/10/11 20:38:49	1.4
+++ pa-linux64.h	2000/10/24 04:51:08
@@ -213,6 +213,13 @@ do {  \
 #undef STATIC_CHAIN_REGNUM
 #define STATIC_CHAIN_REGNUM 31
 
+#undef SELECT_RTX_SECTION
+#define SELECT_RTX_SECTION(MODE,RTX)	\
+  if (flag_pic && function_label_operand (RTX, MODE))	\
+    data_section ();					\
+  else							\
+    readonly_data_section ();
+
 /* This is not needed for correct operation in 32bit mode, and since
    older versions of gas and the hpux assembler do not accept .dword
    we put this here instead of the more logical location, pa.h.  */

Re: Bug in shared libraries

[Alan Modra]

On Tue, 24 Oct 2000, Alan Modra wrote:

> The problem occurs when ld.so is relocating itself, ie. during
> ELF_DYNAMIC_RELOCATE (&bootstrap_map, 0, 0).  I looked at fixing the
> dynamic linker, but it's a complete pain to do as a lot of things aren't
> set up at bootstrap stage.  _Much_ easier to fix the compiler as per the
> following diff.  I've tested this on hppa-linux, and a newly built glibc
> has no .rela.rodata in ld.so or libc.so.

Um, that's only half the problem solved.  The other difficulty is with the
.PARISC.unwind section which happens to be read-only and full of DIR32
relocs for hppa-linux.  hppa64-linux uses SEGREL relocs, which don't need
to be copied to shared libs since as their name implies, they are
relative.

I'm inclined to change the 32-bit ELF unwind section over to using SEGREL
relocs too.  Since gdb support isn't finished yet, we won't be breaking
anything.  Comments?

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: Bug in shared libraries

[Alan Modra]

I've just committed a set of changes to binutils on pehc that should fix
the .PARISC.unwind section.  To build a good ld.so, you'll need to
recompile gcc (or at least libgcc) as well as glibc.  No more DT_TEXTREL
tags!

Alan Modra
-- 
Linuxcare.  Support for the Revolution.