Re: [parisc-linux] Re: gcj can't make shared libs on hppa

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[Randolph Chung]

> r22 should be pointing to a function descriptor and have the plabel
> bit set.  It's a relative rare situation when an indirect call can
> be made directly (no shared libraries).

I know, but that's not what's happening....

__do_global_ctors_aux() looks like this:

static void __attribute__((used))
__do_global_ctors_aux (void)
{
   func_ptr *p;
   for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
     (*p) ();
}

what i'm seeing is that we are calling the copy of this function in 
liba1.so, and loading __CTOR_END__ via the GOT, but we are using an r19 
value that is pointing inside libgcj.so, so we end up loading some wrong 
value for __CTOR_END__

I don't know how/why this is happening though. how does this bit work? 
each .so has its own copy of __do_global_ctors_aux(); how does this get 
called and where does it setup r19 for each .so before this gets called?

randolph
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

> static void __attribute__((used))
> __do_global_ctors_aux (void)
> {
>    func_ptr *p;
>    for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
>      (*p) ();
> }
> 
> what i'm seeing is that we are calling the copy of this function in 
> liba1.so, and loading __CTOR_END__ via the GOT, but we are using an r19 
> value that is pointing inside libgcj.so, so we end up loading some wrong 
> value for __CTOR_END__
> 
> I don't know how/why this is happening though. how does this bit work? 
> each .so has its own copy of __do_global_ctors_aux(); how does this get 
> called and where does it setup r19 for each .so before this gets called?

The dynamic loader calls _init in the .init section when it loads
a shared library.  It's also supposed to process the .init_array
section but that's not being used.

Disassembly of section .init:

00000824 <_init-0x10>:
 824:   2a 7f ff ff     addil L%-800,r19,r1
 828:   48 35 0f b8     ldw 7dc(r1),r21
 82c:   ea a0 c0 00     bv r0(r21)
 830:   48 33 0f c0     ldw 7e0(r1),r19

00000834 <_init>:
 834:   6b c2 3f d9     stw rp,-14(sp)
 838:   6f c4 00 80     stw,ma r4,40(sp)
 83c:   6b d3 3f c1     stw r19,-20(sp)
 840:   e8 5f 1f bd     b,l 824 <_init-0x10>,rp
 844:   08 13 02 44     copy r19,r4
 848:   08 04 02 53     copy r4,r19
 84c:   e8 40 01 f0     b,l 94c <frame_dummy>,rp
 850:   08 00 02 40     nop
 854:   e8 40 05 c0     b,l b3c <__do_global_ctors_aux>,rp
 858:   08 00 02 40     nop
 85c:   4b c2 3f 59     ldw -54(sp),rp
 860:   08 04 02 53     copy r4,r19
 864:   e8 40 c0 00     bv r0(rp)

00000868 <_end_init>:
 868:   4f c4 3f 81     ldw,mb -40(sp),r4

_init comes from the crt files in glibc.  The code at 824 is an
import stub which appears to be provided by ld.  So, if r19 is wrong,
it would seem the relocations in the import stub used to load the
new r19 value must be wrong.  I'm not sure how _init manages to call
the stub.  That's a bit unusual.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

>  84c:   e8 40 01 f0     b,l 94c <frame_dummy>,rp
>  850:   08 00 02 40     nop

I just noticed that r19 is not restored after the call to frame_dummy.
It's clobbering r19.

>  854:   e8 40 05 c0     b,l b3c <__do_global_ctors_aux>,rp
>  858:   08 00 02 40     nop
>  85c:   4b c2 3f 59     ldw -54(sp),rp
>  860:   08 04 02 53     copy r4,r19
>  864:   e8 40 c0 00     bv r0(rp)
> 
> 00000868 <_end_init>:
>  868:   4f c4 3f 81     ldw,mb -40(sp),r4
> 
> _init comes from the crt files in glibc.  The code at 824 is an
> import stub which appears to be provided by ld.  So, if r19 is wrong,
> it would seem the relocations in the import stub used to load the
> new r19 value must be wrong.  I'm not sure how _init manages to call
> the stub.  That's a bit unusual.

Doh, it's actually just a call to __gmon_start__ ().

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

> >  84c:   e8 40 01 f0     b,l 94c <frame_dummy>,rp
> >  850:   08 00 02 40     nop
> 
> I just noticed that r19 is not restored after the call to frame_dummy.
> It's clobbering r19.

You know, this function is a real hack.  Part of it comes from
crti.o, part from GCC's crtstuff.c and part from crtn.o.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

> John David Anglin writes:
> > > please see http://bugs.debian.org/353346
> > 
> > Should be fixed.  See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html
> 
> with this change (and the typo fix), gcj-dbtool segfaults:
> 
> (gdb) run -n classmap.db
> Starting program: /usr/bin/gcj-dbtool-4.1 -n classmap.db
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 6962)]
> [New Thread 32769 (LWP 6965)]
> [New Thread 16386 (LWP 6966)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 6962)]
> linear_search_fdes (ob=0xbff02054, this_fde=0x4291a780, pc=0x427ed7f3)
>     at unwind-dw2-fde.c:776
> 776     unwind-dw2-fde.c: No such file or directory.
>         in unwind-dw2-fde.c

I just remembered, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=334112

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

> please see http://bugs.debian.org/353346
> 
> same thing with the 4.1 rc1 build.

Right, it's a linker bug.  The following plabel is dropped from the
shared library.

0000000c R_PARISC_PLABEL32  .L_ZN2A1C1Ev0

This plabel is for a local alias.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)


-- 
To UNSUBSCRIBE, email to debian-hppa-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

> please see http://bugs.debian.org/353346

Should be fixed.  See http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00815.html

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

>  83c:   6b d3 3f c1     stw r19,-20(sp)
>  840:   e8 5f 1f bd     b,l 824 <_init-0x10>,rp
>  844:   08 13 02 44     copy r19,r4
>  848:   08 04 02 53     copy r4,r19
>  84c:   e8 40 01 f0     b,l 94c <frame_dummy>,rp
>  850:   08 00 02 40     nop
>  854:   e8 40 05 c0     b,l b3c <__do_global_ctors_aux>,rp
>  858:   08 00 02 40     nop
>  85c:   4b c2 3f 59     ldw -54(sp),rp
>  860:   08 04 02 53     copy r4,r19
>  864:   e8 40 c0 00     bv r0(rp)

I'm testing the attached fix.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Index: config/pa/pa32-linux.h
===================================================================
--- config/pa/pa32-linux.h	(revision 111979)
+++ config/pa/pa32-linux.h	(working copy)
@@ -1,5 +1,5 @@
 /* Definitions for PA_RISC with ELF-32 format
-   Copyright (C) 2000, 2002, 2004 Free Software Foundation, Inc.
+   Copyright (C) 2000, 2002, 2004, 2006 Free Software Foundation, Inc.
 
 This file is part of GCC.
 
@@ -36,4 +36,29 @@
 		    aligned(sizeof(func_ptr))))				\
     = { (func_ptr) (-1) }
 
+/* This is a PIC version of CRT_CALL_STATIC_FUNCTION.  The PIC
+   register has to be saved before the call and restored after
+   the call.  We assume that register %r4 is available for this
+   purpose.  The hack prevents GCC from deleting the restore.  */
+#ifdef CRTSTUFFS_O
+#undef CRT_CALL_STATIC_FUNCTION
+#define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)	\
+static void __attribute__((__used__))			\
+call_ ## FUNC (void)					\
+{							\
+  asm (SECTION_OP);					\
+  asm volatile (".call\n\t"				\
+		"bl " #FUNC ",%%r2\n\t"			\
+		"copy %%r19,%%r4\n\t"			\
+		"copy %%r4,%%r19\n"			\
+		:					\
+		:					\
+		: "r1", "r2", "r4", "r20", "r21",	\
+		  "r22", "r24", "r24", "r25", "r26",	\
+		  "r27", "r28", "r29", "r31");		\
+  FORCE_CODE_SECTION_ALIGN				\
+  asm (TEXT_SECTION_ASM_OP);				\
+}
+#endif
+
 #define MD_UNWIND_SUPPORT "config/pa/linux-unwind.h"
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[Carlos O'Donell]

> Index: config/pa/pa32-linux.h
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- config/pa/pa32-linux.h      (revision 111979)
> +++ config/pa/pa32-linux.h      (working copy)
> @@ -1,5 +1,5 @@
>  /* Definitions for PA_RISC with ELF-32 format
> -   Copyright (C) 2000, 2002, 2004 Free Software Foundation, Inc.
> +   Copyright (C) 2000, 2002, 2004, 2006 Free Software Foundation, Inc.
>
>  This file is part of GCC.
>
> @@ -36,4 +36,29 @@
>                     aligned(sizeof(func_ptr))))                         \
>      =3D { (func_ptr) (-1) }
>
> +/* This is a PIC version of CRT_CALL_STATIC_FUNCTION.  The PIC
> +   register has to be saved before the call and restored after
> +   the call.  We assume that register %r4 is available for this
> +   purpose.  The hack prevents GCC from deleting the restore.  */
> +#ifdef CRTSTUFFS_O
> +#undef CRT_CALL_STATIC_FUNCTION
> +#define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC)     \
> +static void __attribute__((__used__))                  \
> +call_ ## FUNC (void)                                   \
> +{                                                      \
> +  asm (SECTION_OP);                                    \
> +  asm volatile (".call\n\t"                            \
> +               "bl " #FUNC ",%%r2\n\t"                 \
> +               "copy %%r19,%%r4\n\t"                   \
> +               "copy %%r4,%%r19\n"                     \
> +               :                                       \
> +               :                                       \
> +               : "r1", "r2", "r4", "r20", "r21",       \
> +                 "r22", "r24", "r24", "r25", "r26",    \
> +                 "r27", "r28", "r29", "r31");          \
> +  FORCE_CODE_SECTION_ALIGN                             \
> +  asm (TEXT_SECTION_ASM_OP);                           \
> +}
> +#endif
> +
>  #define MD_UNWIND_SUPPORT "config/pa/linux-unwind.h"

Awesome, I hope this works. Thanks Randolph and Dave for the
sleuthing!

c.
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

> Awesome, I hope this works.

Seems to, so I will be installing a simplified version to the GCC tree.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

> but *(%ret0-4) points inside the text section, so r22 eventually gets 
> loaded with an instruction value (0x4fd23f01 == ldw,mb -80(sp),r18)

r22 should be pointing to a function descriptor and have the plabel
bit set.  It's a relative rare situation when an indirect call can
be made directly (no shared libraries).

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[Randolph Chung]

> The reason for the segmentation fault is the R_PARISC_IPLT isn't
> being handled correctly and the indirect call to the constructor
> for the library branches to the wrong location.

here's what i see....

__do_global_ctors_aux is trying to load a value from the GOT
(__CTORS_LIST i think). I'm seeing that it loads some garbage value
(0x4fd23f01 in my case), and then it tries to do a $dyncall on that.

__do_global_ctors_aux does something like:

addil 0(%r19),%r1
ldw 28(%r1),%ret0
ldw -4(%ret0),%r3
...
copy %r3,%r22
b,l $$dyncall, %r31

$r19+0x28 is 0x41896830; points inside the .plt. seems reasonable

but *(%ret0-4) points inside the text section, so r22 eventually gets 
loaded with an instruction value (0x4fd23f01 == ldw,mb -80(sp),r18)

dunno if this helps with anything... have to think about it somemore to 
see what's happening...

randolph


_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

Re: [parisc-linux] Re: gcj can't make shared libs on hppa

[John David Anglin]

> Right, it's a linker bug.  The following plabel is dropped from the
> shared library.
> 
> 0000000c R_PARISC_PLABEL32  .L_ZN2A1C1Ev0

I was too hasty in calling this a linker bug.  We end up with the
following relocations in the shared library as a result of the above
relocation in the object file:

00010f34 R_PARISC_PLABEL32  *ABS*+0x00010f46
00010f44 R_PARISC_IPLT     *ABS*+0x000009a8

The reason for the segmentation fault is the R_PARISC_IPLT isn't
being handled correctly and the indirect call to the constructor
for the library branches to the wrong location.

Carlos, do you have an opinion on how plabels that reference local
symbols in shared libraries should be handled?  This is what we have
in the A1.s file for .L_ZN2A1C1Ev0:

        .word   P%.L_ZN2A1C1Ev0
        .set    .L_ZN2A1C1Ev0,_ZN2A1C1Ev

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: gcj can't make shared libs on hppa

[Matthias Klose]

please see http://bugs.debian.org/353346

same thing with the 4.1 rc1 build.

thanks, Matthias
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux