[parisc-linux] broken toolchain?

[parisc-linux] broken toolchain?

[Matthew Wilcox]

as some of you know, i'm busy up here in canada building packages.
it seems to me that i'm getting a lot more unaligned data references from
things that I build than I was last week.  Also I'm getting unaligned
data references from glibc 2.2.3 that i'm building on gsyprf11 which i
never had on jagu.  I did an apt-get update on gsyprf11 and I remember
binutils getting updated, so I'm tempted to blame that.  can anyone else
confirm/deny problems?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] broken toolchain?

[John David Anglin]

> as some of you know, i'm busy up here in canada building packages.
> it seems to me that i'm getting a lot more unaligned data references from
> things that I build than I was last week.  Also I'm getting unaligned
> data references from glibc 2.2.3 that i'm building on gsyprf11 which i
> never had on jagu.  I did an apt-get update on gsyprf11 and I remember
> binutils getting updated, so I'm tempted to blame that.  can anyone else
> confirm/deny problems?

There still issues re the management of the PIC register.  These might
cause the unaligned data accesses that you are seeing.  I know the
mainline gcc was broken by a patch that Alan Modra added to add
dwarf2 profiling support.  On the branch, things are better but I just
discovered a new issue involving inline functions.  Don't know where
things stand with the parisc-linux gcc source.

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

Re: [parisc-linux] broken toolchain?

[Matthew Wilcox]

On Sat, May 12, 2001 at 09:23:47PM -0400, John David Anglin wrote:
> There still issues re the management of the PIC register.  These might
> cause the unaligned data accesses that you are seeing.  I know the
> mainline gcc was broken by a patch that Alan Modra added to add
> dwarf2 profiling support.  On the branch, things are better but I just
> discovered a new issue involving inline functions.  Don't know where
> things stand with the parisc-linux gcc source.

I don't think tat's the case.  Here's a dump:

!!die_if_kernel: ssh-keygen(6160): Unaligned data reference 28                  
                                                                                
     YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI                                           
PSW: 00000000000001001111111100001111                                           
r0-3     00000000 00030ed0 0001cd47 00000003                                    
r4-7     00000000 00000020 000000f6 bff04988                                    
r8-11    00000003 000312ea 0008e010 0008cef0                                    
r12-15   00000000 00000000 0008f350 00000000                                    
r16-19   00000000 00038f00 00000004 0001f800                                    
r20-23   00000005 40242090 000312ea 00000020                                    
r24-27   00000020 bff04988 00000003 00030ed0                                    
r28-31   00000003 00000037 bff04ac0 0001cd47                                    
sr0-3    00000000 00000185 00000000 00000185                                    
sr4-7    00000185 00000185 00000185 00000185                                    
                                                                                
IASQ: 00000185 00000185 IAOQ: 000127ab 000127af                                 
 IIR: 4835082e    ISR: 00000185  IOR: 000312e7                                  
ORIG_R28: bff00000                                                              

now r19 is 1f800 so it doesn't seem unaligned to me.  r22 or r9 look
like the problem children here.  i'll have to disassemble the source to
find out and I'm just going out so that'll have to wait till tomorrow.

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] broken toolchain?

[Alan Modra]

On Sat, 12 May 2001, John David Anglin wrote:

> There still issues re the management of the PIC register.  These might
> cause the unaligned data accesses that you are seeing.  I know the
> mainline gcc was broken by a patch that Alan Modra added to add
> dwarf2 profiling support.  On the branch, things are better but I just
> discovered a new issue involving inline functions.  Don't know where
> things stand with the parisc-linux gcc source.

hppa-linux uses dwarf2 unwind for exceptions.  Since the particular
breakage you mention only affects setjmp/longjmp exception handling, it
shouldn't be a problem unless people specify -fsjlj-exceptions.

Something like the following as yet untested patch should fix the problem.

gcc/ChangeLog.puffin
	* config/pa/pa.c (hppa_init_pic_save): Revert back to saving pic
	register after last_parm_insn.
	(hppa_inline_pic_init): New function.
	* config/pa/pa.h (INLINE_PIC_INIT): Define.
	(hppa_inline_pic_init): Declare.
	* integrate.c (expand_inline_function): Call INLINE_PIC_INIT.

-- 
Alan

Index: gcc/integrate.c
===================================================================
RCS file: /home/cvs/parisc/gcc/gcc/integrate.c,v
retrieving revision 1.6
diff -u -p -r1.6 integrate.c
--- integrate.c	2001/04/16 06:33:11	1.6
+++ integrate.c	2001/05/13 12:56:36
@@ -827,7 +827,12 @@ expand_inline_function (fndecl, parms, t
   /* If the inline function needs to make PIC references, that means
      that this function's PIC offset table must be used.  */
   if (inl_f->uses_pic_offset_table)
-    current_function_uses_pic_offset_table = 1;
+    {
+      current_function_uses_pic_offset_table = 1;
+#ifdef INLINE_PIC_INIT
+      INLINE_PIC_INIT (inl_f);
+#endif
+    }

   /* If this function needs a context, set it up.  */
   if (inl_f->needs_context)
Index: gcc/config/pa/pa.c
===================================================================
RCS file: /home/cvs/parisc/gcc/gcc/config/pa/pa.c,v
retrieving revision 1.21
diff -u -p -r1.21 pa.c
--- pa.c	2001/04/17 00:45:01	1.21
+++ pa.c	2001/05/13 12:57:07
@@ -3436,12 +3435,27 @@ hppa_init_pic_save ()
   RTX_UNCHANGING_P (PIC_OFFSET_TABLE_SAVE_RTX) = 1;
   insn = gen_rtx_SET (VOIDmode, PIC_OFFSET_TABLE_SAVE_RTX, picreg);

-  /* Emit the insn at the beginning of the function after the prologue.  */
-  if (tail_recursion_reentry)
-    emit_insn_before (insn, tail_recursion_reentry);
-  else
-    /* We must have been called via PROFILE_HOOK.  */
-    emit_insn (insn);
+  /* Emit the insn at the beginning of the function after the prologue.
+     The setjmp/longjmp exception handling code emits a call
+     immediately after last_parm_insn, and we need the pic save
+     register valid before the call.  That's why this insn must be
+     part of the parm insns.  */
+  push_topmost_sequence ();
+  last_parm_insn =
+    emit_insn_after (insn, last_parm_insn ? last_parm_insn : get_insns ());
+  pop_topmost_sequence ();
+}
+
+/* Unfortunately, parm insns are not copied for inline functions, so
+   we need to copy the initialization here.  */
+void
+hppa_inline_pic_init (inl_f)
+     struct function *inl_f;
+{
+  if (inl_f->machine->pic_offset_table_save_rtx)
+    emit_insn (gen_rtx_SET (VOIDmode,
+			    inl_f->machine->pic_offset_table_save_rtx,
+			    gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM)));
 }

 void
Index: gcc/config/pa/pa.h
===================================================================
RCS file: /home/cvs/parisc/gcc/gcc/config/pa/pa.h,v
retrieving revision 1.13
diff -u -p -r1.13 pa.h
--- pa.h	2001/05/01 12:40:14	1.13
+++ pa.h	2001/05/13 12:57:20
@@ -522,6 +522,12 @@ extern int target_flags;
 #define PIC_OFFSET_TABLE_SAVE_RTX (cfun->machine->pic_offset_table_save_rtx)
 extern void hppa_init_pic_save PARAMS ((void));

+/* Handle any special initialization needed for inline functions that
+   make PIC references.  */
+#define INLINE_PIC_INIT hppa_inline_pic_init
+struct function;
+extern void hppa_inline_pic_init PARAMS ((struct function *));
+
 #define DEFAULT_PCC_STRUCT_RETURN 0

 /* SOM ABI says that objects larger than 64 bits are returned in memory.

Re: [parisc-linux] broken toolchain?

[Bjorn Helgaas]

> IASQ: 00000185 00000185 IAOQ: 000127ab 000127af
>  IIR: 4835082e    ISR: 00000185  IOR: 000312e7
> ORIG_R28: bff00000

If you trust IIR:

$ echo 0x4835082e=i | adb
                LDW             1047(r1),r21

Re: [parisc-linux] broken toolchain?

[Matthew Wilcox]

On Sun, May 13, 2001 at 02:15:22AM +0100, Matthew Wilcox wrote:
> can anyone else confirm/deny problems?

I downgraded to binutils 2.11.90.0.5-1 from 2.11.90.0.7-1 and I've stopped
getting the unaligned references.  Would someone like to volunteer to
find the bug?  And does this mean we should stop the buildd?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] broken toolchain?

[Bdale Garbee]

matthew@wil.cx (Matthew Wilcox) writes:

> And does this mean we should stop the buildd?

It has been down since my T1 routing got torched yesterday, I'll leave it
disabled until this is figured out.

Bdale

Re: [parisc-linux] broken toolchain?

[amodra]

On Mon, May 14, 2001 at 06:45:25PM +0100, Matthew Wilcox wrote:
> On Sun, May 13, 2001 at 02:15:22AM +0100, Matthew Wilcox wrote:
> > can anyone else confirm/deny problems?
> 
> I downgraded to binutils 2.11.90.0.5-1 from 2.11.90.0.7-1 and I've stopped
> getting the unaligned references.

Can you translate those meaningless (to me) version numbers into the
most recent date you see in bfd/, gas/, and ld/ ChangeLogs?

-- 
Alan Modra

Re: [parisc-linux] broken toolchain?

[Matthew Wilcox]

On Tue, May 15, 2001 at 01:07:49PM +0930, amodra@one.net.au wrote:
> Can you translate those meaningless (to me) version numbers into the
> most recent date you see in bfd/, gas/, and ld/ ChangeLogs?

the version numbers are those supplied by HJ Lu (not meaningless debian
version numbers :-)

2.11.90.0.7 was based on 2001 0427
2.11.90.0.5 was based on 2001 0414

-- 
Revolutions do not require corporate support.