Re: [parisc-linux] booting problems

Re: [parisc-linux] booting problems

[Stan Sieler]

Hi,

Re:

> On some X-Windows servers on PCs, pressing F9 will toggle the "25th" line
...

Oops...forgot that I'd customized my keyboard map.

My keyboard map, which tries to add the missing HP keys to a PC keyboard
(running Reflection X) is at:

http://www.allegro.com/sieler/custom.kmp.html

If you use a different X server on a PC (or Mac or Sun or whatever),
you might be interested in a couple of the keycodes that are less
common ... they're listed on the above page.

-- 
Stan Sieler                                          sieler@allegro.com
                                     http://www.allegro.com/sieler.html

Re: Hack to head.S

[John David Anglin]

> The module init/main.c uses the symbol _stext to determine the
> starting address of the kernel text.  Placing the start in the
> data region will give a totally erroneous result for the length
> of kernel text to profile.  Probably, init/main.c should use
> the origin selected for text when linking (currently, 0x8000)
> as the start of the kernel text.  Then, the kernel entry points
> can be moved back into the standard text space.

It looks like the symbol __text_start can be used by main.c to
determine the start of text when using the HP linker.

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

Re: Hack to head.S

[John David Anglin]

> It looks like the symbol __text_start can be used by main.c to
> determine the start of text when using the HP linker.

Here are two patches which appear to resolve this issue.  I have
tested linking with hpux 9.01.  Somebody needs to check whether
the symbol __text_start is available under 10.X and 11.

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

*** init/main.c.orig	Tue Feb 16 16:02:22 1999
--- init/main.c	Mon Jun 21 15:27:00 1999
***************
*** 56,62 ****
  #error sorry, your GCC is too old. It builds incorrect kernels.
  #endif
  
! extern char _stext, _etext;
  extern char *linux_banner;
  
  extern int console_loglevel;
--- 56,63 ----
  #error sorry, your GCC is too old. It builds incorrect kernels.
  #endif
  
! extern char __text_start;
! extern char _etext;
  extern char *linux_banner;
  
  extern int console_loglevel;
***************
*** 1132,1138 ****
  	if (prof_shift) {
  		prof_buffer = (unsigned int *) memory_start;
  		/* only text is profiled */
! 		prof_len = (unsigned long) &_etext - (unsigned long) &_stext;
  		prof_len >>= prof_shift;
  		memory_start += prof_len * sizeof(unsigned int);
  		memset(prof_buffer, 0, prof_len * sizeof(unsigned int));
--- 1133,1139 ----
  	if (prof_shift) {
  		prof_buffer = (unsigned int *) memory_start;
  		/* only text is profiled */
! 		prof_len = (unsigned long) &_etext-(unsigned long)&__text_start;
  		prof_len >>= prof_shift;
  		memory_start += prof_len * sizeof(unsigned int);
  		memset(prof_buffer, 0, prof_len * sizeof(unsigned int));
*** arch/parisc/kernel/head.S.orig	Mon Jun 21 10:38:05 1999
--- arch/parisc/kernel/head.S	Mon Jun 21 13:06:43 1999
***************
*** 32,39 ****
  
  ;	.section .text
  
! 	.space $DATA$
! 	.subspa $FLUFFY$,QUAD=1,ALIGN=8,ACCESS=0x2C,SORT=56
  
  	.EXPORT stext,ENTRY,PRIV_LEV=3,RTNVAL=GR
  	.EXPORT _stext,DATA,PRIV_LEV=3,RTNVAL=GR
--- 32,39 ----
  
  ;	.section .text
  
! ;	.space $DATA$
! ;	.subspa $FLUFFY$,QUAD=1,ALIGN=8,ACCESS=0x2C,SORT=56
  
  	.EXPORT stext,ENTRY,PRIV_LEV=3,RTNVAL=GR
  	.EXPORT _stext,DATA,PRIV_LEV=3,RTNVAL=GR

Re: [parisc-linux] __hp9000s700 predefined

[John David Anglin]

> > John, is there something specific you are concerned about which
> > can't be handled by the above predefined symbols?
> 
> I was just being cautious about __hp9000s[7-8]00.  I looked at some of
> the uses in the hpux 10.X headers, and for usage in gcc and binutils.  I
> don't see any obvious reason why these two symbols need to be defined
> for linux.
> 
> I believe that the compiler only should predefine symbols that are necessary
> for the control of code generation.  Neither CONFIG_XXX or runtime checks
> will help you for this since gcc only has a limited capability to change
> its code generation at runtime.  There appears to be some model dependence
> in the floating point implementations from one pa machine to another.  If
> this can't all be hidden in the kernel, some further specification of the
> hardware might be needed for floating point.  For example, __i686__ is
> defined on the Pentium Pro and is used in bits/mathinline.h.

There is a nice table listing model numbers, architecture and processor
type in /opt/langtools/lib/sched.models under hpux 11.  It still appears
possible to compile and link a PA1.0 app under hpux 11.  I am guessing
but it looks like there are 5 different PA1.1 float implementations (a-e).

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

Re: testcase for hppa64 gcc bug

[John David Anglin]

> > So I went down the path of trying to fix things properly by defining
> > ELIMINABLE_REGS and so on, but I ended in a maze of twisty little passages
> > labelled "Unrecognizable instruction", like this one:
> > 
> > /src/parisc/gcc/gcc/libgcc2.c: In function `__moddi3':
> > /src/parisc/gcc/gcc/libgcc2.c:601: Unrecognizable insn:
> > (insn 1289 209 1298 (set (reg:SI 50 %fr22)
> >         (subreg:SI (plus:DI (reg:DI 30 %r30)
> >                 (const_int -272 [0xfffffef0])) 0)) -1 (nil)
> >     (nil))
> > /src/parisc/gcc/gcc/libgcc2.c:601: Internal compiler error in
> > extract_insn, at recog.c:2134
> 
> I am making progress in trying to make the arg_pointer register eliminable.
> I have fixed the above problem.  What was happening was that reload_as_needed
> was incorrectly trying to eliminate the return from millicode calls which
> is also register r29.  I have figured out how to hide it from reload with
> unspec.
> 
> However, the compiler is now too good at eliminating the arg_pointer.  At
> -O3, it completely eliminates the arg_pointer.  However, as I read the ABI,
> the call must always set the arg_pointer before calls.

For the record, here is my final patch regarding making the arg_pointer
eliminable for TARGET_64BIT.  I think the code it generates is correct but
it hasn't been extensively tested.  However, I don't recommend it for
installation since in comparing the assembler code generated with and
without elimination for a couple of test cases, I didn't observe any
significant improvement in the code with the patch.  Possibly, the patch
implicitly disables elimination when the arg_pointer is needed.

I do find that Alan Modra's ARG_POINTER_INVARIANT patch needs to be installed
to get correct code with his test case.

There is one part of the patch below which I think needs to be installed.
That is

	(call, call_value): Always USE the arg_pointer for TARGET_64BIT.

The use for the arg_pointer needs to be pulled out of the `if (flag_pic)'.

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

2000-11-07  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the
	arg_pointer is being eliminated.
	(ELIMINABLE_REGS): Enable elimination of the arg_pointer.
	(INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer.
	* pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and
	canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside
	unspec to prevent elimination.
	(call, call_value): Always USE the arg_pointer for TARGET_64BIT.
	Use the new addmovdi3 insn to load the arg_pointer register.
	(addmovdi3 and mov_from_r29_si): New insn and expand which prevent
	r29 from being eliminated in call setups and millicode returns.

--- pa-linux64.h.orig	Tue Oct 31 18:38:24 2000
+++ pa-linux64.h	Tue Nov  7 12:17:12 2000
@@ -209,21 +209,18 @@
    that grow to lower addresses.  What fun.  */
 #undef ARGS_GROW_DOWNWARD
 #undef ARG_POINTER_REGNUM
-#define ARG_POINTER_INVARIANT 0
 #define ARG_POINTER_REGNUM 29
+#define ARG_POINTER_INVARIANT 0
 #undef STATIC_CHAIN_REGNUM
 #define STATIC_CHAIN_REGNUM 31
 
-#if 1
-#define ARG_POINTER_INVARIANT 0
-#else
-/* If defined, this macro specifies a table of register pairs used to eliminate
-   unneeded registers that point into the stack frame.  */
+/* If defined, this macro specifies a table of register pairs used to
+   eliminate unneeded registers that point into the stack frame.  */
 
 #define ELIMINABLE_REGS							\
 {									\
-  {ARG_POINTER_REGNUM,	 STACK_POINTER_REGNUM},				\
   {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM},				\
+  {ARG_POINTER_REGNUM,	 STACK_POINTER_REGNUM},				\
   {ARG_POINTER_REGNUM,	 FRAME_POINTER_REGNUM},				\
 }
 
@@ -240,19 +237,18 @@
 #define INITIAL_ELIMINATION_OFFSET(FROM, TO, OFFSET) \
   do								\
     {								\
-      int fsize;						\
+      int fsize = compute_frame_size (get_frame_size (), 0);	\
 								\
       if ((TO) == FRAME_POINTER_REGNUM				\
 	  && (FROM) == ARG_POINTER_REGNUM)			\
 	{							\
-	  (OFFSET) = - current_function_pretend_args_size - 16;	\
+	  (OFFSET) = fsize + 48 - current_function_outgoing_args_size;	\
 	  break;						\
 	}							\
 								\
       if ((TO) != STACK_POINTER_REGNUM)				\
 	abort ();						\
 								\
-      fsize = compute_frame_size (get_frame_size (), 0);	\
       switch (FROM)						\
 	{							\
 	case FRAME_POINTER_REGNUM:				\
@@ -260,14 +256,13 @@
 	  break;						\
 								\
 	case ARG_POINTER_REGNUM:				\
-	  (OFFSET) = - fsize - current_function_pretend_args_size - 16;	\
+	  (OFFSET) = 48 - current_function_outgoing_args_size;  \
 	  break;						\
 								\
 	default:						\
 	  abort ();						\
 	}							\
     } while (0)
-#endif
 
 #undef SELECT_RTX_SECTION
 #define SELECT_RTX_SECTION(MODE,RTX)	\
--- pa.md.orig	Tue Nov  7 13:50:34 2000
+++ pa.md.work	Wed Nov  8 14:06:05 2000
@@ -3993,7 +3993,7 @@
 	      (clobber (reg:SI 26))
 	      (clobber (reg:SI 25))
 	      (clobber (reg:SI 31))])
-   (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))]
+   (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))]
   ""
   "
 {
@@ -4139,7 +4139,7 @@
 	      (clobber (reg:SI 26))
 	      (clobber (reg:SI 25))
 	      (clobber (reg:SI 31))])
-   (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))]
+   (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))]
   ""
   "
 {
@@ -4197,7 +4197,7 @@
 	      (clobber (reg:SI 26))
 	      (clobber (reg:SI 25))
 	      (clobber (reg:SI 31))])
-   (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))]
+   (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))]
   ""
   "
 {
@@ -4255,7 +4255,7 @@
 	      (clobber (reg:SI 26))
 	      (clobber (reg:SI 25))
 	      (clobber (reg:SI 31))])
-   (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))]
+   (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))]
   ""
   "
 {
@@ -4310,7 +4310,7 @@
 	      (clobber (reg:SI 26))
 	      (clobber (reg:SI 25))
 	      (clobber (reg:SI 31))])
-   (set (match_operand:SI 0 "general_operand" "") (reg:SI 29))]
+   (set (match_operand:SI 0 "general_operand" "") (unspec:SI [(reg:SI 29)] 0))]
   ""
   "
 {
@@ -5785,9 +5785,9 @@
     op = XEXP (operands[0], 0);
 
   if (TARGET_64BIT)
-    emit_move_insn (arg_pointer_rtx,
-		    gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
-				  GEN_INT (64)));
+    emit_insn (gen_addmovdi3 (arg_pointer_rtx,
+			      virtual_outgoing_args_rtx,
+			      GEN_INT (64)));
 
   /* Use two different patterns for calls to explicitly named functions
      and calls through function pointers.  This is necessary as these two
@@ -5809,13 +5809,14 @@
       call_insn = emit_call_insn (gen_call_internal_reg (operands[1]));
     }
 
+  if (TARGET_64BIT)
+    use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx);
+
   if (flag_pic)
     {
       use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx);
       use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn),
 	       gen_rtx_REG (word_mode, PIC_OFFSET_TABLE_REGNUM_SAVED));
-      if (TARGET_64BIT)
-	use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx);
 
       /* After each call we must restore the PIC register, even if it
 	 doesn't appear to be used.
@@ -5961,9 +5962,9 @@
     op = XEXP (operands[1], 0);
 
   if (TARGET_64BIT)
-    emit_move_insn (arg_pointer_rtx,
-		    gen_rtx_PLUS (word_mode, virtual_outgoing_args_rtx,
-				  GEN_INT (64)));
+    emit_insn (gen_addmovdi3 (arg_pointer_rtx,
+			      virtual_outgoing_args_rtx,
+			      GEN_INT (64)));
 
   /* Use two different patterns for calls to explicitly named functions
      and calls through function pointers.  This is necessary as these two
@@ -5989,6 +5990,10 @@
       call_insn = emit_call_insn (gen_call_value_internal_reg (operands[0],
 							       operands[2]));
     }
+
+  if (TARGET_64BIT)
+    use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), arg_pointer_rtx);
+
   if (flag_pic)
     {
       use_reg (&CALL_INSN_FUNCTION_USAGE (call_insn), pic_offset_table_rtx);
@@ -7124,7 +7129,7 @@
 	      (clobber (reg:SI 22))
 	      (clobber (reg:SI 31))])
    (set (match_operand:SI 0 "register_operand" "")
-	(reg:SI 29))]
+	(unspec:SI [(reg:SI 29)] 0))]
   "! TARGET_PORTABLE_RUNTIME && !TARGET_64BIT && !TARGET_ELF32"
   "
 {
@@ -7236,3 +7241,48 @@
   emit_insn (gen_blockage ());
   DONE;
 }")
+
+;; For TARGET_64BIT, the arg_pointer register is also used for millicode
+;; returns.  The ABI requires that the arg_pointer be set for all calls.
+;; When the arg_pointer is made an eliminable register, eliminate_regs
+;; will eliminate the arg_pointer register from the function call setup and
+;; millicode returns unless the arg_pointer is hidden in a use, clobber or
+;; unspec.
+
+;; This is for loading the arg_pointer in function calls.
+(define_insn "addmovdi3"
+  [(set (unspec:DI [(match_operand:DI 0 "register_operand" "=r,r")] 0)
+        (plus:DI (match_operand:DI 1 "register_operand" "r,r")
+		 (match_operand 2 "const_int_operand" "J,i")))
+   (set (match_dup 0) (match_dup 0))]
+  "TARGET_64BIT"
+  "@
+  ldo %2(%1),%0
+  ldil L'%G2,%0\;add,l %0,%1,%0"
+  [(set_attr "type" "binary,binary")
+   (set_attr "pa_combine_type" "addmove,none")
+   (set_attr "length" "4,8")])
+
+;; This is for millicode return.
+(define_expand "mov_from_r29_si"
+  [(set (match_operand:SI 0 "" "")
+        (unspec:SI [(reg:SI 29)] 0))]
+  ""
+  "
+{
+  if (!TARGET_64BIT)
+    {
+      rtx tmp = gen_rtx_REG (SImode, 29);
+      emit_insn (gen_movsi (operands[0], tmp));
+      DONE;
+    }
+}")
+
+(define_insn ""
+  [(set (match_operand:SI 0 "register_operand" "=r")
+	(unspec:SI [(reg:SI 29)] 0))]
+  ""
+  "copy %%r29,%0"
+  [(set_attr "type" "multi")
+   (set_attr "length" "4")])
+

Re: abort in eliminate_regs compiling glob.c from glibc

[John David Anglin]

> Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0)
>     at ../../gcc/reload1.c:2826
> 2826      if (! insn_is_asm && icode < 0)
> (gdb) p debug_rtx (insn)
> (insn/s 2711 2709 2719 (set (reg:SI 6 %r6)
>         (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil)))))
>     (expr_list:REG_DEAD (reg:SI 28 %r28)
>         (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0))
>                     (expr_list (symbol_ref/v:SI ("@strlen"))
>                         (expr_list (reg/v:SI 4 %r4)
>                             (nil))))
>                 (nil)))))

The `use' arises from the `__pure__' attribute in the prototype for strlen:

extern size_t strlen (__const char *__s) __attribute__ ((__pure__));

Still haven't been able to figure out why the REG notes are processed or
a simple test case.  The cpp'd input is attached.

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

begin 644 glob.i.gz
M'XL("('T"CH``V=L;V(N:0#M??MWV[:2\._Z*]CFG%[+<1I+\BO5MO>XB9/X
MJV-G;:>]W6P.#RU1-F\D4B4I.]DV^[=_>#\'("DQS6/%O9M:P&`P&`"#P6`P
MN!?T@F^___YA\;X8Q_/BX76<QGDR>G@]S:Z^'WW;N<?RDW0T78SCA]/D:O2@
M>#^[RJ;%]S??!CT$T?>"=!#$SKX?@GZDKH<WV2Q^.(YNXX?SQ622I(@4!/XP
MN_KW.,D?CK)TDES3FAW?O6`PJ(_'+KU[T*#TO6"_`=$(_&!G:=H0?_K;*[5L
MU]N7?1='5_H0U3L'=;I_I3KZ_7YK=2!L^X^6PW;//YT0BQ'$(^^,`_%Q0N(\
M3S,Q[P9@GJ/H)([*11Z+6=M[Y,K&90_VW+F?^X<X8XQTFWS<Q]OUFF@R$G7<
MP]$XGDA.DNQ94HR`O$=P9JUF[.TN41C5N;WG*8?R>P=+$^6HLN_F$![R?2SU
M'&,1D#I(@O?ZGLY!^=OPM.@+#/H\7*3)._SC%DWE=/'NX552%L9DVJY?0*G#
M%L847DH._$O6%`QJ%XV*F57P,_O0DM*8!7W<$L1O<!WTEAR0&OM[#7I6'USQ
MNS+.TR!)RX!`#/6TS3`DR>$T&T5EDJ7!QFV6C+M!&$9EF2=7BS(.PV!C(PS1
M(EN48=CM#AU\&>S[!RA`UN@FRH/->9Y=Y]$L3-);1D681K-X"\PI;K*\)/D&
M'>7[>8PF(&]JEH?ED!$VJ%Z@K,F,T1GB;IX5E/%Z)EN3[%S)FAHS$T)9JX!:
MR<-%D3_$73F5H^OJX?5H]`#_]V8^CQY0#/WO'^W)YI9CQ#@^Y:BD6143P?.H
M'3Q8EUH=3_.)WMO>:;EBK,[NMXD3:YIM$]GDXY-ND1;)=1J/R>PKDO^)V>2S
MF=KOMS(J3*Q[K;+U;_G$DEY/+F`Q:K&;"-`P7(3XCZ&=3Z0E`2!_`1"XPW`^
M^B^0.\W2:Y*-_T`]BI8+)+E1+I+$80"#DW\XVC\6T1B/!;B@"<^AZ9RO+P$Y
M/ITK".=!"+6*<\T$T)A&*4+_]O9`)"K4P@+3N(O^'?1!)+(X!7#PR<%>]._>
MCIN[[FX1!05%G/=8(_@C&H]S(Y?W)/IS'-^J;6&#AZ`=PQG7=@8;6`E2/<`B
MLVP<PSDI&@%OU2RE8=EDHA<21$^-+`H_UPFCB0677P"]^329F5FB#IQ)V6I3
M32N2PZ/,%Z.R$P1_HO\/6,6WT?1U_\T0I7Q`OR8%*V.0-^:]PY.I$H44-#-#
M84R9S&+?`"QBI-Z-"T?IHBK_[FKZ5FN?DCE"$ODMU!"2`;<1D\OU-W@T4[C)
M.)Q%Q5MUJ0$XC#[,9`$>3%!+L`1YW=M&.OG#8.,@V"2K5C8)-@18M_N&(68=
M,@Z+&"#V;?Q>;P,H(I+YB`^W#L@GQ$)UX80A1FGI&.`TD\UJ:.A."JB\,GPY
M@!?'))GZ<5``"(<`0I/>SJ<3E,YA,U<=R&&!UO<H!P>S!K>0@&:/H7_G9>[H
M-#:DT=B<QBGO#:["D]6GO,GC:%R(Q6E.$^BBQ'[HVX?=Y0HKJD*-'40QNHG'
MAH&Z5@&NC=38=(@B:(7>:03.S%/U"1(?G<FX3W!V.(_0CE"3G"P]3[(\*=\3
M^3GD^^VE^JROU,KRPDE4E%A@=7"]JNPKHW)1X$K9[WF28CA$P0=MJIL(QW$Q
MRD.6NJDG#T%9]J>H9!R7T>@&5QTK-6,VS+-I,B(\@-@FH/`/63));]".N"19
M*KYL3M!3L837\464C_$O!0@1\I8L/$0V!@$V'^#52&1H&$@JQ?`AX$W&E@9#
M+BHM=G4$7D%"RNG`X"K)NHN2,L%*JZP(KV'NBAAK%[/9>[.0I!`4%QQ4K`2^
M"F9A'A=Q?JNR>H9J6:0EV))9F-VE<:X"OTW2\=#/FAECC6S';%'&[ZI:3X`H
M>J,DT$EJT[-T9"U=)GGY'54%JKHUOQ/]2JE""1@FS@N00RC[#@U?RB,HE_P6
MX\&#004257-NBX1Y@32N6&,1;YJ?NQA&Q^9$I;!;X+O-IE&93&.-\5S>Z,.3
M<;>"T5>1P6B4D,=_+))<'9PH<8Z'K&-\HFQ@JEU%>9[$N9,J9_-90;7]GH6>
MERJ)P._MU3"4:E(>F]U=MCUUP\VWV(&YTQ9;Z\#:8G/EW]A;"W6*;ZHM98[O
M@@'E26ZH92;=*`3V?D$H57SSH^61K5?`-F`ZGX6*%BBJFII-MH`!VPCJ662O
M%UP+35?)HGNZ@&_M]$RVK0O$]D[/)GO+8"'1*GFTD;*-9B9IB:)6JME$)0_F
M$+DD!\I@&\2@@/1UL4$+K(V:V*(%8JNF%23+1Z`N(JKNQ^U5>&_$G0%X'DY3
M,H0!64U752JDO>UZ`32ZV`XN4'9R-A#=809\H^E&1-BJ[?T<V'*&3LH!?([7
MA^E&6<R:YF@2UL)M9BFY!TZ6X9,R`#=6LAW)C\!DB$"<#$#;'[9Q[H'E]P_`
M\BCGT3Y48+`-]#U*[@/0!,]@!Z009>RZ24=##!RV^+1E;Q_*$N9QMSA6!8(P
M202J=4*?J`I084"M3TS6)R8?G3O8&6+W8U:V/D]1J>[M>)4YCQZYT%4QP(*W
M\!V@+(B&5^M3-T_T_"&PS]J)BA1B6^1_'N,C]^[0+(=/&[P%GSL*XG,&;\$+
M1T&B1?D*/N$%';OD1;A,>VT4S9MNXVC.!1M'`X:HK,SCZZ0HB7;C*WR7Y6/!
M3V6(ZSX6Z3B)4MU+`6VRT%[,S'H$YE&<@[XSTS8]XFG//$Z4&CCLX`"F`?:S
M-)VH5'BL='EU`<AIHXBG\:AD)%E>:FHN%IR.7)O=IN<(-59JV!P>CCHDP("!
MBPJMC7ZK:7)=Q+)9-<Z410E3("&5*;E&@S*;)2/8FB,,KY#1'1]@;4!G*A9P
MEQRNT',52@W;PN_T&Y)//+)J;/ME(:1_UCA<5N&9'EV7**P'-2J!E9RF[<;:
MMV_H?()](V(LO,.Z%^S#VS;J&PYF/`(V._)CEB2<4<SCD1B58C"6MR'2]X=6
M8LI2/\A-P'K?^.7O&P>/O'/!&#)(3FG.#?)<6!PG:YEHU@7R]%?G[OZ.:QE1
MW"QI8K#!/!@FXV)+8MX,\8D`6C'):0TV9^)\,G*-SU&$F*X;EHG?C>)YZ2JD
M\\HHBE.S12D5$Z6A\Y9:NE13EVMK0!Q;`T.BP&WV(9`+F5$6)1-W`GZ2K%]A
ML$>KPDYL(:]DJ(>+.DL$\[34"NYX^.-E"LP6A1=:,]L:-LN-FR4'3MUI(@5^
MA2KK6OW)&'E?S*)1GDD?8;^B9Y8!E@9]E>BYW)B9")4247BJ!(;/B@%$'$4"
MZ76BBU7ACA*HGBD&#'<W"53/$_LSJR5;,]6;Q:Z7@.@N+W;%#$CW:8$O?RC<
MPBO?$A[G^#C?V+HDF9$C;T!I.6I'?I5:W]KR_]5K<-"X;N-^9KT]M#+#C*V\
M#]ZNC2T).%]L2OAY:5'B/X;Z]EGU$9Q'X]Z0.RO2\UE4)J&W=E@R.T1%Z?BO
M(4OEIZ<HF?S)T^FQ*4I%?_"T:YYV+=,$@7DEA7U!(3UW186H0X\@4:X/*(_]
M&*JY5*23S&STME"*X@%!LR+\IT&)ZL*<+HH8<\LL-ZM3KF^7&]4I-V!M=T/L
M5*'89:TE&U!EM.SMU!LOSI&"G:OH6/E4`T4=(F*$D"54C!'O`%''!R_&1\B7
M,CQ$C_`&L![Y4'D\@!:_1Q])!-;XU,TJJCC@%_Z$=[FBV2)U*`8T8F4P&P6N
M%A.Z^U%JF=!JN!_WEEE<E''2N+>S#)4:G0@%1*E))JX)))265TE5BDZ7960=
M3@(\F:["E!I<L2H<W2#)8E='ZI`"B/YA]S\K+?D*EA!E1.Z"F&HV5&BYNS:!
MK^.2P9-KK281L[?C)+=;,(_*FRIZ:/$48@!8?$L(3_+?;F=H8YLDDZP^-5C-
MV_-N!K0M]N2=.N-NXWR+9R33<5Q8$Q#_UYX/86BC@08`N<!;-=!\U4Q7K<=3
M$=%YH1V6CW-2"/AY1V>/J*T#L<_`U;!AGMI`)JY8F[<ZHW%L1GAJ@R>'RRQ#
M9\PFG3+&%$^P`H-/2]V+%JG,U2S7("&]AC6Q'`D/4A,;BH.M0-+/(8>=#TZB
M'"M`-57UR)HN2U?5V@M7-U&KHP*[3F6-A*2?*X8$U?N(U=-3F4$%[W=\^'SH
M5(P@:/6LT5OP#'&,(US'<B-I6>KJDC==GKXZ:I)O5(E*H7%%/M!NKJC(NCD9
MG'=4,0'U3%W>UU)-=4&[6HT--2F=VAJ*E*D6H0V+2XO2<#?4CXRR[GGO.+WQ
M*DQ#Q]!S]38ELA7Y[JK8)]];$N&NJC^*"'=5UJ((;TV(RT]X0KC-[1W;,!X5
M19Q+FQ_)HVE&%C..FWG0)OI>L-NO`&8L)K?DPI`"A),HF=KLI9E)EL(JFY?1
MADT&]R:`99&.,/YN)[`]T=*,]@J/^`,2/J>!=BC]M"H<]F<Q6X)D#^4UBJW4
M-KAUP8:S/R`Q+>FM6:?G,P^8Y(CL2V<'SW"WCI?*<9*IGGK*A)@F5W@3)"'$
MD-=S.D;1M>?\VG-^[3G_E7C.#W8@6=!GN:O,]BB_5F9["YATWB@G_XMD6B9I
M>!LA(4P<3Z[3Q8C_M$7NO6!_%=D#4N/[E"N2"EV!DSZ]?QZY^T='SZ_['I^%
M3X]/C@+\S[`:+`P-0'UY(/^*Y6$?R%'+B)4I73P,GX7.`,;K=62]CJS7D<K6
M?-1%Q8JQ<X?56D?X/JV$IJG?)2[?K$:?B)7C%"%]#5C3<@GEA@?5W:B8715J
MEH@+8V1)K#L#1_Y:7JWEU5I>?4UZ[\X>*"7Z@"ZCWNC2Q<EV-:"L\,!5H?$Y
M@\B(2$&+-,E2X31$!3#*1SBI&PJ+<HE^7[W>$;>M;J/I@D1?"D-$`8X@Y17;
MTKO2%(=X6NR[<G;!9N*<?5CX2C=,4"QC+N\ZL_&8AHEDN3#711/[!V[<!&"P
M[6KIP%.Q+,[4=U?]W)L20+_O7HL&!RZL>`ES8=S9]:Y^QO0XZ+N`[P6[VZZ!
ML>OMC=V!NZ/Q4R3N%N\Y:]QSX,0/"KB&XIYC**H=!^L71#P8[RW(XO@MADH=
M!IC>W*$R#.<9#70E9R@SU-.)^RR<(`@MVJR!A5U-KH5'NK6S^:XUZQI1?:M;
MR1.<I&=PIW0M!T:X5M+62MI:25LK:;4_GY)F0CI72R?NM7:SUF[6VDTS[>81
MI`;TUROO>N5=K[Q?U\H[`#5^MO#&Z6+&MAS/'I^=_AJ>_1+\&&QO*2FG9_@_
M>LJ3G_7?+XY>;'64E*,7+R]_#X]/7[ZZ5`&?OCHY"<]>71K)QR<G1\\.3VSX
MX]/'9R]>GAQ='O$\H-23HXO'Y\<O+\_.]:*71^>G*/OH_/SLG(7QMEI[?!&>
M'%Y<XB:_V][>[FD8GIV>G1_1\A<<HL\PB<#<A*%H/Q;/AU!B.([*R,J99M$X
M'H?9U;_C46GEEGF4%JQ@1X_ML[')@2:CLAML`#4&F\*/S"($Y7G=<+@#CO[(
MRN;FEBO'C\Y&PVZ,;1)/&_*/%FI,;V*2)J6OG4I@+^+S(TO&Z;BBH+-2RGP?
M=VLX,GGXSV*K-W&':L3SBHY<H=JED/$.]W0SY3CZLXS?\?YF3%J%!57-:8"B
MBA.5C?MC$>?O6=-T)S?3QZX>5QOR5IE(E+&;NO>;>R+1\G(ZT>*X0J?,0O*5
M"%%C.J$4\??0`E!Z7P`J:78!1I(`9K_5QPNH`+4FHZ04`Z6HAJ%;IFM1[B'A
M3=QT;]#*']Y$Z7@:4TIUU\)9-F9/'6KF?QSJ'H">Y-F,/8UH9Y99*%`I*P'Q
M(->XQ+N<^`$G%A,E^P3C.I*\69(BQL2XE9@:Y=6"Z)TC0Y8H,Q"^S(9*#<1^
M.5E,24/T#G/V!1]=UGP,PVR!W9^'[JP8Q^M7ZI],H^M"2U%>IY2]HV9CW])H
MBD,6,^Y+>RQSU<8J@,-02S!Y!R+Y-70\-R(Z=9+1$<F?XD@Q8PI@E-.U*@Q%
MOOZZF'.!HKWP>OL--BY+,3"TW5D535+$%O$8RZ7#`3[P`J85;AP>[\JC&.)<
MS`?J66VE#/A`9M+L*DGI0P6(N$2T3`N>^&RYZ*2R[(I121&2Q5(40%CJT[+$
MAL)P*FO]BKM\\-EV4JOU*>YQ_U[,YJBO38\YP*>.>H^C?"U.OE)N%N5OXUQ[
ME4.F;K(%);!\\S;#@HBHCI`IY&`'[X6WP48228`W+&3HCN/1;8FO<R^F_(B(
M)V9OM[3?\R@ODVBJ)Q(??STIS?`,8!)';2$#(-4(?8"7&N,;Y8IN+.&)7A`$
M(,DZB@Q+90>.)GI98(CAAF7ITLI<I3YM::R0-59+@T`HD4QYK-\!2%K<)).6
M.@%_>D<LUYJ56I2DK31FA0&EZ_7:KZ7Q($1+#C%93!EF7:Z;&<R+4_0C2:]]
M$QLH%DWOHO<%DR0-RT[C]+J\<?59LW[P<)[I2BXJL(;JI:1+M3VA+Q"]`PVV
M(9"*I!K3X!1,=PE:;(7J*KH"9Y%7C^8E>?+*SHCI&U-VQE54Q%8.??K*DP75
M0W.@BM!:!2/#&52;-C**Z-91_U4T>KN8LSRP&%//#>49Y_+7\<R,:83#$3'E
M6EMM><_Q/[0JZ?-.J`VO>V]HC9:2@,@B779;1E=X/V=U*%G.A2N7W$ETJ/#:
M#,RN-5(9NXU4SCF9K/>HF6[AUOI2)JL=J:?R7F0[);,+9;+6?Q8\1P,I0_2/
MPLQG"A%"A.>1X"0.82$WCR*DE.)4DTW'^$\>P]>*;Q:.%CGJ]^EB1N:G]E(T
M[4]1G+O6&0,"UR:4/T0C>P62?9IGCB0$''^;<@!J^4(>\($F#+V\Y334EZ"0
MA;-ZW=M5@K%CRVGP`&W)9!*SS;SA0]9Y2T11?HV\<#[%SV#RFY10+OG5#WLA
MOL"2AL.ZL$@VU@=&VFIH1`Z2PX:(A3$>.:X\(H==F0BWZ%#[.3"TT\_HA)RD
MG*5XP<C>)O&6,"J@\;*E;,*OWI=QT:W"2B<HA-:T\F#TU6N]K-^NFADMLK"(
MX[>..OE`WB0^9OSNZYUE321X1M.L@(CO6@^N2?91"/:37>750[2J7&'0[+<+
MG+>'0=.?+F!!-(-FOQ5PAP^?THA-_,>0IPIJ-\E?(IV3M8G_$*FB_DWR%S$\
M$`E!J$$`G!3-#]`)$C@*ZGLW`H)EJ77A6\&;)J6A[HABI&_5V]#TX4W<W(I!
M:0TQ9T-"Q!1EPF@A)Q8IFJ*3:787;,BY:\:E6%0!9+<V$G[>Q`"ELW5%E0I@
M'2"X:IKOL;2HY*-RUW$Y4C$@ELV-1J*\^0)#,:/R5E`%/J&/HU="86,!`&?5
MC@8[?;XW'D/@2K/$")Q@<#+.0#9*N$7JAQ34EOE[!V0%BV\GQ2A*-88$,F2>
MOH]0,YRS0+\52N>/$H3/IOUV,L_1WT:?P!34(<"@0`VW(I8BW&_1.+4FQI8$
MDN640@4:D48I?DHG2LGJA):$2Z)A@G[K906(=A3L+(]6*%]YI6XY@O(XYKIK
MA(28-3B,F4LGW9UGUBF0:.)A2+&O"._J3#^L[YGHN9A5PQ.J'_9B&\!F4&LT
MW=49T&+[56M,+S.H[^J,:KD+K$-%S9%]9P]MVFG@Z-:'RIUOK-">V%=-M?H-
M;K%Z<\?^@/OW`[DT)+WEM^_XY,M"1C`/ZJMWD\WBAV.T%>/^2-<(;/0PN_KW
M.,EYI&M4`C%N)BX!/&I>T$,=%&J$LH5QFG)25]M%FJJNBT1%35?&5Q[/T/(*
M!]G"!Z/&(I631!L<[2-MK3N-[_1`,I26<C:G2XL,/NH$PA'0!!@#H.@1`"(E
MV."5%7I5*E"86V#8*1D*]&(4CUDE9LM0=P(Q'"?OP!@WLVB*EE,KJ@X-]XK5
MV&"#3VDT:^-H9O!\,D&;N1L("``+Z2J/U0<(WJX<$:?WA-8-DVP>IY6Q<]UQ
M,CT%L7@NE*:R"O-XQ2JK*W65,P5KH/(.>Z-#X2:@P4NX5B/F\"J-Z`Y!QJU8
MZ_+,JV"?Q:(Q[68U/I_EY"%M`#9[Z3Y([IY5.J/K9,0W3=X5<-FF!MZM&$LH
M5*'%*)\A<4O:S<DN%+,'ZAH_&S1<&$^(\%$><PEGA:A&TJ`JJBKS>C*>9_J?
M&!6%-AU%C,U[4KY8_;T%<12*=HXPW2Z'"FZ2U/M4MJ8Z]Y0VH'U9:W4'BOT(
M_V&%AT-5XC!H6GN=HIGK>V[BFHK;29;/(J2U??_]]\;Z(G3+90H7O#10ROD>
M6=UZU(INO3RQYXV-%>XV(_`06K[S:Z.-MPTX!*+K&/C\3&N]*7J'I?[*Q2">
M1>^P0')55:L/(76(YE-O&4I*&&X%@ZU@A_K-:%:GVW;(K4<QW'=-FK!-FJ!U
M=3OT_XW4F[+H-C*&JU[]O`14894\=Y-6HK</<!M'HZRBU35`?$V8-1[.B+J!
M2=VRM'TDRO1.'G/:W`J946\#&;1:KS8G;7F6&(^Q4.-/LT5XN664F9F6*EM=
MV/4(:NV%6%^)/7Q9>O5::N`00K1Q8RRTM=FZ6O4]1_7+]LQ'D_<0P_0Q3X])
M+`55`7%`=$P83+IAXS$@?,8*&YD"K6`U:6]B`#$.>WPT5(%V3&#2>@8/,H#4
MKE#KPVUAKU7.IL@N!BSXV&9?U;_86L]QW/E)ID,8]TWA4H(HGG3+8T+H#&&4
M2HO\N/U[X)JV"UJ%WA3EV!4PH>,3D'$\31P;=+PC]&DE_`/WZ"EO':D@0557
MXO&UTR*^#=+;(=S?/1#AF+H5Z':0[2U3<PSQN5]4K`MU)X/`ITR%Y@M.O3;H
M$@!H06'!+5*Z7GC%FWXX.L$.$J!ECVPV-#.+ZY4K8?SQ\7%HU4R\,F2S5B&A
MD@9GTXV%;FD"FC(#X@4PJ%JAJ7X/F3IY'+\U5Z<M]=');#(1KE<W<3I2C[`$
MV*2,\;F'\]R%M#&/[Y+4I4>`GTEH9E,JXYGY".50A$X+BWWV@^88.=#W&#/9
M(:K1<5EA6J>P#Z:&2U).^U\BPJ5K^=]09N"S"9`=+#`;Q!#+?X%RQ$:EZSN,
M(2J8@R7<8\]FBLT3N`&2*XKWG]9%9#2-IG&4QWE>==I'/(HJ0*@[D6=0:#76
M5+-QS;5!R0LG]51M0LN<NT#!"X:VG\47(,AIM>A\O0S]A<$0%-[\O'YCJ*=A
M31RAA<08M\2#NL9.@L!5\<,XP)G#!YVC;#:+4N^!F+H,.T^0+;5UA/Z>)6-`
M<]7!%D6<0V`%]6[,\+4!ZL.MT,%20VZKT8&-"<92O6M$;>,$0,1M:U0L:\V0
MQ>U-NNVG26:(XL=7)>TU!SWW1HVB5=W^_"N9_KB!=%=1?5S@;%#P\P>S,,V=
M6F<H,Z=90WD/2QX$44^7+5F2GG<`[_$1$G2;A/;$EG`/)0XU7?Z<E@L+,-$G
M<PTCL;O,NP]^4J^N!#_]&%CI,=(P_AE(!UR<'?P0;&Z8(3'LH@CE_?O5#3;M
M)CJ=M,4`H5:&02G-=Y`*816TPM1:1A.SAZ@)ANPA:,][T=4UK^C<V!#IE'9Q
M-8CU'9")V-(E?%'<E(5VH+.&!BOI8J99&9O.JN_?#WYD!;NNUSH%![_2%GL&
M#&#3,EK(1@O4/B`+:!T7-$W:!E=:JR^%(:-C&S*X]4*Q4*3>'E8M4$IQ4NP?
M_YW^8TO=;'D&EU\[](PI<I\O^"[8?M?;[@;?_!AL>_JT2K&L54]?KX>O;;O;
MSN4+Y>[M^A:W>\'>CMLGD^)W/"YG/<-J^]UIV6V=>-<^HJ?`#8_I]5-Z[XG0
MTD?:S0Z.JYMA'WX8O@9U3XL:'7TVH*MGT&78D>N(@@JSBV]3ASFP]('5Y]&?
MBAZ[CKBZCKBZCKCZM41<W7>NK9H`PX\CAVAMS4<W<ODL9_.ILFSBGZ'75<R6
M92Y_?Q\.2A':JH?X&@'"8#FW7<=IR*X8Q":Y%.)MDMJGY^PY7GRU))Q$900\
MDCR+BR*ZCIU2U/^,L=\28<!6F1>0S(*?#)(/\]X+=KT@QF#X2H7["M/C"Y#.
MZJ?>A4<*S#C!1QV5E[;6,O?O_/"&I_GS\8L4:7!CXQV;>58D[[0L\32.D=4&
MV;W]71"U-&XB)I<WV"A5B,8AL'?XQRW-IOL_@B',YO+-^^T5,*S>MA58L@=V
MA-:%X$-M<7J;Y%DZB].R,*S`=>`[4`5W63[&B_&#09^]!L<2'!7XX.6+2+7(
M[TM5HA;Y:.UJ`&TP_6#;S72@C[[.16V]8UGO6/Y/KI[][0;3'_R4P#MIB=0D
MM'GA?PPMD`+IX%.\G0C$7[I"I=Y#&(W0]L#>-)![H7S;@C#;Q]SQ(ADW+*TS
MA;U>9"W[AM?+E#KYJ/[^BM-,$9>VWXS54NDQ0K!AUPT#G_0Z<6!46LY.V3D&
MW76+;2VIUYJLA/M).6-;&>69[YE]R\&!""1BWH0*F[&*WXO`V)0NCT7:J&Q(
M'\H"9XK=HUH3]?[T-M)S)<P<!5"WT/:;XV<Y#CCK-&?:/)D+EN._QW'QNO^F
MB\,;#_;Z(+]8:2UJ=32-\IER.L5.&&)$_;B@V/9!)1W$5DSC>.[!9LR_!<M!
M;5TP0K1$]NKN5F"D)C@R/,K2W5P)JQ>,!*/$PJ!!962T*+10$^JDOLGN``<<
M&JH+84W&M)OND-)''!-8PG6>+>:`$R[#IPZ3"AR6A)VV09/>QG$"N%UA0YGM
M5\*`%2F']#?'5LWTB!_=*2Y#^GP0UZ%E=:(8#C"9(PT:F]A":@C3KHR8\$8M
M-@?'B[DAI_7,OMI!_*^^"B@.6)B"/S1S9+JY/KZ+1U`P%<QM>9N<N9[A8X[;
MUV]`66&"HAKGK]\`?F>\1MDD1RTNE/:((2B;M<$:21C'U,D(,Q4A@6^:$32M
M8+F=N^:4KT46+4XL?F)4/&DR$OV%]%3`53*,W^%@@DRZEE&Y*+HU;+B=BKT\
M?CL"3S##FE$%RP8Y?N>+/QX1OGP<GAR?_A*^./P7>4",)J%?X>/#T[-3(TT^
M-$;33@]?'!E%7QY>/C>3CE\>A3^_>JHD/7Y^]MMI>'YT<7E^_/CRZ(F*\RR\
M/']U^EA)^O7)\<7ASR='2M+%[Z>/P^,S)>703GIY?GRFIUR</29MU:G!QNZ+
MX_\Z^OGX\@*GBN<%))\N4`7GS]2&7>!6')\\,=-.?@DO'_^BI)P^.S][]?+"
M@#M[>71J)"%F'!V^,!(O_\MD,DK\?V<_AX_/3B_/ST[4\H>_'CT)CY]<*&D(
MX\GE,4)P<?SL]/!$S<+<.3^^_!W]_?SHR2LT#)ZI]:)"YRHXX>_S\[/3LU<7
M"E,E(L3`)WH&+V'G/,59RN\7AR]?(AC2$6KRT8N3,XV9+"4\/SQ]=J2GGYW_
MCD@YNSQZ?'DL1R[)N[@X?':$AN;%A=[(BR-4\?.S<ZW2B^>'YX@6AO'LY_^'
M$&J,0(/JY/@"56+TRB&80@;ADZ.3RT,C$Z4=_D[8;&2\^$]H=*!4@DI/_15U
MDM[:EZBI>#"C)#D*+E'WFZ/MZ$5XBOXQ!R9.__7PY)4YYA"&_WQU9"6K#5!J
M_!G][_#"!$:I3X[-$8X2+QX?G@"P6#J<6I/N[.0D_.WH^-GS2Y/TH_]\=?PK
MFH&HG\V<?[T\#T^1N#'2T:`WZST_"I^\>FG-],-SBE>9C2*W#W1#/T1-.#Y]
M8B0].?I52WEZ=GX))R(9J"5>_&;!H9F`^/;DZ*E*S,OCXRWM5_BO2S,%B\&C
M2R.1O@II)9]=:*41][7!<H)FAY+PBH[0X[-?'=B9E'/E/GEV;F4B"E"O:W-0
M))^`R2J&2R1Y?A4#5*0^1U1HDI*F("'Z]"A\BM8?+$34_&='E\_.P_,0SRUC
M=*"LE[_!62=GSXY/K7425X<$+Y1,J7B"5\97CR_/SL-CQ)E#DQ@&]LO1[^9(
MY\VX/,0KW?&IG<6:#I<[O+P\IX4/GSPY]^4S&6/D5RPJ$@AU^?,C!.G(98(<
MRCU[C.0YD]+JP#]E66?G%WAQ?+H%9YV=GFCB\CEB(9&9JMS^%4Z^//K7L2E"
M7DII(]+^1>2W+11H^K\>OW+FO3H]_I>5^/C\]Y>75NK1Z?/PN'=@X[AX_D*7
M3EAZA6@8J=,""R-(:KUZ>62WY%\OG_7M9KQ\-H`2=]3RI.J?M6XF2;9X-08K
MD@@&$$G18$[.T.J@(__M[/R)D?3BY_#$6DU/_^OH7%-5@+E[`5!Z`9!Z\?S<
MI)4F:5"O`&RO[%:^(HTRTI0:9`M.L$9JM.HD/$&*D97XXL)..[52+HXNK30T
MXB_-P?WSQ6YX?/)RT`_/GCX=:`-#R_KY^)F9=_)R;P=G[>W8.0A<EC*&%7[-
M^/'OUFCCVJTS0Y'S<A8_^?7X`JMVQZ=/U2'P\^'Y^;&N\V(51AVFA+OAQ:N7
M+]$*[<P(5;GYF*BK=)W4Y]ICM)?2:6<BSLY`"__QXR-=A69I%R^/'A\_/7[L
MSM'(>8H4VV<O5-J?'FM<P)LU+1<I9ECH'__\ZE(3AB0'-TX7\23YXO>+RR-5
MVKQ`VX9+M!%@_%!S7J&.>HG*,!&M:9RGS\`,I"B@>6Y4C%F'--'?SO&"20C3
M<+U$R["9>'[T#"F&9@(@%B^>'^EJC[69NGAY^)M6`@V$PR?'6$,Z1_B`!=H)
M0)D7/CF\/#3&GY&C=2P>,6>O-&WH\O>7OGW,*U1S2/>F<*J&_^7/%_JO\/#Q
MX[-7IY=Z+^`,K)9>'AF);!-FI%Z>'VJCX>)WM+T[>XD3/@PA>\7C"V)A$'N-
M+9%\\A0M^T]/#I_A]\A[V]O;'"W+.WE",LW4XY_MI--+`!0)KL=P,H@9IUNX
M22+##C3!E*Q*>WI:>RQ`FP0;1*<&R+>;;<ESFP4V2!4M!,9'#`5P4"-7$`<M
M"H"#$A4"H$/+=E(A5RLG'0J(DQ(5!J1%`Y!#A\P/'/X>=LQ2;JJ(0`G8UHJM
M@2XK+`NOPR*%VW$69'G3ZNXL4[POU!("SHA/@6&*,E?!7.\)36,C!BP^5!O3
M0#'S9&R'&%?S=0`0Y#J?6]',33AR@V-^G9!`&CQI3HM`*$%`TYA<@)!;2J4X
MFYZS[NX>.,]93910>QSM0O"%SB&[-86C,?*HD$,NX-X0^;$#X)H#7%?DQ]=P
M=[+`5^08K1#&=QS(1#EDHV$"K`,&4@B'8KZ*R5&;.)-S=MJ",H2?YBT@:A!8
M'AN`^2+1CA5C5TFSX,))"AL^-LTF*09@?DU)X;]C5TFS(,`5/C0F6?X6/O_C
M$+<VB'8V5Y;OZ2$BZ*F!$QE$F$.'9KK8P-&SX]3"D!010F)68=113+/2-<ZF
M2?H6.$C*LYE]D%1F5OW%^]DR&%04V(,"QJ&&0=%._&K%P+8EKE+I(H6K-!<"
M0N"LWK$U'Q?E2,AAU]EO.2I,$%U0YO/0$$SBU'F:72>I1VR0?/69";H:28\0
M/.*L58A-$(;<R1;ZF:[6J%;%-5E=T/6<_C:4Q5`.!L[,CO1^-;,U[J"T*+_&
M:L4>2(06GV->)O1ATHZ1S!\GT5/1_\C2]6C/TX9>#VX$]JYTM]WH0)3#AP5J
MS8@/>]HC]#SWUGP]BCQTB0IRMQ-\B;COX:?ZH7YQ]";V4=[O>QRV`>IOLJ+4
M+Q&Q\2>\`N$96:A%88<^[XQFY;%\5P)P6:*943G.9E&2@G3JE>@UJ,66H'%2
MO$]'EK!6(6YOHO1Z,;?5!BHI;[.WCO=Q8,^M/$-YBI<4?4@59^$Q$\WFTSBD
M;P_4"9DF(+B;HNE]-8JFIG,-<_(L?3)%<Q'*LPP`MH2M$(<X0E!Q$]LWV(G_
M0IR._0`%A`&J9QY!GJ:(P[-Y:8O2<13/,N%_E6;$FTGL-C+BPFEUF1BWUW(L
M0^.`CB+G`C"/KF/<50P$<-<@;0`?`2KS13J*2L<@4WTTV;O:JE(.X(&>@%$P
M,>=##9<Z7R0YD/^M30)4UNUMJY<W!`1Y4%AAXQ"JY(HK@$0NC\>Y@8QF%01,
M>$Z34*-EQ*\D'L"7,\"M*`G4H(@WE)9FJG,/0O=HQ^/"JFI^^*JDO14>S4P>
M.QA,RNO,-3%(/D.;-Z._\$O)FGQ,IN/8CD_%%L/\_1P0$V_C][;264334I,=
M3#(P'$+?Q@WB;8C'.(2'J?E3B7$777D#4%+5%\@H,TBL%J87M=W8$@Z6AI01
M^#:5M@;0VV%(!LCM2K!!1%<\C_*XR\:W-UJ#+!1A!\EF948WJ"=Y$3%.!X[+
M>E:(D@9._EJYAA<$+%=]-&Z7<M8W[@\P-(UN$-@H\/WJU?#P-@E,RS9,CM=F
M_OW.L0*XXEM5$;);JJ]VI:TY]P<`>_VM;*?6!E6W=[.B28>V6&G]7FWU#D6S
MKFVYZJ;UUYP_SO)+W`K21++S)@ETPP,M<Q5W/#3<OLL*(`]K7(C0*K"N5,`]
MTQ1MLUL6KCJ]5?CO79B--*]=:*H(.3FHOEZAX63V,]>&#G_"\3U*LS1!:B[&
MATK%HS++WU.358*OXJ10A)'R)BGP]JIRJNB?VH*&1:WK)%J#S6L?9J;SVH>N
MO[1U@<-SA</<8U#LM<_8[.+59VQV&?B,#3RR4G;$8+X7P#@=,@YT"()%17X,
M`EQ+@.N*_!@`H,VN?^"C%_.>]VB@KK,>$ZCN28]9#CQ;,8'J'1':)-4[\;'Z
M7#^CT=`N<_BB(0#.7G3)WO1@1&_U$B<KNMAUGJOH$@0ZGM8059R5F*.XO@%8
MUPW:M576MU::]`.6'PT$LOGHRZUU/]O2IAI>S[;*+Z^(R:GAGAE-;8BZ!E'3
M9J=9R%!O>&QD'=,D0)31.,7]A-7!11Z3HYF]@^HH0<SZH)]?S>^L.$%W8YDJ
M0P2)5,6&M8Z7LHZ7LHZ7\C7%2QGLF#+`CI3"7G/`IT)W8Q()FJYV\SNRW`W5
M!`J$D[@.A1+1'S3EFJ=<TQ11[!IM=`LM!6URM-_DU&K8^0`<PO##K?E=G);V
M,1(_''-D:ZVCQU\&H`MT(F$K7^UC<.(1%1V3[O_A6.2!(,_ZT^Y02QS^2)X2
M:32K<HK`A__;UBIAG,SA!F.%T]=4].=B6OHVI;`;C*X84975_3R\3@!$@=EA
MG'5A;C"O;B6?;2O-1J*.#0%[B?KZ'M9HO_1F=_3^G:@#M-DSPRTTNXUV-VDX
M,+;-8:WND!`=CI,K986PE&C?=&?\,"KQ&*),+L"MI4VT*0$G+MAG51UE4ER_
M>YI1[)B%;#/Y>1(.S"$Y<Y8C>@6J?63?"_;A<)+V;DDN<-K`Q^;9M#3V3311
MRQ.[)S//J7\QSS4+W@PI`L8YU:LVXG?Z2ZB*'4TDUW;HA88P23/$]C'^[Y`E
MT4WM&/^7"@><#!@PT-3#,6C2H0Y`>G9,#J!I#DO`0_QU?W?OS9#?(M*(VMN1
MMXDP->3LQZ2+)1+*/A95O+O@[N4A70\<O6E^VC6I)Y?AJ]-?3L]^.PU^#/C%
M(92([_KAVT0RY?'S<Y30EPE/CG'"CDSX^>07E+`G$\Z/GJ&$`YEP<OH+N7(E
M4W!\`9RDX/WM^25.V>EHS9>!#UD?D0#M=,8'B!15%\64;>*']L#C&-@?#MN2
M"#@I3)#/R?3M[>PZ^*KKL30CV,0F)P"1N1H:(TV4PX>64$G-/9%`AK(.9?7%
MA9R/T^J4:N502OZ^9L&*]=Y!+YHIC2D.;#[5IQHH[*%<W;#11V!=O:CO_.*W
M)ISV,BU_%M0\CL$OFE940&1'DD_&CK%D+A0R_'0OG"8SR$W<`=+?]<(X%I"6
MO^;!NHFM`VC'<A@L6A[>9#.T_$:WL;2GX)*<W_07><R\X+9%J%DL^O22[:H?
M/);9WGR=;2(S7=+!(@B([;CAI4?CV=H^N[;/KNVS%M8OTC[;[SLV&WS:J[[R
MHPA6M_25'EZK3?W"-@+A0WFX+*X<>[\6\91XL70M0R='ZW"CY0A&LWG7]#<V
M#_RZIIH#,@%RQJ_#!DAA:<**^LS`J)U>Q<LP1+V%,IW?1`7>_%C.VW'//D&-
M^]T.<.PY7^2Q$N72YK6H1N7VZA6I=X3BO$@0BH_>%*6B=ALCJY&O"N*3=S(&
M\B0N()>,6I<^U3';T$]6[.>-NJ(BGCMV$0[J=0?/9>E?H@7JWM_7"M.&J4M0
M=;>*\%7L5VW7!V#[`&])J1]$37"^QW+L1BW7%WTG2O<_5OU-]FD>LQ^TDP1J
MI$VHJ-.Y.P3J=<IUOS0'Y7D-*=Z2'&\NR:WIQAX23DM04H!>-!TO&GC*5B!B
M]U-4@:]2'O%+NO3GE?,%/"D=-<2&^%T1];W@T:"9P=>G@EGO"R-5D9F"-0B:
MHP$(>["99U:PWK.M]VSK/=M7LF=C/C66/+"=\KPFJ+LH*<GCZH[(\96%-*)V
M8$%$;$N>Z/48'XV%7R=^O0;=C&FZE,5Z6)3R*AU/(@($(A8CMF1I@)/%"0M>
M8^Y82']ZSD-7<+9H_\FIX&NVZCW[0V]O"&9@UU2DJY2C;!S_<."!&65Y/%[,
MYC_T/$#XVBM*^F%_R,GX@--1*TA6DD9E//;0WISTHLSFN$8?Z1CF-IIB&),J
MG#6G)*D'9#N58]_\^)D2Z3?19;(7L7*RF)?Y4'0E2DA8`B;GM\-C'*CZ\/+5
M!:`5E'F4%O0J;TB0VMM`BQ3!83E\_EADI:0@CV>T]G%RRU[\<I05APT2@4@2
M6*823:>#;\.4<5H04@,?6A=NH`*M!N7CNP^N]XUP?5A3#&=7^(F8<!:]`V*,
MC;/%U30.HC(#+L^DJ&\@+VIE8ZS:$,HL606':"Q"!-R7JH'(9+F*6,/N0E]I
M!="YAKJRS,9^GRN$UK6E$,_D:&=P8TR(6MEDFD4EK0OHHWIU^:M2^:0V;;I\
MVQJU4$:+(+6N4*F[0GZA"]L4E#8+0:G3L%B%B,;D=.RQVP''+J'MCU5)J\\D
MD"2=90;?5B9N2>8UX!\T^QO2^#$YV`)Y2_(0'TW"&V!+JWM'M'CYX#`]DR5I
M9E[?D0DOU8@B"A&R=9)X,K$\EH-CKF"NT)_%Z][@S9`H3I1I\%TLNAY>#068
MEHY&1787Y\[<!=*04.X'66U(`ZOU76RA)[U]CPX%W"DEPS-<=0#4ZW0_#ME,
M^J=79#+*%ZN37JL1-3$H306;4T->\"YIJV%M]`S]:C?((6M$E[799Y6-;(3'
MVW^=H:F,L1:-5VR/KXM\5%`MC1$Q68V(1C3`^AL?N:NR8_4NA0CNV+JTZ#YW
MQ(3FH[)ZOHE7/^%N;)&8YK3`_=DF?U;O7?:I#0!V=&)I:Y?X%0E7!8S1@%J+
M7?L]T4JS:C:PV?KW,=K:2CN];5QR170UMAGWZ;?J8*!?:T."?BZF=:1=21P[
M)CB00LSD4*>NR<.W]2<73^G3J[#83]E*Q\7C-NK-#Q9%O.<Z=:T&M;BH[HIL
M.J=>.CE+87HM4=*I;6JHU_]^TA=-:+?[GRR,G;I6J(;=/UFV^]516<=:U9"N
M:9UQZ3([ZI3JG5[#3-+&:&W2Y?XVP$*S4]OHT\X(;C:$FW=+'=M+&RWYNSK&
M;@^P'M5<7-KM&\?RXCF'4"N5JQ"MAP7MV>P&&RS(37>["TH-S!O/085:"7:M
MZ2HF:4]56T&O8HWRG&E8#:M=6[,1[CWXL&AH0(2F,%#8Z=Y.I,5\3L%[.]'>
M#D`1^%B[>@QC>?*\+QYB0YTXV1X\\AG>.NJQU:"/-J9YE(ZSF2/@1,%SK9".
M,?R$2I+2@^P8+"(=M0B,UZM21HS"H&9P?HH'!XBCE9EXY>$HLY_2AA#[J7HD
M2EBP.5%/9FE2;B<1W,KQ*<*H7+H42>/XVD@IXKF!"HF&D!_^ZB>)C$YY!UTA
MO+93JJBG.GY"(2L$.PRF@G%8P2,ZWHD)6%26&`65+I)>?IF-CR7-RY!7MTI]
MVA%X.>&L^>:9;082B]>;^M0T#4UC7&CGP`PBQG)CG@N<(H3ANV)QE;P>O`&%
MV11&+/+3Y5'/*E#_NS%JR6E<3-T$(];=1E-9"72<@H&<U>',WMXMK5"M;HK$
M_+6SV#S*H]GK?4HE&U2LKW2)!91^]WKPQGEC//)ECIPY6/F7>/GTEEXRZKU2
M1J846"KA<'P0QW1BP]`AM)0Z8UFGM].K+L=\'$+U-Q?:8X\8J-4,2C\Q@ZI(
MU5@T^R0L^O>7Q*)"$FN+JRT7+2P*3L=<\V)?NZ4$<T7I]%:FU\6DGK,R+O<:
M,ED+[],Q!/OF+)I.LQ$:3%K(9T"MIH"Z(Q9%,3)1I#A>KQDU&_*8TG!:I.4Q
M0\QO7Y$]QO*$3O(XUI!I6@))'SE@S'T$J2+B-P*,VP!JI@S18N2QOEC?!%C?
M!%C?!/B:;@*P]P0M62"\H3491_--\:LZ5SOD3M_&A>]J>;#="W9W]GS&#@W9
M[5+K0D=;T$A$"QR\/9JBU8R+U4V4H$IRDCF+TU*DU%TO5(*C*W)?V!7..<VH
MS<HL2]3^,GZ7E,K349-%.C(>=-)NKF5I")?@IX/XTH&,>AWEUUW]EW['K@UT
M5@=2C"J&6FS1<(1'JR&A1@+\+$!Z6R,@E+!*D9#7874Y,^`J`9>VK3Q)KP'`
MPH/7#CR/YL%"G'WF\7P:C9@7I,HII*_5H%:/?!7C"PJWKN?W:/G9VQ)-%MDH
M_&N*QBL8.'SVMJB"!L#)W4MW`9.>L;<*E<WO,7J;(:-L-D,*JLD3FJT]D(*?
MB`G=CY$ZB<1Z(WX#8/D0IP`\^C.;WBK&(NZ-BMNZ0=N%%/1PDH9E]:7?H8)`
M*QK0OY,""07\&]*+KPHT=$8W9B7&\X`B5+['3]"KL6\9E/%?MNS]HQ"R5]18
M@1LBJ$9U1%Q?B5O1[^I%[I>&-U)6V116(8"/371WD*F"54,-K6#&TZ32Y(CO
MZN!_Q3,QBUDL_+W&<9K-JO!QXBBJ*<&EGJM0A$I*+:P.#O!:E&JLNFKYFYA%
MZQ$%3_QX=(N&H?"#TT1W.DZN$_;HGSZSQ_%H#L<$L&'QKAQ:XR:?K.;K&C4K
M]_U56PE-_H-R37<AA-"`W>EJE+L%>N633UGY=<W*+0;J`@DS$!MM/G;W-XJU
MXG[Q9O(%D*O2^P?G[]\S2F`DCJ9XV/S'Y,LAV]8-$;'`HWV%\>B.4:;,[M".
M\0Y#6\>I\[N1<]%WJ&C>VNY&93:[4M3]K8!7'(;D+TUQ8(AF5P4FLO!0Z7W)
MM3ZM>KT(+2:W@`].JVOT4*O6VX&V!?E\%I4C6!N>HX086E!Q0;0!*Q97F7Q$
M6J\=92"=P!E#5NK[N$Z]:)F]11I%D]NN9-I887GY*R!(\04?RP:W2==YA)]A
MTEZPTB$6*7XKVP;1EX]Y6=#-B0&D[THI4*-7V*S0_:6Q2=2SIUDTCFZO%8'.
M4EZ_$7(FGL8SU:ITX(AOT]?1$[<(U`^ZTXMF(@@KG%Z,O7U['B^PSXME2O"X
MO&@VG2I/$M)7NJ<(%+%J!?\0#5%]!Y&E.-6`$LCK0]19'TV%`X8&N^J)=<51
MV)9^)`UTXZHGPE4$.(L9YYP`::N>Q'Y$TOSGKLO18X_&U<YC&U:WZI%LG4-9
MK4(.EZ`T74HVZ^2:E9LSO;%AU.E1IUA+S16CTEBJ46492@T1W]!D:)1VVPII
MJQ5=B9O_-.J66=\U!,;ZKN5%XS%2E?!SQDF>I?H3TXP\)<77(?Q3X4=((4W2
MN*!*@NPLO;?^6"2CMZI]CZ*8:T:^,BNC:8B5#(\NJQSNF*9%'"C1;/SH710:
M)S/*N0R.O\B/T/)K_J?-PA6/H/!7?>1U+^@-=BN"#]HQ!?'QA.E!X/13WG$4
M[EMG@*AIH]'\O33'CI$6;9N%BQS>CVDS>.3?U9!#EA3>*1(*E>*SZ!T>_2Z6
MVD%^%$Q%/%>V(!3UW)9(XWB:S&RI5N8XTN0(GUI85/9L+$6_`9&BBG2$YD.#
M.FII:TNRB[S/#G=(K2%M8TP]*+?JT.MV'L*:X1T>LS>Y?:!1\`W,:#E.(*0I
M=&MN*;S*!,LKJ*W%$V\-+5>@^BCA3M/$CQ*Q5,]3S`)K/Z6UG]+:3^EK\E,2
M$4L->:":@)B+*!)'JD*AF:2=X;1-X:4:/'-+L;!JG&6W<1T=!C)_6M1[R:^B
MU+%2@Y+8]J'!]:/MCJS>(<1-8SJB6M4F1&G@40*D3>C+@7\IL+C3:*FI>OQ`
M]^"MM;0WI+?AXEN38'9%#ND,>*P`5GI]K$!F_%P+\R,0IEZ,CM'EK\<U<F0C
MHK+M1JR`L=K]Q'+A1TUHI+#75=9)4QJHZ4M,+$X_>(=VI0;PO6F9OYODL\9C
MJNF@ZMC[4C.:W_8C]R)B;I%&CNAH+L[KX:":L8A4B)F$*Y3[0VBH&BWW&E`,
MDF`!`N^5ZKC.`M.N_L:KEIEBQZ'HHZS=OG,/8$D750`#>ZH&VS2$;45T,'U5
MV[ZZ..64&Q5S^$3<GE7_CD=E76DA*ZB+/QJ-XGDE?I,G\ZO\[4=$C_YG8[^)
MWA=E-'IK5Y+&\7@*^WA#4935+7U4Q!^C,GL%_3CU`,.US-XZ_`)\$IM:NSH.
M-B&<KFO:'@E755W#2(1%=!OS.U1`HYT$+D]'%16@>CY3W92Y/BF[64A9GN2^
M5V\BH2-"%=0D@1I"ZXT2Q28T7V(7!A#E7?5-WBQ59\.M'R`+89OR$E*[J76Z
MZ5(3YWDFSG[0CW0Q<TDN`AH:P'4/B_0*&V,Q!Q3*^I\XS[1=J=DK*OS5*)N_
M!S9=N#?U/;IG6U]9I:(Q7GWDW2_E5Y*.XW>KZ`GZO8.5T>DZ\V0B'-T3NR2I
MPWA4JV8)HR94:JH=V4]]94%_<(YF:ON"3R'5W46*6.+;V_T9N[)6<=M;RX:G
M0,U,%2Y.-=A5U=_=9#7U>.L(K"5JU#V935I]9DD553M%U`+7T`-%_YKN5,'L
MFT_+G#@VD#.X+<DU"9_&F)]<VU"X7?-5C5E&O2OC`XE<RD#6T)IA-N13&.4F
M^7OP>J*I<TWR[,J[,INXL2\&[/2"_6'4NW+W@L&>8Y_O?1),]U903Q'V8(L"
ML0"9UB,%55]_$((5AP#Z/@A&Q4Z_"D8A>6_'!WPOV!_40&:\1?&GC`M$6(_O
MY>:O^V^&Y+6JB\OSX]-G_?#QV<O?P\/S\[XUV^=H6Q&3R\:U$`\<B`>K(MYQ
M(-Y9%?&N`_'NJHCW'(CW5D6\[T"\ORKB`P?B`P]B;0#W#K9K#W?S0_/IP#]9
MT)SN>:<<$STB=J2Q0PT+;'?D\HON3+:@25`['C4PSE<HN[-"V=T5RNZM4'9_
MA;('?/V0JZ#1=1U'W_%EG8U=M,3U`#I@\8:`^U"O#V@>U(&PU$'`.Q"B79H'
M]0@L#!#P'H1HG^9!+(;G*`(^4-9D]).8#G#(.?J"(0T^Q[C&PL8YN#2*^J[\
M`<T?N/)W:/Z.*W^7YN^Z\O=H_IXK?Y_F[[OR#VC^`7UM$`V61?`CTY]P4G&7
MD$M'FL-_5^$7QLHXA=27H/=#AS-]\>`GQ#>"#8\Y_E;E51Y';X>R1%^64'>D
MK#QF+4?1=Z$85*$8<!0#%XJ=*A0[',6."\5N%8I=CF+7A6*O"L4>1['G0K%?
MA6*?H]AWH3BH0G'`41P`*#YTE%#1:GD12QAC"N[+,:0$%7;[%#K=#H;JJC@X
M>.37"G=VO``88G^_R;*IGFE(R4M35UHO5U@N5U@M5U@L5U@K5U@JFZV4M%\Z
M<'>Y=HUM+8UMK8QM+8SK=;'INJA(L#87R'_\]_8_ULOC_X7E45L<Z1#Z(%<O
M&=C-L2.\%^SU_&8-;!=IM.W3K8SK]>N+6;_L[EJO7^OU:[U^@2C6Z]='6K^4
M?5SP(.AIR]F^WP!I&#3W!TVL__M[WJ42`3SR+I3W@H/>;@7`P+]5!(RR!_O>
M-IC27/5RQ7Z)X:@'NATP6<4\$NU5@>+I-,3#G@"Z3@J$3=)"@P*@(;"-._SN
M)IF2`ZGB-<]Z$WQ#IWSPW7>!E:$X3J+O_GV>.51'#D_ZT*G!DWYU6R"#)O1I
MA?JU.%FK=A/QQV5M3S;6!]9OKPL&'ZL+#"2#6EU2BQJSHHZ'C,%GTF'>W$'=
M[F2RZ%&_D1U+[?1J$<*\B_V]51M-#>Z[V/_CCPJ:U8=[]92G==4<[5J9*GE3
MOVX3;SO\ZP5__14X<UN1)M73=P7V&CBJ9$E]6JKJ^5O8+QGB`VLD))",\!\B
M>VS=^!Y"FS.E>JJHIML&M0-S178&+J%*</Y;]@F0J,R$0F$O`?N1X?JG^G)B
M\`/?H7=Y('ZRP0*GB\7C]J9+\_EB\WRI"0.OO<KT6;5'M/75S!VTVE_,=V.[
M5[TY<$B?YN[L6+Z8P'$ZQAMZ/;D;R'NZ'!MNWY9$I@D$C.2?LHT;-.5!P$MC
M5O"26NMWO)LKSY@F]T7"WDB+^,D]$^*Y\C9MBK#,*\9D4VR$DXK;'Q.0"7F"
MEHP&]3E99EE!Z0'',#1&*A&]J"9CB&&$ZOCBJ,22H%2#X>-I$2N&%@V4H<1?
MY1P1E&C4X`^F"'^\:7I5@B*5*@9>&"8?&TMP/^C)W`\=_J]37:6CRK]E]XPJ
MU&YE%-3;-*OCJ+J\OL;+(53>1E,Z/@HYDG@R,)PTX6,.`]9)LKB^F=XD/=B]
M?U_AO^@G7':#HS4.WO$-DF1:)BD5%E%:AG-*)T&.QY#R2Y&)7*H8T7TH@5N2
M/"0F"G&?U,I%'QZ>%B_@%FEC#^:3,HQP557K*.[=OJ]W[0U\]7!IB/#3CA^B
M6X(Y_1I#BT]_B_P1G>Z\%TPAA;)U*443)%%0:E\78*.Y(<$DTJY//JDEW2--
M2B=#XL'\M818W=$W:#18:FESE783<\`VI,%O(?F,!C!CEBM_\-D-<+UW(9#!
MUS@'KO7AY[AN7SV.Z^%I>;@"XW1#<%E;:_\4VYMM3%Q$+@I%_6&]59BKXIJ[
M6W=#@4*:51=IZ`Y`;15'@/\D5Y"B;=*/YEY!0G=?;[\A=&X+_=#>$F%$O4I$
M/8JHIR&JJ8]$VUP7P7\UT4.B;9<.@G*Z@OQ^)?E]2GY?)=\T.:C(:6-I!5[$
M@S=*@\P-M8V14L$:Q8,^0)I5)<@P^.#0OR!Y`$UL\[/O1/M"50;^B"8XV-UV
MG:LZ=JVM157!-`SJGE7>"_K>VU!]<IUJSWV=BN#8V79&@L5A:/<JPM`:YXZ]
MW7U?`>"L$CR^[&][ZZV'ID8]^G6R24H>MM!ODI&`OU;6(S!O!5K4>\\I>U]#
M'TYS-'`0B!ZCN>+=.1Y5;C*-K@MY9Z_O:C;N\_Z^MPMIG^-K/X_\761REV30
M"W\Z;V4&OHID9SCZCKFH58,V^-@]*_P<P="\D]?AJ@V;S]=3W"4WS&^':0(L
M\79H0&:3";-HD$<VIK1'2(?@1!:/&J6/IED1CY-<AJ5FJ%CD]22/<<A\`IO'
MT1@`I3\HNFP>IQ1$6Q`D*01JBAO<-0<<OXU:<:M:LDPM9%;AK\&+Y4.`>Y<^
M7:C`[>V8]^,^HQ[:V_E,^P@3MFPO^>KP5T&[<&]'O#^)9CJ[-VS,7T4.XC07
M+8$B#Q41YXNMB76,.,]9S'<5+4'1=96E@\^L'*=:EZUQ(GWP71:2D+:DITQI
MJ8VKM3(0/>1J*=103+Q:KJJQO$%8RW:L;K2E?RPRY=58I,>`2XD5%7"I.BP,
M=I<TZ(<5.@'D)%II'\$7Z74E3--*R2M.UTFJO/.$9V8RZG3H9K;34:G"!O/P
M*H]&<5@LC#EWA;:N+$P`12$[$VV;D-S2P4$M!<O$49GE[RL,2D3[\8]QA<?+
M#7/!:<QG.5Z5MLWS>)*\PU>KH_=&XTB..,PA$$*_QTQ2L.#HE%$9C]F[%+%^
M<8SS1WF^U]]%';./:+_09EK]-61>QLK32&CHE#?<@4@M0$Q+K)0\5.JI_K;4
MSL`P(!2PL8?8A)A%:(L:HMBO#]HOS5ID(E$1X6WJGP8L_N[?)Z0,.V:R;F5B
MG$&[^T6LIW_HF'\Y3YFXC4VWL&TH+?OK+\;;GP)YGE#=L`]`PQX\J-FP#P#;
MQ7F:!@F9C10`FS\<M7:14N[',24?B$3>]THE-(C+#EW!A4B@4SM@\W8KH+//
M'L*L`*-)"`7EMW_R,T!MDM,9H<+R4";F?$#"BB>SF8U2R+%SP*+QX'?K^:]L
M.AYEB[0D7,5=P8@W;'AXE!`Z@/0-TKK@N^!_-S9ZP7_\!QI&?]$_>OR//O]C
MT$7PY*\]GK3#_]@5>?L\Z9'`M"TR>P)K3Z#M#<1?.^R0;%L7`&Q)2S,2.`D_
MU!AL($#4F'Z?,YR/D0<]9=Q@GGPCFLA;@28*'8:$*0]^8@JX\%'"I?0R/3ZY
M.$66T*M]WHB%"IG%Y(\JZYX8O@1:VO:T]*[@`::<D@.?-.(&J#.0#.\D+\J1
M.L4I)=&TQ"IY7@[U*2MGBBL#KQ:NO)Q=N.`?&^4X.23CW*0C2V-$R>N"A5%D
M#<?&W]X;;+/:8;MVG[5&HA2-JMU?HD+BE0I!4(8_"%1(IPE;`/DMV`*,&K`1
M1J.6X#]^#`Z(#=6(=D'YM<7#TDDK+$?)K=SZI73@ZD\W^!/]7P4>3W;O#=IZ
M?>C6J6NP>EW>['Y]4G8^.BG>[$%]2G<_-:7>[)WZ#=G[S!OBS=ZMW\[]+[N=
MWNR]^FPX^*K9X,W>YURRUHP?`B4J,I?A8I4WP94H6G)MP\LN6M;`O1I9;M1U
M%VL*M(!#4>#*@J[1"S4+TJZ)%LGU)4O5-C<1*F*\_#/253"^_R'9WP#[%G./
MH^!169#3*WJ]KKFYP5R@93Q<<'&B16Y0COCY@]4CU#:N"-V_CQ.[U,?0&@N0
MXKO;!;I7IT$JQ,1VS7?L;I!;R#4":A'5,A&T486F\`EC@.XY:=H%)/TZ:?3E
M3^I2:36MGK9'>>I4]7@_^'4\T3$>!8_"".U.=+!+K:M'?C#W$$\%Q`,&XZ0>
MY_MIQQ""<H[42;E0N0')B#"MJHX*%'!."TIH90VNG!:TSA7J=N6TH&%^%*I<
M.2THDG\SO:Z<%E3%SZ8EKIP6],`OH(VN'*'?25&K*7:*+)PK0-TN@)"L$*M*
M1P6)*Z\%"5FK%G=>"W)R90K<>2W(RX]*G3NO!<GYR2AWY[4@13_+5KGS6I"I
M7UR+W7E"QDIE7).Q:TUYK2FO->6UIORYM&2M*;>L*><DCKN0_L(6JMM[Q,UA
M:IMC)E6_9\Z&=1HNSK=[/=-Z9G]_24,;8.\S"62V1TPD-0#AO[[Y,1@XK(]V
M?;6,?/R3[H$N`Z2P9LHKX?KW`6K")K<B$^.L589Y<IA&1&:D->U\^'.8L><6
MQ=3NB`84-60;)]YH@=W&]U'","J*."_#292@-?9;`/;;+=\)\E:PN[V/9^G+
M\Z/+R]_#IZ].'U\>GYV&(>KE;>7P73#)-L6:=E54/S6(P@XSFM$5>P>970T-
MSBZ$:2`Q\?OGN$;N?D+MR:9+P<-_*%Z4S!U"%``,Y=*.3&Z$&50JCA[$O0,-
M=E85$EUDX/ROXP(?<X;!1F/-*8=GZ@9Q?C8R-/BOM!6T5%=Z82D(!!U:#9+.
M;[__=MB!B-RV^T'I696[O!F<LU85#[\==@SL8@[=OZ\Z%LE:=-\5(HC3^&YN
M(1*$/)!-O1?L[M>X$(/`'FW[P6AEN&+<%WP]D"HXN8L4!1N,''I@PTIM;LA@
M)"WY;=!J/I*[!FN#2]7'3%C[:!C'MFL?C?8I7?MHM+.=^$+:N?;1J,.&>CX:
M?'W0]B54<`M=B<%TB3<JO3TL=0.Y:*N+K;I&*VH33^1*$<)E:I)R6?D)K3(=
M4%G!9^#T<C_=]S`:N$^"\,/U>R1@@E@L@&U=KY2:+$6(E2HS33H^5&Z9@K\L
M5UM#HV:*K!)Y0E%E*_9`G#$>MP:GA[#=8(^_@U-WQ-V1J,T!T-$QB`8AO8RM
M,93X)6/=HXJ/QK=)'&NSB5"SK.ZU"/%XP+`^Z&FZ[80\%4YX&218T=&I'J*!
MGKC&#JGR=?+&KY.3#N8^[K;K".*+4:78KM38@[")8>Y!M#LG#*0G@Q;@^Q9Z
MZD-M\^+P>K[)9C&YKH2F98PD[RW:B#X_>W'TK;;14KM'EK!<]GF6(BFJ_6**
MQ6@4%X6YAV9[`548\8]Y9M-7UVE`L_<%:A2.%7+Q.#PY>W9\&IX>OC@*7QS^
MB_LA&15C=W16GD@2P#[`T?<M3R.^:7-O%.2+\`;IM+&4V^0N&GYCGLI!5B;X
MB7K[0R2SXI`=QDP1=T_G45'<C8E3/`1$>3F_<W'SV='ER]_"\_#B^+\H/R'S
M#&7$_*Z<S1$>"$(GAE0'@9$!$=T2[H)7*\!&$*EQ)_OS00_J4/PI[>QM]W<@
M$G@K_!W,$<$$B5BRJ)?G=ZA[92]_1TINB6JV!$TXSR--O[%6//Y!G<_9XKB@
M@JUY.^[*7!@)?WR.=?JG7):"O@^.'-%)FVCRN8HW[B88C?L"#QZ&CF(?W%;/
MN?-^B_HI4G?^X*?Y'?Z[VN]2KZE5.6S?*]H!2+=-=_33E`R@C=_^[[=#HRW6
MLF(O:7K]4F7EB$U3I+>%MFF)?TP"$JRZW8Y79(V":D.1P':?*^*6G*AG+/I.
M\F5%@Y&&R6\TTD#K&HYJGFX+IGH.N3GW*@ZY):J*LVX)*!HC.JBA'4SB6OG0
MV\#D!6CC"+Q9?14`;9R+MTQ0!4`;9^9_-\45`&T<JW]V3:H`:.,`_LMK<P5`
M&R?V7R%3*@"$/4VN-X!%C1=0P$"O6'717'5ML'%5@+2P/BQ19R5("ZO$QR&K
M$J2%U>*345X)TL*Z\3DWKA*DA37D"V]_)4@+*\K7SZ)*$/^)S7K'M-XQK7=,
MZQW3>L>TWC%])DSYF#LF96E4W!-`%VEI[+4MMFJ4NJI#;MJ(.!V'_,BN7B2L
MASP2UL,:D;#&W)&!0,M(6%JZ?LRMLGA1Q'DH'2-M`&GO-DSFLEV>(P>!'K6>
ML]7P;5[!>%YM"1=$/N#5VZ;PQBZ42D,\6A%0M5<]TK#Z%20-5*A(=H5-E245
M[ZKJDHVK`J0%E6F).BM!6E"</@Y9E2`M*%"?C/)*D!94J<^Y<94@+:A57WC[
M*T%:4+*^?A95@@BE"UK/`/5+*0V6@>YAV2ZBD/X`*6,JO*XW5/@?57AQ5?@=
M45[!'D>5OD9-O8QT;S'(N\CC553/407V)@+]B$2/0,Y$BBL1Z#%D>_8LXR4$
M^P?5\@QR^@39WD!>+R"%K1YNFJ4:NOM8CCYU7'RJG7L`?QFED(.%'YR.F#YR
M/JH?C!$B%Q5Q;$G8E4>.D$.MYE@CJM6N8_&O\9Y"$+5JD#6)R+^'D'"M!UM;
MFXS7)N.UR7AM,EZ;C-<FXR_99&QA%FOFJ@N#@<B7W\*RT*@V?WX+:T*KU/CS
M6U@/_E9J_?DM+`6?56O\^2TL`E]4:_WY+4C_KXH;_OR60N&M]S'K?<QZ'[/>
MQZSW,>M]S)>\C^$KHQ8<4`_,L9P+#&!+=MSE=+R6HH5AX[$-Z@978U9@Y9'J
MHA2&6/WIXX(\3.T(Q\9BQJF6:_P`H`GQR#ZX^B>"VI2Q%MA#S6/N>?,=>\IB
M&SAO(-H"TA?*[U&/S+)QC*,O!-N]_6WTD5(;V]L[Y(==+PG?]XZU;6,@#MU(
ME7L[M%)9Q=Y.G4JZ73C:'#ZN0H.@0;`)6=:(;*&U0XWPD<<LQ(=1H"(N)?XV
M!&U(LZ+:U4<+\J&FFT$[.!EO:OMYB5/4&EY!-3V"N-:(!Z;C6)?(3,BK;,2Z
MH+>%,:`A]B<_80F-$QF5IB&K`#]/7=(`.P(CC]M"RG>'A/,"S@Q+"2*(9T2Z
M\3QEH'.</&N(I".5B8C*\4)A;]<92\33A0W.M)3@H1*7=;8D1Y&:^L$]5U[?
MOZ\-*?A8[OY]Z]T@""./2<2>;%5@[,B:\E!=%](BK)#]HK?H%3-BT%ZWJ\3"
M9&C9$["HD`B[DL?728&P\;A`;CG]J&N>+.NO-6&LWV-1-$>K'CT%E>*)I@T!
M<"2`QB8X2X/`1].LB$UXG@@5(,N3"HP3(,"I!3G503_(%0X_>6L%M((EIA7Y
M!X=J$$M?(-^OK12X?\F.<`%SD+Y$W!MT7<]_BW!;V$.WT)YL94W4^YN-2O[B
MKQQ71N`EP5(Z+_2P2^8"ETW'XMVM>\&C7D7$3J6T*`F]X27!M-X2C[1S#6=+
M(Q9'@*I>^7B7*M&5982Q'2>[(<[#@<XXR23TLN[^(AZHAHO8KA^FT)11E_5>
MM_/AJ,S&(%"S/MAR7GL[OAFGOS/%LNQO4_.IP&0J3@_DT*E885IBEG/M$2*%
M#:@?V8@ZT-WCH8#-)@_P:.&1R1SQO^P=@AGLQ6P_4T/X9#&T$9[<A8)F,PT3
MK:2T^ZR'#ILJMP9E\.8#R+8W(?SSZ<CX:TE/QI^J*VO2L4$H/;]RC;^F"C;^
M()>NJF&//WAHX\\*RMYD>?"1I:K55`4P)0H8@4R\6F\KTT`0?/P1[:=Z$\H_
MYV:4;42_@3>B_$-;WF^6WY'R#]J9BEUI;0KJ;ECA*&O@ZL0_W[:-[U=X)Z%)
M46].6-]]35B!(W?Y#0C_7&'2ZLP;'<[]\@'^W',,?Q_`L5MO!RQ%M_.`1>.C
M=Z>LK0.>K;*$$R<LVLJRHO/;MP^_]9T7]2H.BDCQBC,B`B.([ZU*<<4)%YL-
M%737.=O2C[7X+'-1[YP<D*FTE5,NGT6YO;.M.K6X\]HXS%J5`G=>&P=7'Y,Z
M=UX;YU.?BG)W7ALG4)]CJ]QY;1PO?6DM=N>I$4"`4R./B"5Z&R\%.L.196AE
MF2N1N/+:D+EU:G'GM2%S5Z7`G=>&S/V8U+GSVI"YGXIR=UX;,O=S;)4[KPV9
M^Z6UV)TG9&YO.:^SM3J^5L?7ZOA:'?^"6K56Q_]V=1RM-5OD32"@-F'A6E4$
M&XA\^2V(XD:U^?-;$,NM4N//;T%,_ZW4^O-;$-V?56O\^2V(]"^JM?[\%L3]
M5\4-?[Y8#O1#CF4V#>M3A_4V9[W-66]S/A/U>+W-66]SUJ<.ZU.']:E#NY2O
M3QUDWOK40<U;GSJLU?&U.KY6Q]?J^%H=_WCJN'+J(*\N:=8K];8EX!?LO:\H
M@3@--=SZO?=PW>%@W7<C[:"@_`Y#>Q<QA)NT=GNYY@T,\=E7,<"[&+(%58]#
M6[<V`L?%&6\(@*;7E^!WG8'K23`B#"AHX'5K=_J@FWG0)4KX6AX;Y'AT;+FN
MS-6^K"C!Q_0]XY^,JZQZUUDWUSQ7/-GW>5U86_9"&OVW`\:3D#>*&:/HG6'Z
MHU$X")HG+@;QBVOT?E#E73#]RE"MVSKP'1VSQY(WOM@1*T2.L&[G.&KF(23<
M==>^H>,:).P^E'X7RB8';R>,\-M4UB'!A`JZQ#!IB'WSADG#BMLU]KV:ZILR
MKCLR>ECQ>GLQ<M!"(C@X]EDU3FOTPQK.7UY0;K?P:T%RM_4=8LYK#/D@Z*^T
MBY+[:A)E8M7MDF>;+G?IC6IR;8MJU>3(ZC<EPK7[694(1]:@*7VN/<Y'I,^1
MM=.4=-=&YM.0[LC:;=HJUV;ELVN5(VM/;[`IEDC4&5Z$QWXQ9!+9@5@%^<-G
M<`%++[97"ZKJZ@\>T'^9#F)&-NEW337DCR++2[FN@(H8VUCIBT3EG?H'0C,Q
M2AKJ_U8PRJ;3J(S':#V9S:,\%BIR1XWT0F-L=3"A'7-IZ[#EC,5C8;%:J,XR
M[/S9@:]W0QL+OHR:L5UHJGD;VU30;>7*9*?!I/L!ZD7W!H>V471.#61BS/B+
M"A83KF+=*AGAIG;,O@@VHJV`,UA=K8-H""0R;JOSB/Y=]!#7-C?LC$T*W*7X
M@(+]JH)70S[<<25(+^M3<M4@03+7XK2J!!&PO@_L`8$3&Z0<\PNCWL+5BD&J
M<A3>#07D]U:0:JRE[6,PG+]T]T[@61)30U/*;#%463(9K?+F/AP%:RBM'<J^
M#NM>S,"-H7C,K8?_X+'P!#[$U7M!K[?[J#+DC#EG4F66B'!XE-IX6NK4DD8S
MA5IHJ:HJ;47M8@32J&H4G[;?]2G2J@K-7A%*]*TN,+$HB0\>*%//'%7TDU?.
M93V4^C@=:R^X-`_$YH2H//T8+Q6IC0Z1BNB^P((Z5J*YM?!,HTM]D-GM/<]8
MIRYO=GM/,K9`BC>[O2<8/SZEWNSVGEO\Y`WQ9K?WK.+GWDYO=GM/)W[A;/!F
MJP<K8$A>Q7X\EB].\R6+K%;W[P=$+9#)]=8LN9Z['R"F:[9WT=+4`L^J)>'D
M<\-4Q7`M6[AQ`/<$HE47+@.1+[^%I:M1;?[\%E:O5JGQY[>P@OVMU/KS6UC&
M/JO6^/-;6,R^J-;Z\UM8T[XJ;OCSY;._;!71UC8JW#FX`)*KVP?5`0#<YRF[
M/)Z@&N%@DU4'FP'L^,/LSZW@CT56QH`=@`&P"K$ABD`:NWZM!#%BX%/D.=^E
M\QTXWF%RA`@0&YU(('WLW$#K+NZ2<G03;&S.N\9&=105<?"/?_[C!^WWIOBM
MA1M70?[[OQ48O/TF#<#K\!RO;XP&=7^-J)%*!7OW5D/Y6L'(6MGSEWACT(!+
M=;U;=>V]7;M/\41$/\*P?#\GEDRS;[N!T==AB/[,DZM%&9/)>X?PHY$X3:(B
MV/C6+/ZM[H^B&I.T`W\Q@-"O>%1F^7O7B7_5V#*L3Q29,NZ8EXGXO;')*D#3
M3RV[A7/Y#`&LL,Q*6)2(P3/;U86==V/X:9*^U4U$>AXV`+TK#9.0,)I]`+#1
M_`*HE5G3)MDB'?,)-(O+B/^-GSDF8PHGDK>3G5,9"B7.#8NT-'_CP(ALO=/]
MBSD*]*#HXT:,VQTAA2C5=*K3T4K]2JP:51N6>>*/J"2/1]32X?&DINHY_0L(
MRA^&>72'CT)NU%%*P>F1AYW1[9IV.<D$;034<I)@6;1G447&B3VM63#18RRE
M4Z&K#[3)8CIE#XUXGEW63)&,!O;L,L-6C^&<6O>>24'NW3<)3/YMDP`3NR99
MP?_)0)-L$/@]S6LYFG-,U>[F'+*NP96/28=')4/7AJ.YALH/T9+3>:,:JR!:
M<D-OF:8JB);<T_]VJJL@6G)>_PS;5071DH/[%]GR*HB67.&_4MY40?@MO'*A
M4+8-PM`+X5Y?7EU?7EU?7K7RUI=7UY=75[R\NMY8K#<6GUQI66\LOJQVK3<6
MZXW%E[BQ\`7_Y";'59<1'8\GNX4%I$%=WNP6UHWV2/%FM[!6_&V4>K-;6!P^
MEX9XLUM8"KZ0=GJS6Y#Z7P<;O-E"NJO'2?]GPGJNMV+KK=@G5_/66[$OJUWK
MK=AZ*_8E;L5\9MGU&<_ZC,=)W?J,9WW&LS[C69_QK#<6ZXW%YZ!JK3<6ZXW%
M>F/Q^6PLE#,>X=ZOF!.[:MP1?A^G(O[@/P,@^*"D`X<<5,$QN6JP0`UR;X=>
M,]CN=F302N!N1<7E"NUB"HGR0]O*XZ5H=YK^[*CQ,<4=%.MV"G2%@(=*,H#U
MR%`$Y8.?S`L)/")*3P,F,5#4`IZ@@M=9F>&(5JB3PSC/L]Q1*VDVO4T&`*`Y
MZ`YJ*SBLQ2!D]VRVU>`I]+]:V%8U7HMRI:@BFB7[]&&%[X2-<8QWY<X'6.R'
M0-P(#'DIM9#%;$Z8A\]FZ$8R*39#S/,T"_%(*)$("S;0V/WFQZ!O![AD(2[9
MG2PCGA3)4^YK*1,7KL3!L(!<$=*9NPU"L\MR1@1,>SK)S^YP_#6*UTNNJ:4S
M$1AYPPI^MM\E`2I9(#34D]NNALH66\-I3T'28TC`F-'69\7?=+/#D$@'4B+Q
MCX4G`H(OVW%`]>M]2F0I[9.A3<%<*H#PV$%\WD14@TVN._DP"PV472W&+)HS
M8SH?Z?QQX<'2GL&BRI\<G^.)R8M`#2'!KBI"J=)/NP1JHO@&87GPTSA,THS&
M3H9Q(,8C<;Z(AX[`XF2F&X&"!\[YA_=QN%)\[137^N0R?'7ZR^G9;Z=0%F)&
M-5%V+EM&"#8Z5AQTH\D6D?O"8J%G,:?Y).0K+40#-$KQ!]SRO(-72^>46W(5
M53_U%N#&QKC+>>$L@*AT+\#RWA]<F(4EJ[$@JQ^P.#M@-S<:1A:K""M6::NH
M$U#,B";F,TZ(!5<P"=!A6PDKY@O]TUY`L5JUN/-:,$&L3($[KP53PT>ESIW7
M@C'ADU'NSFO!4/!9MLJ=U\+V_XMKL3M/;.>!1WH!N4K_I;MY]]K#-WMNS9>B
MI%L_LA%TKIQL/VS$,5:_^_=E:`;[^V"EZBG.]QFX^FT%9&!6@"X8HM0?2,#>
MSK:\WZ_<5%<8`TQ=I*XYP*UM--8NJL,95"H82\<Q\$8LE6SPNLFM'937#LIK
M!^6U@W+#=GJSUP[*C1R4@;"EJO`6!@FFQUCZBJD#R->O^&IOA,L7ZV`+KZEM
M5+Z<<)_K$=6OJ]F/J:DKN_4R6N/5G82.&S(M1K<K#Z7N)I42B;/RK0*##??O
MOU%0*4;*IHBL)_0L/,;;>6)$X#A?N#!H%1?/`U![ON_M"/OU+]4.JIHY1].L
MB#4[)V^U9N\.!:!EY)0'4XX3`ZQZHG91/C#+O*KZ_C,88"LVSE9'``Z91]O#
M(Z!Y.>-O=)TF*PVN;&YE4RE'F)$<&KQVAZE:L.M!#B,DI%*D:^K[RIR0720C
.#:+Q]O\!-6U&P&H/`P!E
`
end

Re: abort in eliminate_regs compiling glob.c from glibc

[Alan Modra]

On Thu, 9 Nov 2000, John David Anglin wrote:

> > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0)
> >     at ../../gcc/reload1.c:2826
> > 2826      if (! insn_is_asm && icode < 0)
> > (gdb) p debug_rtx (insn)
> > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6)
> >         (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil)))))
> >     (expr_list:REG_DEAD (reg:SI 28 %r28)
> >         (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0))
> >                     (expr_list (symbol_ref/v:SI ("@strlen"))
> >                         (expr_list (reg/v:SI 4 %r4)
> >                             (nil))))
> >                 (nil)))))
> 
> The `use' arises from the `__pure__' attribute in the prototype for strlen:
> 
> extern size_t strlen (__const char *__s) __attribute__ ((__pure__));

I don't see this problem using current puffin CVS hppa64-linux gcc.  Was
this with your REG_ELIMINATE patch?

Alan Modra
-- 
Linuxcare.  Support for the Revolution.

Re: abort in eliminate_regs compiling glob.c from glibc

[John David Anglin]

> > > 2826      if (! insn_is_asm && icode < 0)
> > > (gdb) p debug_rtx (insn)
> > > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6)
> > >         (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil)))))
> > >     (expr_list:REG_DEAD (reg:SI 28 %r28)
> > >         (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0))
> > >                     (expr_list (symbol_ref/v:SI ("@strlen"))
> > >                         (expr_list (reg/v:SI 4 %r4)
> > >                             (nil))))
> > >                 (nil)))))
> > 
> > The `use' arises from the `__pure__' attribute in the prototype for strlen:
> > 
> > extern size_t strlen (__const char *__s) __attribute__ ((__pure__));
> 
> I don't see this problem using current puffin CVS hppa64-linux gcc.  Was
> this with your REG_ELIMINATE patch?

No.  Well actually I saw it first with the patch.  I see this with the
32 bit compiler.  The only elimination with the 32 bit compiler is the
default frame pointer elimination.

I just tried the hppa64-linux-gcc compiler with the source that I posted
and it didn't abort.  There were lots of warnings about int to pointer
conversions though.

Make sure you compile with -O2 or -O3?  Register elimination only occurs
at -O2 or above.  I see the problem both with a i686-linux cross compiler
and a fairly recent native hpux compiler under hpux 10.20.  The problem is
not present in 2.95.2 but it doesn't support the pure atribute.

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

Re: abort in eliminate_regs compiling glob.c from glibc

[John David Anglin]

> > Breakpoint 2, eliminate_regs_in_insn (insn=0x406a0ba0, replace=0)
> >     at ../../gcc/reload1.c:2826
> > 2826      if (! insn_is_asm && icode < 0)
> > (gdb) p debug_rtx (insn)
> > (insn/s 2711 2709 2719 (set (reg:SI 6 %r6)
> >         (reg:SI 28 %r28)) 69 {pre_ldw-4} (insn_list 2708 (insn_list:REG_DEP_ANTI 2696 (insn_list:REG_DEP_ANTI 2702 (insn_list:REG_DEP_ANTI 2697 (nil)))))
> >     (expr_list:REG_DEAD (reg:SI 28 %r28)
> >         (insn_list:REG_RETVAL 2708 (expr_list:REG_EQUAL (expr_list (use (mem:BLK (scratch) 0))
> >                     (expr_list (symbol_ref/v:SI ("@strlen"))
> >                         (expr_list (reg/v:SI 4 %r4)
> >                             (nil))))
> >                 (nil)))))
> 
> The `use' arises from the `__pure__' attribute in the prototype for strlen:
> 
> extern size_t strlen (__const char *__s) __attribute__ ((__pure__));

Here is a patch to fix the abort in eliminate_regs when it encounters a USE.
As I understand the situation, there are three conditions needed to trigger
it:

1)	A function that contains insns with an eliminable register.
2)	The function must call __builtin_alloca to change the frame size
	from its initial size.
3)	After the call to __builtin_alloca, there must be a call to a
	pure function.

With the enclosed patch, I can now build glibc for hppa-linux with -O3
optimisation.

Please review carefully because I will be the first to admit that I don't
understand why the use is there in the first place and all the details of
what eliminate_reg does.

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

2000-11-14  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* reload1.c (eliminate_regs): Don't abort on MEM USEs.

--- reload1.c.orig	Wed Sep 27 14:27:23 2000
+++ reload1.c	Tue Nov 14 16:01:56 2000
@@ -2499,6 +2499,10 @@
 	return x;
 
     case USE:
+      /* Handle insn_list USE that a call to a pure functions may generate. */
+      new = eliminate_regs (XEXP (x, 0), 0, insn);
+      if (GET_CODE (new) == MEM)
+	return XEXP (new, 0);
     case CLOBBER:
     case ASM_OPERANDS:
     case SET:

Re: testcase for hppa64 gcc bug

[Jeffrey A Law]

  In message <200011091739.MAA07483@hiauly1.hia.nrc.ca>you write:
  > For the record, here is my final patch regarding making the arg_pointer
  > eliminable for TARGET_64BIT.  I think the code it generates is correct but
  > it hasn't been extensively tested.  However, I don't recommend it for
  > installation since in comparing the assembler code generated with and
  > without elimination for a couple of test cases, I didn't observe any
  > significant improvement in the code with the patch.  Possibly, the patch
  > implicitly disables elimination when the arg_pointer is needed.
  > 
  > I do find that Alan Modra's ARG_POINTER_INVARIANT patch needs to be install
  > ed
  > to get correct code with his test case.
  > 
  > There is one part of the patch below which I think needs to be installed.
  > That is
  > 
  > 	(call, call_value): Always USE the arg_pointer for TARGET_64BIT.
  > 
  > The use for the arg_pointer needs to be pulled out of the `if (flag_pic)'.
  > 
  > Dave
  > -- 
  > J. David Anglin                                  dave.anglin@nrc.ca
  > National Research Council of Canada              (613) 990-0752 (FAX: 952-6
  > 605)
  > 
  > 2000-11-07  John David Anglin  <dave@hiauly1.hia.nrc.ca>
  > 
  > 	* pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the
  > 	arg_pointer is being eliminated.
  > 	(ELIMINABLE_REGS): Enable elimination of the arg_pointer.
  > 	(INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer.
  > 	* pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and
  > 	canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside
  > 	unspec to prevent elimination.
  > 	(call, call_value): Always USE the arg_pointer for TARGET_64BIT.
  > 	Use the new addmovdi3 insn to load the arg_pointer register.
  > 	(addmovdi3 and mov_from_r29_si): New insn and expand which prevent
  > 	r29 from being eliminated in call setups and millicode returns.
I haven't followed this discussion too closely.  Is this patch still needed
after some of the recent changes in how we compute liveness for the argument
pointer?
jeff

Re: testcase for hppa64 gcc bug

[John David Anglin]

>   > 2000-11-07  John David Anglin  <dave@hiauly1.hia.nrc.ca>
>   > 
>   > 	* pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the
>   > 	arg_pointer is being eliminated.
>   > 	(ELIMINABLE_REGS): Enable elimination of the arg_pointer.
>   > 	(INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer.
>   > 	* pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and
>   > 	canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside
>   > 	unspec to prevent elimination.
>   > 	(call, call_value): Always USE the arg_pointer for TARGET_64BIT.
>   > 	Use the new addmovdi3 insn to load the arg_pointer register.
>   > 	(addmovdi3 and mov_from_r29_si): New insn and expand which prevent
>   > 	r29 from being eliminated in call setups and millicode returns.
> I haven't followed this discussion too closely.  Is this patch still needed
> after some of the recent changes in how we compute liveness for the argument
> pointer?

I think this needs to be reexamined.  Allan's ARG_POINTER_INVARIANT patch
might not be needed now.

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

Re: testcase for hppa64 gcc bug

[Alan Modra]

On Tue, 5 Dec 2000, John David Anglin wrote:

> >   > 2000-11-07  John David Anglin  <dave@hiauly1.hia.nrc.ca>
> >   > 
> >   > 	* pa-linux64.h (ARG_POINTER_INVARIANT): Define even when the
> >   > 	arg_pointer is being eliminated.
> >   > 	(ELIMINABLE_REGS): Enable elimination of the arg_pointer.
> >   > 	(INITIAL_ELIMINATION_OFFSET): Revise offsets for arg_pointer.
> >   > 	* pa.md (mulsi3, divsi3, udivsi3, modsi3, umodsi3 and
> >   > 	canonicalize_funcptr_for_compare): Put "(reg:SI 26)" inside
> >   > 	unspec to prevent elimination.
> >   > 	(call, call_value): Always USE the arg_pointer for TARGET_64BIT.
> >   > 	Use the new addmovdi3 insn to load the arg_pointer register.
> >   > 	(addmovdi3 and mov_from_r29_si): New insn and expand which prevent
> >   > 	r29 from being eliminated in call setups and millicode returns.
> > I haven't followed this discussion too closely.  Is this patch still needed
> > after some of the recent changes in how we compute liveness for the argument
> > pointer?
> 
> I think this needs to be reexamined.  Allan's ARG_POINTER_INVARIANT patch
> might not be needed now.

It's still needed.  The problem is that gcc thinks the arg pointer is
unchanged from the entry value to a function, even when the arg pointer
needs to be set to call other functions.

Actually, given the nature of the problem, I'm inclined to think that all
targets that use an arg pointer should probably define
ARG_POINTER_INVARIANT = 0.  Or equivalently, don't apply my
ARG_POINTER_INVARIANT patch and simply remove tests for arg_pointer_rtx in
rtx_unstable_p, rtx_varies_p, rtx_addr_can_trap_p, function_invariant_p,
loop_invariant_p, and possibly other places I've missed.

Here's the testcase again:

extern void abort(void);

char p;

int f1 (char **);
int f2 (char *, char **);

char *f3 (char *a, char *b)
{
  char *c = 0;

  if (f1 (&b) != 0)
    goto out;

  /* hppa64 passes bogus value for b */
  f2 (b, &c);

out:
  return c;
}

int f1 (char **x)
{
  if (*x != &p)
    abort ();
  return 0;
}

int f2 (char *a, char **b)
{
  if (a != &p)
    abort ();
  *b += 1;
  return 0;
}

int main (void)
{
  if (f3 (0, &p) != (char *) 0 + 1)
    abort ();
  return 0;
}

Results of compiling with -O2 -S for hppa64-hpux11-gcc built from CVS
of less that an hour ago.

	.LEVEL 2.0w
gcc2_compiled.:
	.IMPORT f1,ENTRY
	.IMPORT f2,ENTRY
	.text
	.align 8
	.EXPORT f3,ENTRY
f3
	.PROC
	.CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=3
	.ENTRY
	std %r2,-16(%r30)
	ldo -56(%r29),%r26	! r26 = &b = r29 - 56
	ldo 128(%r30),%r30
	std %r4,-104(%r30)
	copy %r27,%r4
	std %r25,-56(%r29)
	ldo -16(%r30),%r29
	b,l f1,%r2
	std %r0,-120(%r30)
	ldo -16(%r30),%r29	! arg pointer set to current frame
	ldo -120(%r30),%r25
	cmpib,= 0,%r28,L$0005
	copy %r4,%r27
L$0004
	ldd -120(%r30),%r28
L$0006
	ldd -144(%r30),%r2
	ldd -104(%r30),%r4
	bve (%r2)
	ldo -128(%r30),%r30
L$0005
	ldo -64(%r29),%r29	! r29 = curr_r30 - 16 - 64
	b,l f2,%r2
	ldd 8(%r29),%r26	! try to load b from r29 - 56, but
				! gcc misses fact that r29 has changed
	b L$0006
	ldd -120(%r30),%r28
	.EXIT
	.PROCEND
[snip]

-- 
Linuxcare.  Support for the Revolution.

Re: pa reload problem

[John David Anglin]

> I was going to deleting the hack and adding a general_operand test in
> local-alloc to see if that would fix the reload problem with "-fPIC".
> However, for the moment, there are still problems with a "normal" build
> at "-O3".  With only the yesterdays CVS source and the patch below
> to prevent rename registers walking of the return pointer, I get the
> following failure building libstdc++ v2:
> 
> /xxx/gnu/gcc-2.97/objdir/gcc/g++ -B/xxx/gnu/gcc-2.97/objdir/gcc/ -nostdinc++ -isystem /xxx/gnu/gcc-2.97/libstdc++ -isystem /xxx/gnu/gcc-2.97/libstdc++/std -isystem /xxx/gnu/gcc-2.97/libstdc++/stl -isystem /xxx/gnu/gcc-2.97/libio -isystem /xxx/gnu/gcc-2.97/objdir/hppa1.1-hp-hpux10.20/libio -L/xxx/gnu/gcc-2.97/objdir/hppa1.1-hp-hpux10.20/libstdc++ -B/usr/local/hppa1.1-hp-hpux10.20/bin/ -B/usr/local/hppa1.1-hp-hpux10.20/lib/ -isystem /usr/local/hppa1.1-hp-hpux10.20/include -c -O3 -fno-implicit-templates -I../../../libstdc++ -I../../../libstdc++/stl -I../libio -I../../../libstdc++/../libio -I../../../libstdc++/../include -I../../../libstdc++/../gcc -nostdinc++  ../../../libstdc++/exception.cc
> ../../../libstdc++/exception.cc: In function `void __check_eh_spec(int, const 
>    void**)':
> ../../../libstdc++/exception.cc:363: Internal error: Segmentation fault.

I have made some progress in locating this bug but still don't have a
complete understanding of the problem.  The problem is that a code_label
insn is "incorrectly" deleted in the loop pass.  Here is the rtl from
the gcse pass:

[snip]

(code_label 1158 1268 1439 124 "" "" [3 uses])

(note 1439 1158 262 [bb 12] NOTE_INSN_BASIC_BLOCK -1347440721)

(note 262 1439 1159 85 NOTE_INSN_EH_REGION_END -1347440721)

[snip]

(insn 788 787 789 (set (reg/f:SI 209)
        (high:SI (label_ref:SI 1158))) 87 {*pa.md:2435} (nil)
    (expr_list:REG_EQUAL (high:SI (label_ref:SI 1158))
        (insn_list:REG_LABEL 1158 (nil))))

(insn 789 788 791 (set (reg/f:SI 208)
        (lo_sum:SI (reg/f:SI 209)
            (label_ref:SI 1158))) 90 {*pa.md:2467} (nil)
    (insn_list:REG_LABEL 1158 (expr_list:REG_EQUAL (label_ref:SI 1158)
            (nil))))

Here is the rtl after loop:

Loop from 576 to 1288: 105 real insns.
Continue at insn 1278.

[snip]

Insn 788: regno 209 (life 2), move-insn savings 2  moved to 1530
Insn 789: regno 208 (life 1), move-insn forces 788 savings 1  moved to 1532

[snip]

(insn 1531 1528 1532 (set (reg/f:SI 337)
        (high:SI (label_ref:SI 1158))) -1 (nil)
    (expr_list:REG_LABEL (code_label/v 1158 1268 1439 124 "" "" [0 uses])
        (nil)))

(insn 1532 1531 1535 (set (reg/f:SI 208)
        (lo_sum:SI (reg/f:SI 337)
            (label_ref:SI 1158))) -1 (nil)
    (expr_list:REG_EQUAL (label_ref:SI 1158)
        (expr_list:REG_LABEL (code_label/v 1158 1268 1439 124 "" "" [0 uses])
            (nil))))

The code_label 1158 is deleted by delete_trivially_dead_insns apparently 
because the preceding call to loop_optimize in toplev.c has reduced the
number of uses to 1.  Maybe somebody can see how this occurs.

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

Re: pa reload problem

[Jeffrey A Law]

  In message <200012140048.TAA02603@hiauly1.hia.nrc.ca>you write:
  > I have made some progress in locating this bug but still don't have a
  > complete understanding of the problem.  The problem is that a code_label
  > insn is "incorrectly" deleted in the loop pass.  Here is the rtl from
  > the gcse pass:
  > 
  > [snip]
  > 
  > (code_label 1158 1268 1439 124 "" "" [3 uses])
  > 
  > (note 1439 1158 262 [bb 12] NOTE_INSN_BASIC_BLOCK -1347440721)
  > 
  > (note 262 1439 1159 85 NOTE_INSN_EH_REGION_END -1347440721)
  > 
  > [snip]
  > 
  > (insn 788 787 789 (set (reg/f:SI 209)
  >         (high:SI (label_ref:SI 1158))) 87 {*pa.md:2435} (nil)
  >     (expr_list:REG_EQUAL (high:SI (label_ref:SI 1158))
  >         (insn_list:REG_LABEL 1158 (nil))))
  > 
  > (insn 789 788 791 (set (reg/f:SI 208)
  >         (lo_sum:SI (reg/f:SI 209)
  >             (label_ref:SI 1158))) 90 {*pa.md:2467} (nil)
  >     (insn_list:REG_LABEL 1158 (expr_list:REG_EQUAL (label_ref:SI 1158)
  >             (nil))))
  > 
  > Here is the rtl after loop:
  > 
  > Loop from 576 to 1288: 105 real insns.
  > Continue at insn 1278.
  > 
  > [snip]
  > 
  > Insn 788: regno 209 (life 2), move-insn savings 2  moved to 1530
  > Insn 789: regno 208 (life 1), move-insn forces 788 savings 1  moved to 1532
  > 
  > [snip]
  > 
  > (insn 1531 1528 1532 (set (reg/f:SI 337)
  >         (high:SI (label_ref:SI 1158))) -1 (nil)
  >     (expr_list:REG_LABEL (code_label/v 1158 1268 1439 124 "" "" [0 uses])
  >         (nil)))
  > 
  > (insn 1532 1531 1535 (set (reg/f:SI 208)
  >         (lo_sum:SI (reg/f:SI 337)
  >             (label_ref:SI 1158))) -1 (nil)
  >     (expr_list:REG_EQUAL (label_ref:SI 1158)
  >         (expr_list:REG_LABEL (code_label/v 1158 1268 1439 124 "" "" [0 uses
  > ])
  >             (nil))))
  > 
  > The code_label 1158 is deleted by delete_trivially_dead_insns apparently 
  > because the preceding call to loop_optimize in toplev.c has reduced the
  > number of uses to 1.  Maybe somebody can see how this occurs.
Seems to me we have a reference counting problem.  There is clearly 
a reference to label 1158 (insn 1531/1532), but it's reference count
is zero.

Seems to me that if you find that reference counting bug that you'll
fix this problem.

jeff

Re: pa reload problem

[John David Anglin]

>   In message <200012140048.TAA02603@hiauly1.hia.nrc.ca>you write:
>   > I have made some progress in locating this bug but still don't have a
>   > complete understanding of the problem.  The problem is that a code_label
>   > insn is "incorrectly" deleted in the loop pass.  Here is the rtl from
>   > the gcse pass:
>   > 
>   > [snip]
>   > 
>   > (code_label 1158 1268 1439 124 "" "" [3 uses])
>   > 
>   > (note 1439 1158 262 [bb 12] NOTE_INSN_BASIC_BLOCK -1347440721)
>   > 
>   > (note 262 1439 1159 85 NOTE_INSN_EH_REGION_END -1347440721)
>   > 
>   > [snip]
>   > 
>   > (insn 788 787 789 (set (reg/f:SI 209)
>   >         (high:SI (label_ref:SI 1158))) 87 {*pa.md:2435} (nil)
>   >     (expr_list:REG_EQUAL (high:SI (label_ref:SI 1158))
>   >         (insn_list:REG_LABEL 1158 (nil))))
>   > 
>   > (insn 789 788 791 (set (reg/f:SI 208)
>   >         (lo_sum:SI (reg/f:SI 209)
>   >             (label_ref:SI 1158))) 90 {*pa.md:2467} (nil)
>   >     (insn_list:REG_LABEL 1158 (expr_list:REG_EQUAL (label_ref:SI 1158)
>   >             (nil))))
>   > 
>   > Here is the rtl after loop:
>   > 
>   > Loop from 576 to 1288: 105 real insns.
>   > Continue at insn 1278.
>   > 
>   > [snip]
>   > 
>   > Insn 788: regno 209 (life 2), move-insn savings 2  moved to 1530
>   > Insn 789: regno 208 (life 1), move-insn forces 788 savings 1  moved to 1532
>   > 
>   > [snip]
>   > 
>   > (insn 1531 1528 1532 (set (reg/f:SI 337)
>   >         (high:SI (label_ref:SI 1158))) -1 (nil)
>   >     (expr_list:REG_LABEL (code_label/v 1158 1268 1439 124 "" "" [0 uses])
>   >         (nil)))
>   > 
>   > (insn 1532 1531 1535 (set (reg/f:SI 208)
>   >         (lo_sum:SI (reg/f:SI 337)
>   >             (label_ref:SI 1158))) -1 (nil)
>   >     (expr_list:REG_EQUAL (label_ref:SI 1158)
>   >         (expr_list:REG_LABEL (code_label/v 1158 1268 1439 124 "" "" [0 uses
>   > ])
>   >             (nil))))
>   > 
>   > The code_label 1158 is deleted by delete_trivially_dead_insns apparently 
>   > because the preceding call to loop_optimize in toplev.c has reduced the
>   > number of uses to 1.  Maybe somebody can see how this occurs.
> Seems to me we have a reference counting problem.  There is clearly 
> a reference to label 1158 (insn 1531/1532), but it's reference count
> is zero.

That's what I thought.  It would appear to occur when the above two insns
get moved out of a loop.  The count gets decremented when the old insns
are deleted but not incremented when the new insns are created.  The puzzle
is why the count is zero rather than 1.  Maybe what happens is the two
insns in the loop are deleted first, then the label is deleted?  Notice
that insn 788 is moved to insn 1530.  However, the insn becomes 1531 and
the reg changes to 337 from 208.

I will try to step through the code later.

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

[parisc-linux] PATCH: Adjust label usage count for new insns [was Re: pa reload problem]

[John David Anglin]

>   > Here is the rtl after loop:

>   > (insn 1531 1528 1532 (set (reg/f:SI 337)
>   >         (high:SI (label_ref:SI 1158))) -1 (nil)
>   >     (expr_list:REG_LABEL (code_label/v 1158 1268 1439 124 "" "" [0 uses])
>   >         (nil)))
>   > 
>   > (insn 1532 1531 1535 (set (reg/f:SI 208)
>   >         (lo_sum:SI (reg/f:SI 337)
>   >             (label_ref:SI 1158))) -1 (nil)
>   >     (expr_list:REG_EQUAL (label_ref:SI 1158)
>   >         (expr_list:REG_LABEL (code_label/v 1158 1268 1439 124 "" "" [0 uses
>   > ])
>   >             (nil))))
>   > 
>   > The code_label 1158 is deleted by delete_trivially_dead_insns apparently 
>   > because the preceding call to loop_optimize in toplev.c has reduced the
>   > number of uses to 1.  Maybe somebody can see how this occurs.
> Seems to me we have a reference counting problem.  There is clearly 
> a reference to label 1158 (insn 1531/1532), but it's reference count
> is zero.

These insns result from "moving" insns with label_ref's out of a loop.  The
old insns are deleted by delete_insn which reduces the LABEL_NUSES count.
However, the LABEL_NUSES count is not incremented when the new insns
are created.  This leaves the number of uses of the label at 1 and
delete_trivially_dead_insns deletes the code_label after loop_optimize
completes.

The simplest solution is to modify add_label_notes to increment the usage
count for CODE_LABEL's.  As far as I can tell, add_label_notes is only
used in loop.c when a new insn is created and an old one deleted.  An
alternative solution might be to actually move the old insn in the list
rather than deleting it.

There appears to be a similar situation in gcse.c.

I have run a complete bootstrap and check at -O3 under hpux 10.20 with this
patch and the patch previously posted at
<http://gcc.gnu.org/ml/gcc-bugs/2000-12/msg00156.html>.  It fixes register
rename walking over the return pointer.  The test results are here
<http://gcc.gnu.org/ml/gcc-testresults/2000-12/msg00172.html>.  I have also
run a complete bootstrap and check under i686 linux.

Please review and install if OK.

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

2000-12-14  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* loop.c (add_label_notes): Increment the label usage count when
	a note is added to an insn which refers to a CODE_LABEL.
	* gcse.c (add_label_notes): Likewise.

--- loop.c.orig	Thu Nov 30 12:22:29 2000
+++ loop.c	Fri Dec 15 17:25:46 2000
@@ -1589,7 +1589,8 @@
 }
 \f
 /* If X contains any LABEL_REF's, add REG_LABEL notes for them to all
-  insns in INSNS which use the reference.  */
+   insns in INSNS which use the reference.  LABEL_NUSES for CODE_LABEL
+   references is incremented once for each added note. */
 
 static void
 add_label_notes (x, insns)
@@ -1610,8 +1611,12 @@
          mark_jump_label for additional information).  */
       for (insn = insns; insn; insn = NEXT_INSN (insn))
 	if (reg_mentioned_p (XEXP (x, 0), insn))
-	  REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_LABEL, XEXP (x, 0),
-						REG_NOTES (insn));
+	  {
+	    REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_LABEL, XEXP (x, 0),
+						  REG_NOTES (insn));
+	    if (LABEL_P (XEXP (x, 0)))
+	      LABEL_NUSES (XEXP (x, 0))++;
+	  }
     }
 
   fmt = GET_RTX_FORMAT (code);
--- gcse.c.orig	Wed Dec  6 16:16:30 2000
+++ gcse.c	Fri Dec 15 17:23:06 2000
@@ -4839,8 +4839,9 @@
 }
 \f
 /* If X contains any LABEL_REF's, add REG_LABEL notes for them to INSN.
-   We have to add REG_LABEL notes, because the following loop optimization
-   pass requires them.  */
+   If notes are added to an insn which references a CODE_LABEL, the
+   LABEL_NUSES count is incremented.  We have to add REG_LABEL notes,
+   because the following loop optimization pass requires them.  */
 
 /* ??? This is very similar to the loop.c add_label_notes function.  We
    could probably share code here.  */
@@ -4868,6 +4869,8 @@
 
       REG_NOTES (insn) = gen_rtx_EXPR_LIST (REG_LABEL, XEXP (x, 0),
 					    REG_NOTES (insn));
+      if (LABEL_P (XEXP (x, 0)))
+        LABEL_NUSES (XEXP (x, 0))++;
       return;
     }
 

Re: pa reload problem

[Jeffrey A Law]

  In message <200012141640.LAA03285@hiauly1.hia.nrc.ca>you write:
  > That's what I thought.  It would appear to occur when the above two insns
  > get moved out of a loop.  The count gets decremented when the old insns
  > are deleted but not incremented when the new insns are created.  The puzzle
  > is why the count is zero rather than 1.  Maybe what happens is the two
  > insns in the loop are deleted first, then the label is deleted?  Notice
  > that insn 788 is moved to insn 1530.  However, the insn becomes 1531 and
  > the reg changes to 337 from 208.
In this case we typically will bump the number of uses before we delete
the insns that way the label doesn't go away unexpectedly.

jeff

Re: pa reload problem

[John David Anglin]

>   In message <200012141640.LAA03285@hiauly1.hia.nrc.ca>you write:
>   > That's what I thought.  It would appear to occur when the above two insns
>   > get moved out of a loop.  The count gets decremented when the old insns
>   > are deleted but not incremented when the new insns are created.  The puzzle
>   > is why the count is zero rather than 1.  Maybe what happens is the two
>   > insns in the loop are deleted first, then the label is deleted?  Notice
>   > that insn 788 is moved to insn 1530.  However, the insn becomes 1531 and
>   > the reg changes to 337 from 208.
> In this case we typically will bump the number of uses before we delete
> the insns that way the label doesn't go away unexpectedly.

As far I can tell, move_movables doesn't do this when it moves an insn
out of a loop.  It does this by deleting the old insn and creating a new
one.  It calls add_label_notes if notes need to be added to the new insn.

I sent a patch to add_label_notes for review which I think fixes the
problem.

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

Re: PATCH: Adjust label usage count for new insns [was Re: pa reload problem]

[Jeffrey A Law]

  In message <200012162038.PAA25535@hiauly1.hia.nrc.ca>you write:
  > 2000-12-14  John David Anglin  <dave@hiauly1.hia.nrc.ca>
  > 
  > 	* loop.c (add_label_notes): Increment the label usage count when
  > 	a note is added to an insn which refers to a CODE_LABEL.
  > 	* gcse.c (add_label_notes): Likewise.
Thanks.  Installed.

jeff

Re: abort in eliminate_regs compiling glob.c from glibc

[Richard Henderson]

On Tue, Nov 14, 2000 at 04:40:52PM -0500, John David Anglin wrote:
>      case USE:
> +      /* Handle insn_list USE that a call to a pure functions ...
> +      new = eliminate_regs (XEXP (x, 0), 0, insn);
> +      if (GET_CODE (new) == MEM)
> +	return XEXP (new, 0);

This is not correct.  You want to return something that still
looks like a USE.  Probably you want

	new = eliminate_regs (XEXP (x, 0), 0, insn);
	if (new != XEXP (x, 0))
	  return gen_rtx_USE (GET_MODE (x), new);
	return x;


r~

[parisc-linux] Re: testcase for hppa64 gcc bug

[Jeffrey A Law]

  In message <Pine.LNX.4.21.0012061607530.16721-100000@front.linuxcare.com.au>y
ou write:
  > > I think this needs to be reexamined.  Allan's ARG_POINTER_INVARIANT patch
  > > might not be needed now.
  > 
  > It's still needed.  The problem is that gcc thinks the arg pointer is
  > unchanged from the entry value to a function, even when the arg pointer
  > needs to be set to call other functions.
But the incoming argument pointer should have been copied into a pseudo at
the start of the function and the new pseudo used to address incoming args.

That's the real problem here I think.

jeff

Re: [parisc-linux] PIC assembly

[John David Anglin]

> This page contains links to various useful documents including the 32-bit
> runtime:
> 
> <http://h21007.www2.hp.com/dspp/tech/tech_TechTypeListingPage_IDX/1,1704,10403,00.html>.
> 
> The document itself is here:
> 
> <http://devresource.hp.com/STK/partner/rad_10_20.pdf>.

Maybe copies of these documents could be made accessible from the PA-RISC
LINUX Tech Documentation page as some of these are hard to find.

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

Re: [parisc-linux] PIC assembly

[Grant Grundler]

"John David Anglin" wrote:
> > This page contains links to various useful documents including the 32-bit
> > runtime:
> > 
> > <http://h21007.www2.hp.com/dspp/tech/tech_TechTypeListingPage_IDX/1,1704,10
>   403,00.html>.
> > 
> > The document itself is here:
> > 
> > <http://devresource.hp.com/STK/partner/rad_10_20.pdf>.
> 
> Maybe copies of these documents could be made accessible from the PA-RISC
> LINUX Tech Documentation page as some of these are hard to find.

I've been given the OK to link into h21007.www2.hp.com website and promised
the URLs for specific documents wouldn't change (too) suddenly.
I'll add those links in the next couple of days to p-l.org
"Tech Documentation" to those.

grant

Re: [parisc-linux] PIC assembly

[Grant Grundler]

Grant Grundler wrote:
> I've been given the OK to link into h21007.www2.hp.com website and promised
> the URLs for specific documents wouldn't change (too) suddenly.
> I'll add those links in the next couple of days to p-l.org
> "Tech Documentation" to those.

I've added links for PA 1.1 and PA 2.0 Instruction Sets among other things.
Please reload:
	http://www.parisc-linux.org/documentation/index.html

Please continue to post requests for links to docs here.
(I'm not promising any new docs at this point).

thanks,
grant

Re: [parisc-linux] compiling kernels with gcc-3.1

[John David Anglin]

> Is --disable-indexing used in kernel builds?  This should stop gcc
> from generating the above.

Oops, that should be "-mdisable-indexing".

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

Re: [parisc-linux] compiling kernels with gcc-3.1

[Randolph Chung]

In reference to a message from John David Anglin, dated Jul 15:
> > Is --disable-indexing used in kernel builds?  This should stop gcc
> > from generating the above.
> 
> Oops, that should be "-mdisable-indexing".

right now we use:
-Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-reduce
-mno-space-regs -mfast-indirect-calls -mdisable-fpregs
-ffunction-sections -march=2.0 -mschedule=8000

(the last two are only for pa8x00 builds...)

i'll try the disable-indexing stuff...

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] compiling kernels with gcc-3.1

[Matthew Wilcox]

On Mon, Jul 15, 2002 at 10:32:33AM -0700, Randolph Chung wrote:
> In reference to a message from John David Anglin, dated Jul 15:
> > > Is --disable-indexing used in kernel builds?  This should stop gcc
> > > from generating the above.
> > 
> > Oops, that should be "-mdisable-indexing".
> 
> right now we use:
> -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
> -fno-strict-aliasing -fno-common -D__linux__ -pipe -fno-strength-reduce
> -mno-space-regs -mfast-indirect-calls -mdisable-fpregs
> -ffunction-sections -march=2.0 -mschedule=8000
> 
> (the last two are only for pa8x00 builds...)
> 
> i'll try the disable-indexing stuff...

while we're on the subject of gcc flags ...

right now, we have an interesting patch in the kernel to get around a
fun feature of the PA ABI that no other ABI seems to have:

-asmlinkage ssize_t sys_pread(unsigned int fd, char * buf,
-                            size_t count, loff_t pos)
+static inline
+ssize_t do_pread(unsigned int fd, char * buf, size_t count, loff_t pos)
[...]
+#if BITS_PER_LONG == 32
+#ifdef __BIG_ENDIAN
+#define LOFF_T(high, low) unsigned int high, unsigned int low
+#else
+#define LOFF_T(high, low) unsigned int low, unsigned int high
+#endif
+
+asmlinkage
+ssize_t sys_pread(unsigned int fd, char *buf, size_t count, LOFF_T(high, low))
+{
+       return do_pread(fd, buf, count, (loff_t)high << 32 | low);
+}
+
+ssize_t sys_pwrite(unsigned int fd, char *buf, size_t count, LOFF_T(high, low))
+{
+       return do_pwrite(fd, buf, count, (loff_t)high << 32 | low);
+}

the problem is that the PA ABI specifies that quantities shall be
`naturally' aligned, even 64-bit quantities on 32-bit machines.  so the
kernel is expecting to see:

	fd (32 bits)
	buf (32 bits)
	count (32 bits)
	(empty)
	pos (64 bits)

what it _actually_ gets (because glibc is hideously broken, IMO):

	fd
	buf
	count
	(pos >> 32)
	pos & 0xffffffff

is there any chance of having a flag (or maybe an __attribute__ that
we could #define asmlinkage to?) which would change the ABI to be more
compressed like all the other architectures?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] compiling kernels with gcc-3.1

[John David Anglin]

> the problem is that the PA ABI specifies that quantities shall be
> `naturally' aligned, even 64-bit quantities on 32-bit machines.  so the
> kernel is expecting to see:
> 
> 	fd (32 bits)
> 	buf (32 bits)
> 	count (32 bits)
> 	(empty)
> 	pos (64 bits)
> 
> what it _actually_ gets (because glibc is hideously broken, IMO):
> 
> 	fd
> 	buf
> 	count
> 	(pos >> 32)
> 	pos & 0xffffffff

It's probably a whole lot easier to fix glibc than change gcc.

> is there any chance of having a flag (or maybe an __attribute__ that
> we could #define asmlinkage to?) which would change the ABI to be more
> compressed like all the other architectures?

I think this is basically a bad idea as it will have a whole lot
of nasty side effects.  How will gdb know which ABI, varargs, etc?

You would need to use a compiler switch and modify
FUNCTION_ARG_PARTIAL_NREGS and FUNCTION_ARG appropriately.

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

Re: [parisc-linux] compiling kernels with gcc-3.1

[joel.soete]

Quoting John David Anglin <dave@hiauly1.hia.nrc.ca>:

> > Is --disable-indexing used in kernel builds?  This should stop gcc
> > from generating the above.
> 
> Oops, that should be "-mdisable-indexing".

Sorry Dave,

it do not help (system still crashing)

Joel


-------------------------------------------------
This mail sent through Tiscali Webmail (http://webmail.tiscali.be)

Re: [parisc-linux] gcc-3.[02] alignment problem

[John David Anglin]

> These messages are coming from the assembler (remove "-pipe").  The
> first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> a store double.  This is probably a problem with pointer arithmetic
> in the source.

Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

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

Re: [parisc-linux] gcc-3.[02] alignment problem

[John David Anglin]

> These messages are coming from the assembler (remove "-pipe").  The
> first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> a store double.  This is probably a problem with pointer arithmetic
> in the source.

Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

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

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

In reference to a message from John David Anglin, dated Jul 16:
> > These messages are coming from the assembler (remove "-pipe").  The
> > first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> > a store double.  This is probably a problem with pointer arithmetic
> > in the source.
> 
> Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

ah, this is not it, but i see what it is now.

include/linux/tcp_diag.h defines:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
        __u32   tcpdiag_cookie[2]; 
#define TCPDIAG_NOCOOKIE (~0U)
};

the code goes on to do:
        *((struct sock **)&r->id.tcpdiag_cookie) = sk;
and
            sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

even tho tcpdiag_cookie looks like it can be 64-bit aligned in the
struct, it appears that it isn't.... 

the "vomit grade hack" alan mentioned in another post is that in our
tree, we have:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
#if defined (__hppa__) && defined (__LP64__)
        char * parisc_hack_to_align_tcpdiag_cookie;
#endif
        __u32   tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};

why is the offset of tcpdiag_cookie[0] 44 and not 40?

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

In reference to a message from John David Anglin, dated Jul 16:
> > These messages are coming from the assembler (remove "-pipe").  The
> > first is from "std %r4,44(%r3)".  The offset "44" is not correct for
> > a store double.  This is probably a problem with pointer arithmetic
> > in the source.
> 
> Check the definition of RTA_ALIGNTO in linux/rtnetlink.h.

ah, this is not it, but i see what it is now.

include/linux/tcp_diag.h defines:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
        __u32   tcpdiag_cookie[2]; 
#define TCPDIAG_NOCOOKIE (~0U)
};

the code goes on to do:
        *((struct sock **)&r->id.tcpdiag_cookie) = sk;
and
            sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

even tho tcpdiag_cookie looks like it can be 64-bit aligned in the
struct, it appears that it isn't.... 

the "vomit grade hack" alan mentioned in another post is that in our
tree, we have:

struct tcpdiag_sockid
{
        __u16   tcpdiag_sport;
        __u16   tcpdiag_dport;
        __u32   tcpdiag_src[4];
        __u32   tcpdiag_dst[4];
        __u32   tcpdiag_if;
#if defined (__hppa__) && defined (__LP64__)
        char * parisc_hack_to_align_tcpdiag_cookie;
#endif
        __u32   tcpdiag_cookie[2];
#define TCPDIAG_NOCOOKIE (~0U)
};

why is the offset of tcpdiag_cookie[0] 44 and not 40?

randolph
--  
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [parisc-linux] gcc-3.[02] alignment problem

[Matthew Wilcox]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
> include/linux/tcp_diag.h defines:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };

> why is the offset of tcpdiag_cookie[0] 44 and not 40?

0	tcpdiag_sport
2	tcpdiag_dport
4	tcpdiag_src
20	tcpdiag_dst
36	tcpdiag_if
40	tcpdiag_cookie

hmm.. worth checking that dport is at offset 2, not offset 4?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] gcc-3.[02] alignment problem

[Matthew Wilcox]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
> include/linux/tcp_diag.h defines:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };

> why is the offset of tcpdiag_cookie[0] 44 and not 40?

0	tcpdiag_sport
2	tcpdiag_dport
4	tcpdiag_src
20	tcpdiag_dst
36	tcpdiag_if
40	tcpdiag_cookie

hmm.. worth checking that dport is at offset 2, not offset 4?

-- 
Revolutions do not require corporate support.

Re: [parisc-linux] gcc-3.2 bootstrap?

[John David Anglin]

> > but when I try to use it to compile kernel-2.4.18-pa54 I got following error:
> > `gcc -print-libgcc-file-name`
> > /Develop/parisc-linux/src/linux-2.4.18-pa54/arch/parisc/lib/lib.a
> > /Develop/parisc-linux/src/linux-2.4.18-pa54/lib/lib.a  \
> >         --end-group \
> >         -o vmlinux
> > arch/parisc/kernel/kernel.o(__ksymtab+0x258): undefined reference to `$$mulU'  

> $$mulU is a millicode routine in libgcc.a.

Sorry, this routine is no longer in libgcc.a.  It was in the 32-bit
library for 3.0.x.  However, we have switched to the "64-bit" millicode
for both 32 and 64 bit code.  Gcc doesn't use it anymore but I see there
are a couple of remnants to clean up.

Your problem appears to be with arch/parisc/kernel/parisc_ksyms.c.
It imports the symbol.

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

Re: [parisc-linux] gcc-3.[02] alignment problem

[Richard Henderson]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };
> 
> the code goes on to do:
>         *((struct sock **)&r->id.tcpdiag_cookie) = sk;
> and
>             sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

This is absolutely awful.

> the "vomit grade hack" alan mentioned in another post is that in our
> tree, we have:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
> #if defined (__hppa__) && defined (__LP64__)
>         char * parisc_hack_to_align_tcpdiag_cookie;
> #endif
>         __u32   tcpdiag_cookie[2];

An only marginally better fix is

	__u32 tcpdiag_cookie[2] __attribute__((aligned(sizeof(void*))));

Note that this should be unconditional so that the other
64-bit ports don't take an alignment trap here too.

A much nicer fix would be to, gasp, use a union.



r~

Re: [parisc-linux] gcc-3.[02] alignment problem

[Richard Henderson]

On Tue, Jul 16, 2002 at 10:22:55AM -0700, Randolph Chung wrote:
>         __u32   tcpdiag_cookie[2]; 
> #define TCPDIAG_NOCOOKIE (~0U)
> };
> 
> the code goes on to do:
>         *((struct sock **)&r->id.tcpdiag_cookie) = sk;
> and
>             sk != *((struct sock **)&req->id.tcpdiag_cookie[0]))

This is absolutely awful.

> the "vomit grade hack" alan mentioned in another post is that in our
> tree, we have:
> 
> struct tcpdiag_sockid
> {
>         __u16   tcpdiag_sport;
>         __u16   tcpdiag_dport;
>         __u32   tcpdiag_src[4];
>         __u32   tcpdiag_dst[4];
>         __u32   tcpdiag_if;
> #if defined (__hppa__) && defined (__LP64__)
>         char * parisc_hack_to_align_tcpdiag_cookie;
> #endif
>         __u32   tcpdiag_cookie[2];

An only marginally better fix is

	__u32 tcpdiag_cookie[2] __attribute__((aligned(sizeof(void*))));

Note that this should be unconditional so that the other
64-bit ports don't take an alignment trap here too.

A much nicer fix would be to, gasp, use a union.



r~

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

> > why is the offset of tcpdiag_cookie[0] 44 and not 40?
> 
> 0	tcpdiag_sport
> 2	tcpdiag_dport
> 4	tcpdiag_src
> 20	tcpdiag_dst
> 36	tcpdiag_if
> 40	tcpdiag_cookie
> 
> hmm.. worth checking that dport is at offset 2, not offset 4?

oic, it's embedded inside another structure:

struct tcpdiagmsg
{
        __u8    tcpdiag_family;
        __u8    tcpdiag_state;
        __u8    tcpdiag_timer;
        __u8    tcpdiag_retrans;

        struct tcpdiag_sockid id;

        __u32   tcpdiag_expires;
        __u32   tcpdiag_rqueue;
        __u32   tcpdiag_wqueue;
        __u32   tcpdiag_uid;
        __u32   tcpdiag_inode;
};

that's why it's 44...

randolph

Re: [parisc-linux] gcc-3.[02] alignment problem

[Randolph Chung]

> > why is the offset of tcpdiag_cookie[0] 44 and not 40?
> 
> 0	tcpdiag_sport
> 2	tcpdiag_dport
> 4	tcpdiag_src
> 20	tcpdiag_dst
> 36	tcpdiag_if
> 40	tcpdiag_cookie
> 
> hmm.. worth checking that dport is at offset 2, not offset 4?

oic, it's embedded inside another structure:

struct tcpdiagmsg
{
        __u8    tcpdiag_family;
        __u8    tcpdiag_state;
        __u8    tcpdiag_timer;
        __u8    tcpdiag_retrans;

        struct tcpdiag_sockid id;

        __u32   tcpdiag_expires;
        __u32   tcpdiag_rqueue;
        __u32   tcpdiag_wqueue;
        __u32   tcpdiag_uid;
        __u32   tcpdiag_inode;
};

that's why it's 44...

randolph

Re: [parisc-linux] PATCH hppa ordered load absolute ops

[John David Anglin]

I installed the following after testing on hppa-unknown-linux-gnu.

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

2003-01-31  Grant Grundler  <grundler@dsl2.external.hp.com>

        * hppa.h (ldwa, ldda): Add ordered opcodes.

Index: opcode/hppa.h
===================================================================
RCS file: /cvs/src/src/include/opcode/hppa.h,v
retrieving revision 1.49
diff -u -3 -p -r1.49 hppa.h
--- opcode/hppa.h	16 Dec 2002 09:57:03 -0000	1.49
+++ opcode/hppa.h	31 Jan 2003 21:13:31 -0000
@@ -407,6 +407,7 @@ static const struct pa_opcode pa_opcodes
 { "ldbx",       0x0c000000, 0xfc001fc0, "cXx(b),t", pa10, 0},
 { "ldwa",       0x0c000180, 0xfc00d3c0, "cxccx(b),t", pa10, FLAG_STRICT},
 { "ldwa",	0x0c001180, 0xfc00d3c0, "cmcc5(b),t", pa10, FLAG_STRICT},
+{ "ldwa",	0x0c0011a0, 0xfc1ff3e0, "cocc@(b),t", pa20, FLAG_STRICT},
 { "ldcw",       0x0c0001c0, 0xfc0013c0, "cxcdx(s,b),t", pa10, FLAG_STRICT},
 { "ldcw",       0x0c0001c0, 0xfc0013c0, "cxcdx(b),t", pa10, FLAG_STRICT},
 { "ldcw",	0x0c0011c0, 0xfc0013c0, "cmcd5(s,b),t", pa10, FLAG_STRICT},
@@ -417,6 +418,7 @@ static const struct pa_opcode pa_opcodes
 { "stby",	0x0c001300, 0xfc0013c0, "cscCx,V(b)", pa10, FLAG_STRICT},
 { "ldda",       0x0c000100, 0xfc00d3c0, "cxccx(b),t", pa20, FLAG_STRICT},
 { "ldda",	0x0c001100, 0xfc00d3c0, "cmcc5(b),t", pa20, FLAG_STRICT},
+{ "ldda",	0x0c001120, 0xfc1ff3e0, "cocc@(b),t", pa20, FLAG_STRICT},
 { "ldcd",       0x0c000140, 0xfc0013c0, "cxcdx(s,b),t", pa20, FLAG_STRICT},
 { "ldcd",       0x0c000140, 0xfc0013c0, "cxcdx(b),t", pa20, FLAG_STRICT},
 { "ldcd",	0x0c001140, 0xfc0013c0, "cmcd5(s,b),t", pa20, FLAG_STRICT},

Re: [parisc-linux] PATCH hppa ordered load absolute ops

[John David Anglin]

I installed the following after testing on hppa-unknown-linux-gnu.

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

2003-01-31  Grant Grundler  <grundler@dsl2.external.hp.com>

        * hppa.h (ldwa, ldda): Add ordered opcodes.

Index: opcode/hppa.h
===================================================================
RCS file: /cvs/src/src/include/opcode/hppa.h,v
retrieving revision 1.49
diff -u -3 -p -r1.49 hppa.h
--- opcode/hppa.h	16 Dec 2002 09:57:03 -0000	1.49
+++ opcode/hppa.h	31 Jan 2003 21:13:31 -0000
@@ -407,6 +407,7 @@ static const struct pa_opcode pa_opcodes
 { "ldbx",       0x0c000000, 0xfc001fc0, "cXx(b),t", pa10, 0},
 { "ldwa",       0x0c000180, 0xfc00d3c0, "cxccx(b),t", pa10, FLAG_STRICT},
 { "ldwa",	0x0c001180, 0xfc00d3c0, "cmcc5(b),t", pa10, FLAG_STRICT},
+{ "ldwa",	0x0c0011a0, 0xfc1ff3e0, "cocc@(b),t", pa20, FLAG_STRICT},
 { "ldcw",       0x0c0001c0, 0xfc0013c0, "cxcdx(s,b),t", pa10, FLAG_STRICT},
 { "ldcw",       0x0c0001c0, 0xfc0013c0, "cxcdx(b),t", pa10, FLAG_STRICT},
 { "ldcw",	0x0c0011c0, 0xfc0013c0, "cmcd5(s,b),t", pa10, FLAG_STRICT},
@@ -417,6 +418,7 @@ static const struct pa_opcode pa_opcodes
 { "stby",	0x0c001300, 0xfc0013c0, "cscCx,V(b)", pa10, FLAG_STRICT},
 { "ldda",       0x0c000100, 0xfc00d3c0, "cxccx(b),t", pa20, FLAG_STRICT},
 { "ldda",	0x0c001100, 0xfc00d3c0, "cmcc5(b),t", pa20, FLAG_STRICT},
+{ "ldda",	0x0c001120, 0xfc1ff3e0, "cocc@(b),t", pa20, FLAG_STRICT},
 { "ldcd",       0x0c000140, 0xfc0013c0, "cxcdx(s,b),t", pa20, FLAG_STRICT},
 { "ldcd",       0x0c000140, 0xfc0013c0, "cxcdx(b),t", pa20, FLAG_STRICT},
 { "ldcd",	0x0c001140, 0xfc0013c0, "cmcd5(s,b),t", pa20, FLAG_STRICT},

Re: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase.

[John David Anglin]

> > I've added all the caller-saves registers to our clobber lists when
> > making syscalls. Though, r19 being special, I've had to add "STW_PIC"
> > and "LDW_PIC" that do the saving and restore _only_ if we are compiled
> > PIC.
> 
> That seems overly pessimistic and will mean a lot more register saves
> in routines that do syscalls.  It appears the system saves the caller-save
> registers in all syscalls except the fork related calls.  It would
> be best to keep the number of clobbers to a minimum.  I wonder, there
> seems to be a slot in the task struct for r1, but it's never saved in
> a syscall, and r1 is clobbered.  Maybe the r1 slot could be used to save
> r2.  This might mean that we don't need to use GR21 or GR22 at all.
> It would avoid having to have special pic code.

Another possibility might be to define another couple of offsets in the
task struct.  It looks as if there is plenty of space before an alignment
boundary is reached.

Re: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase.

[Carlos O'Donell]

> Another possibility might be to define another couple of offsets in the
> task struct.  It looks as if there is plenty of space before an alignment
> boundary is reached.

That seems best. The sad fact though is that until I bump
min_kernel_version in glibc past the kernel version that last didn't
have this fix, I'm still forced to implement all this for people with
older kernels.

c.

Re: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase.

[John David Anglin]

> That seems best. The sad fact though is that until I bump
> min_kernel_version in glibc past the kernel version that last didn't
> have this fix, I'm still forced to implement all this for people with
> older kernels.

Why?  Things are broken now and people have lived with the bug for
sometime.  While it is possible to work around the problem in userspace,
the best fix is to do it in the kernel.  I wouldn't fix anything but
a regression.

Dave

Re: [parisc-linux] Re: [glibc] tststatic failues, reduced to simp le testcase.

[Carlos O'Donell]

On Sun, Aug 31, 2003 at 04:47:59PM -0400, John David Anglin wrote:
> > That seems best. The sad fact though is that until I bump
> > min_kernel_version in glibc past the kernel version that last didn't
> > have this fix, I'm still forced to implement all this for people with
> > older kernels.
> 
> Why?  Things are broken now and people have lived with the bug for
> sometime.  While it is possible to work around the problem in userspace,
> the best fix is to do it in the kernel.  I wouldn't fix anything but
> a regression.

It's best to use an example. Debian supports HPPA as an architecture.
I provide Debian with patches to make upstream glibc cvs buildable for
this distribution. If I make all the glibc fixes in the kernel, and
submit to debian minimal patches, glibc will build and subsequent
updates will render all userspace broken. As a happy medium I need to
make, atleast for all usable distributions, a set of patches that fix it
in such a way that we don't force a kernel update (people don't like to
update their kernel). The patches I send upstream will be different.
They will, to the best of my ability, be as clean as possible. I balance
users on one side, and the "right thing" on the other.

I agree, that the kernel, sharing the context switch path, and already
saving r19 should be held responsible for restoring r19. I've already
begun to run into a number of cases where userspace restores aren't
going so well.

c.

[parisc-linux] dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_pglobal_lookup

[John David Anglin]

I hacked together of a build of debian gdb-6.0-2 this afternoon.  When
I start gdb, I see the following error:

dave@gsyprf11:~/gdb-6.0-2/objdir$ gdb/gdb


dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_pglobal_lookup
GDB will not be able to debug pthreads.

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

[parisc-linux] Re: dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_pglobal_lookup

[Carlos O'Donell]

On Mon, Dec 15, 2003 at 05:05:12PM -0500, John David Anglin wrote:
> I hacked together of a build of debian gdb-6.0-2 this afternoon.  When
> I start gdb, I see the following error:

My friend, that's amazing!
 
> dave@gsyprf11:~/gdb-6.0-2/objdir$ gdb/gdb
> dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_pglobal_lookup
> GDB will not be able to debug pthreads.

Every pogram that links libthread_db.so.1 must provide a set of process
control primities that will allow libthread_db to access memory and
registers in the target process, start and stop the process, and lookup
symbols. ps_pglobal_lookup is always UND in libthread_db, and gdb should
have exported an arch version for the library to use :)

c.

Re: [parisc-linux] Re: dlopen failed on 'libthread_db.so.1' - /lib/libthread_db.so.1: undefined symbol: ps_pglobal_lookup

[Carlos O'Donell]

On Wed, Dec 17, 2003 at 10:32:20AM -0500, Carlos O'Donell wrote:
> Every pogram that links libthread_db.so.1 must provide a set of process
> control primities that will allow libthread_db to access memory and
> registers in the target process, start and stop the process, and lookup
> symbols. ps_pglobal_lookup is always UND in libthread_db, and gdb should
> have exported an arch version for the library to use :)

See:

gdb/proc-service.c
gdb/gdbserver/proc-service.c

*unless* You are insinuating that the loader has messed up the symbol
resolution and ps_pglobal_lookup exists but isn't resolved properly...
which is a whole 'nother can of wormns :)

c.

Re: [parisc-linux] Re: dlopen failed on 'libthread_db.so.1' -

[John David Anglin]

> See:
> 
> gdb/proc-service.c
> gdb/gdbserver/proc-service.c
> 
> *unless* You are insinuating that the loader has messed up the symbol
> resolution and ps_pglobal_lookup exists but isn't resolved properly...
> which is a whole 'nother can of wormns :)

I'll take a look.  Based on what you have said, it's likely the gdb-6.0
isn't being linked correctly on hppa-linux.  Debian gdb-6.0-2 doesn't
build as is, and I had to make some minor mod's to the patch set and hack 
a config file to include linux-nat.o in the required files.

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

Re: [parisc-linux] Re: dlopen failed on 'libthread_db.so.1' -

[Carlos O'Donell]

On Wed, Dec 17, 2003 at 11:43:48AM -0500, John David Anglin wrote:
> > See:
> > 
> > gdb/proc-service.c
> > gdb/gdbserver/proc-service.c
> > 
> > *unless* You are insinuating that the loader has messed up the symbol
> > resolution and ps_pglobal_lookup exists but isn't resolved properly...
> > which is a whole 'nother can of wormns :)
> 
> I'll take a look.  Based on what you have said, it's likely the gdb-6.0
> isn't being linked correctly on hppa-linux.  Debian gdb-6.0-2 doesn't
> build as is, and I had to make some minor mod's to the patch set and hack 
> a config file to include linux-nat.o in the required files.

AFAIK there was major work required. I shy'd away completely as glibc
was taking up all my time and seemed like a better place to start :)

Current todo:

- Giving up on fixing dlopen from static app, too tough for me right
  now.
- Atomic ups are up next, with possibly a review of time functions,
  monotonicity and a fast gettimeofday.

c.

Re: [parisc-linux] Re: dlopen failed on 'libthread_db.so.1' -

[John David Anglin]

> On Wed, Dec 17, 2003 at 11:43:48AM -0500, John David Anglin wrote:
> > > See:
> > > 
> > > gdb/proc-service.c
> > > gdb/gdbserver/proc-service.c
> > > 
> > > *unless* You are insinuating that the loader has messed up the symbol
> > > resolution and ps_pglobal_lookup exists but isn't resolved properly...
> > > which is a whole 'nother can of wormns :)
> > 
> > I'll take a look.  Based on what you have said, it's likely the gdb-6.0
> > isn't being linked correctly on hppa-linux.  Debian gdb-6.0-2 doesn't
> > build as is, and I had to make some minor mod's to the patch set and hack 
> > a config file to include linux-nat.o in the required files.

dave@gsyprf11:~/gdb-6.0-2/objdir/gdb$ nm gdb|grep ps_pglobal_lookup
000dc904 T ps_pglobal_lookup

Looks as if there is a problem with dlopen.

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

Re: [parisc-linux] Re: dlopen failed on 'libthread_db.so.1' -

[John David Anglin]

> dave@gsyprf11:~/gdb-6.0-2/objdir/gdb$ nm gdb|grep ps_pglobal_lookup
> 000dc904 T ps_pglobal_lookup
> 
> Looks as if there is a problem with dlopen.

No, the problem is ps_pglobal_lookup isn't in gdb's dynamic symbol
table.  I'll have to figure out how this is done.

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

Re: [parisc-linux] Re: dlopen failed on 'libthread_db.so.1' -g

[John David Anglin]

> No, the problem is ps_pglobal_lookup isn't in gdb's dynamic symbol
> table.  I'll have to figure out how this is done.

Adding --export-dynamic to the gdb link command resolves the problem.

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

Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.

[John David Anglin]

> Did I miss something?

Yup.

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

Re: [parisc-linux] [Testers wanted] New glibc with profiling fixed.

[John David Anglin]

> Did I miss something?

Yup.

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

[parisc-linux] Re: linux signal race fixes, patches against hppa tree, please test.

[John David Anglin]

> > This is more important for you, approximately 48 hours ago, Linus
> > commited a fix for a signal handling race.
> > 
> > http://linux.bkbits.net:8080/linux-2.6/cset@1.1846.1.48?nav=index.html|Chang
> > eSet@-2d
> 
> I have the patch under test on hiauly6 with todays CVS.

I've been running this now for three days on hiauly6 with a 32-bit
2.6.8.1-pa7 kernel (default c3000 config) doing almost continuous gcc
builds.  Things seem pretty promising.  No random SIGSEGVs and expect
seems to be behaving itself.

> I had another SIGSEGV on gsyprf11.  It looks as if this was in /bin/sh
> although gdb doesn't say which program the fault ocurred in.

This is definitely not the case with the 64-bit SMP kernel on gsyprf11.
There I've been testing with an unpatched kernel.  Expect works better with
tcl8.3 but there are still some tests that fail when they shouldn't, and
the output with tests which produce a large amount of output gets
truncated.  With tcl8.4, expect has major problems.  The Tcl_Finalize
patch doesn't fix them.  I think we need to try Carlos's patch on a
64-bit SMP system to see if it helps the expect and SEGV problems.

I'm off to Korea early Thursday morning so I can't do much more on
this until I'm back in a couple of weeks.

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: linux signal race fixes, patches against hppa tree, please te

[John David Anglin]

> I've been running this now for three days on hiauly6 with a 32-bit
> 2.6.8.1-pa7 kernel (default c3000 config) doing almost continuous gcc
> builds.  Things seem pretty promising.  No random SIGSEGVs and expect
> seems to be behaving itself.

As usual, I have to eat my words.  The libjava "PR218 -O3 execution -
source compiled test" hung in the libjava testsuite on the next gcc
build.  Looking at libjava.log, I see that there is no "WARNING:
program timed out." message for this test.  Thus, the alarm signal
for this test somehow got lost.  The testsuite continued after I
killed PR218.exe.

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: linux signal race fixes, patches against hppa tree, please te

[John David Anglin]

Hi Randolph,

> > I've been running this now for three days on hiauly6 with a 32-bit
> > 2.6.8.1-pa7 kernel (default c3000 config) doing almost continuous gcc
> > builds.  Things seem pretty promising.  No random SIGSEGVs and expect
> > seems to be behaving itself.
> 
> As usual, I have to eat my words.  The libjava "PR218 -O3 execution -
> source compiled test" hung in the libjava testsuite on the next gcc
> build.  Looking at libjava.log, I see that there is no "WARNING:
> program timed out." message for this test.  Thus, the alarm signal
> for this test somehow got lost.  The testsuite continued after I
> killed PR218.exe.

Ok, the next time around on gsyprf11 expect did a SIGSEGV after the
exact same test.  The timeout warning was printed in the log this time.

The core dump, core.20875, is in my home directory.  The expect
program is /home/dave/opt/gnu/bin/expect.  I can see that expect
died because %r4 has apparently gotten clobbered.  It contains
0.  %r4 was used to restore the pic register after the last call.
We then die in a stub that uses the pic register.

Is there any chance you could look at fixing the backtrace command
in gdb?  Here is the bt:

(gdb) bt
#0  0x406a0ef4 in NativePathInFilesystem () from /usr/lib/libtcl8.4.so.0
#1  0x406d5be4 in Tcl_WaitForEvent () from /usr/lib/libtcl8.4.so.0
#2  0x00000000 in ?? ()
#3  0x00000000 in ?? ()
(gdb) maint print unwind 0x406d5be4
unwind_table_entry (0x6a6744):
        region_start = 0x406d59b0 <Tcl_WaitForEvent+784>
	region_end = 0x406d5e0c <Tcl_WaitForEvent+1900>
	flags = Save_RP
	Region_description = 0x1
	Entry_FR = 0x0
	Entry_GR = 0x10
	Total_frame_size = 0x48
(gdb) disass 0x406a0ee4 0x406a0f04
Dump of assembler code from 0x406a0ee4 to 0x406a0f04:
0x406a0ee4 <NativePathInFilesystem+1668>:       ldw 518(,r1),r21
0x406a0ee8 <NativePathInFilesystem+1672>:       bv r0(r21)
0x406a0eec <NativePathInFilesystem+1676>:       ldw 51c(,r1),r19
0x406a0ef0 <NativePathInFilesystem+1680>:       addil -1800,r19,%r1
0x406a0ef4 <NativePathInFilesystem+1684>:       ldw 320(,r1),r21
0x406a0ef8 <NativePathInFilesystem+1688>:       bv r0(r21)
0x406a0efc <NativePathInFilesystem+1692>:       ldw 324(,r1),r19
0x406a0f00 <NativePathInFilesystem+1696>:       addil -1800,r19,%r1
(gdb) disass 0x406d5bc4 0x406d5bf4
Dump of assembler code from 0x406d5bc4 to 0x406d5bf4:
0x406d5bc4 <Tcl_WaitForEvent+1316>:     stw r8,-34(,sp)
0x406d5bc8 <Tcl_WaitForEvent+1320>:     copy r4,r19
0x406d5bcc <Tcl_WaitForEvent+1324>:     copy r5,r26
0x406d5bd0 <Tcl_WaitForEvent+1328>:     ldo -238(sp),r25
0x406d5bd4 <Tcl_WaitForEvent+1332>:     ldo -1b8(sp),r24
0x406d5bd8 <Tcl_WaitForEvent+1336>:     ldo -138(sp),r23
0x406d5bdc <Tcl_WaitForEvent+1340>:     b,l 0x406a2394 <NativePathInFilesystem+6
964>,rp
0x406d5be0 <Tcl_WaitForEvent+1344>:     ldi 60,r7
0x406d5be4 <Tcl_WaitForEvent+1348>:     cmpib,= -1,ret0,0x406d5b24 <Tcl_WaitForE
vent+1156>
0x406d5be8 <Tcl_WaitForEvent+1352>:     copy r4,r19
0x406d5bec <Tcl_WaitForEvent+1356>:     b,l 0x406a0ef0 <NativePathInFilesystem+1
680>,rp
0x406d5bf0 <Tcl_WaitForEvent+1360>:     copy r14,r26
(gdb) p/x $rp
$1 = 0x406d5bf7
(gdb) disass 0x406a2394 0x406a23a4
Dump of assembler code from 0x406a2394 to 0x406a23a4:
0x406a2394 <NativePathInFilesystem+6964>:       addil -800,r19,%r1
0x406a2398 <NativePathInFilesystem+6968>:       ldw a0(,r1),r21
0x406a239c <NativePathInFilesystem+6972>:       bv r0(r21)

I'm not quite sure how we got to the point of the segfault.  However,
with respect to gdb, the back trace uses the wrong function symbol
in both frames 0 and 1.  We are in a stub in frame 0.  I'm fairly
sure that this is why the bt fails at frame 2.

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: linux signal race fixes, patches against hppa tree, please te

[Carlos O'Donell]

On Tue, Aug 31, 2004 at 04:43:11PM -0400, John David Anglin wrote:
> > I've been running this now for three days on hiauly6 with a 32-bit
> > 2.6.8.1-pa7 kernel (default c3000 config) doing almost continuous gcc
> > builds.  Things seem pretty promising.  No random SIGSEGVs and expect
> > seems to be behaving itself.
> 
> As usual, I have to eat my words.  The libjava "PR218 -O3 execution -
> source compiled test" hung in the libjava testsuite on the next gcc
> build.  Looking at libjava.log, I see that there is no "WARNING:
> program timed out." message for this test.  Thus, the alarm signal
> for this test somehow got lost.  The testsuite continued after I
> killed PR218.exe.

Losing signals under load is very bad, I don't see where or why this
might be happening. I don't really know what that test does, if it uses
compare_and_swap in any way then it's non-atomic and all sorts of bad
things could happen under load.

I'm still writing my paper, so I can't add the hooks in for this.

c.

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

[parisc-linux] Another SIGSEGV, this time in /bin/sh

[John David Anglin]

I had another SIGSEGV today building gcc on gsyprf11.

dave@gsyprf11:~/gcc-3.5/objdir$ gdb /bin/sh gcc/core.save.1
GNU gdb 2004-09-01-cvs
...
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/debug/libncurses.so.5...done.
Loaded symbols for /usr/lib/debug/libncurses.so.5
Reading symbols from /usr/lib/debug/libdl.so.2...done.
Loaded symbols for /usr/lib/debug/libdl.so.2
Reading symbols from /usr/lib/debug/libc.so.6...done.
Loaded symbols for /usr/lib/debug/libc.so.6
Reading symbols from /lib/ld.so.1...done.
Loaded symbols for /lib/ld.so.1
#0  0xf7025554 in ?? ()

Looking at %r2, it appears that the fault has occurred in an indirect
call from __strtoll_internal:

(gdb) p/x $rp
$1 = 0x40785883
(gdb) disass 0x40785860 0x40785888
Dump of assembler code from 0x40785860 to 0x40785888:
0x40785860 <*__GI___strtoll_internal+2972>:     copy r19,r4
0x40785864 <*__GI___strtoll_internal+2976>:     b,l 0x4076c508 <__gconv_read_conf+916>,r31
0x40785868 <*__GI___strtoll_internal+2980>:     copy r31,rp
0x4078586c <*__GI___strtoll_internal+2984>:     b,l 0x40785848 <*__GI___strtoll_internal+2948>,r0
0x40785870 <*__GI___strtoll_internal+2988>:     copy r4,r19
0x40785874 <*__GI___strtoll_internal+2992>:     copy r19,r4
0x40785878 <*__GI___strtoll_internal+2996>:     b,l 0x4076c508 <__gconv_read_conf+916>,r31
0x4078587c <*__GI___strtoll_internal+3000>:     copy r31,rp

We appear to have reached 0x40785874 from the following code:

0x40784d40 <*__GI___strtoll_internal+124>:      ldi 24,r20
0x40784d44 <*__GI___strtoll_internal+128>:      cmpb,>= r20,r9,0x40784db8 <*__GI___strtoll_internal+244>
0x40784d48 <*__GI___strtoll_internal+132>:      addil 1000,r19,%r1
...
0x40784db8 <*__GI___strtoll_internal+244>:      ldw -124(,sp),r7
0x40784dbc <*__GI___strtoll_internal+248>:      ldi 20,r10
---Type <return> to continue, or q <return> to quit---
0x40784dc4 <*__GI___strtoll_internal+256>:      stw r7,-f0(,sp)
0x40784dc8 <*__GI___strtoll_internal+260>:      addil 1000,r19,%r1
0x40784dcc <*__GI___strtoll_internal+264>:      copy r3,r8
0x40784dd0 <*__GI___strtoll_internal+268>:      ldw 390(,r1),r6
0x40784dd4 <*__GI___strtoll_internal+272>:      ldw 98(,r3),r22
0x40784dd8 <*__GI___strtoll_internal+276>:      addil 1000,r19,%r1
0x40784ddc <*__GI___strtoll_internal+280>:      cmpib,<> 0,r22,0x40785874 <*__GI
I___strtoll_internal+2992>

The address for the indirect call, r22, was loaded as follows:
(gdb) p/x *($r3 + 0x98)
$20 = 0xf7025555

Some interesting registers:
(gdb) p/x $r10
$23 = 0x20
(gdb) p/x $r3
$13 = 0xe3c08
(gdb) p/x $r8
$16 = 0xe3c08
(gdb) p/x $r6
$18 = 0x408a1c8c
(gdb) p/x *($r19 + 0x1000 + 0x390)
$17 = 0x408a1c8c
(gdb) p/x $r7
$21 = 0xd65e8
(gdb) p/x *($sp - 0xf0)
$22 = 0xd65e8

This establishes how we got to the failure point.

It would appear that r3 has either been clobbered by the kernel, or there
is a problem with the memory access by which it was loaded:

(gdb) p/x *($r19 + 0x1000 + 0x354)
$12 = 0x408a98fc

This should have given the r3 value.  The same procedure gave the r6 value.

(gdb) p/x *(*($r19 + 0x1000 + 0x354) + 0x98)
$19 = 0x0

This is probably the value that r22 should have had.

The failure doesn't happen consistently as rerunning the script which failed
was successful.

Any thoughts?

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: Another SIGSEGV, this time in /bin/sh

[Carlos O'Donell]

jda,

What kernel is this btw?

> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/debug/libncurses.so.5...done.
> Loaded symbols for /usr/lib/debug/libncurses.so.5
> Reading symbols from /usr/lib/debug/libdl.so.2...done.
> Loaded symbols for /usr/lib/debug/libdl.so.2
> Reading symbols from /usr/lib/debug/libc.so.6...done.
> Loaded symbols for /usr/lib/debug/libc.so.6
> Reading symbols from /lib/ld.so.1...done.
> Loaded symbols for /lib/ld.so.1

Why isn't this the debug ld.so?

> Looking at %r2, it appears that the fault has occurred in an indirect
> call from __strtoll_internal:

But it's always some place different every failure...
 
> It would appear that r3 has either been clobbered by the kernel, or there
> is a problem with the memory access by which it was loaded:

It's possible.
 
> This should have given the r3 value.  The same procedure gave the r6 value.
> (gdb) p/x *(*($r19 + 0x1000 + 0x354) + 0x98)
> $19 = 0x0

So you are saying that the code should have given that value, but
something corrupted the value before it was used?

It definately looks signal related. It feels a lot like some return path
in the kernel might be clobbering r3. Time for another witch hunt?

c.

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

[parisc-linux] Re: Comments?

[John David Anglin]

> > > I think we have somehow broken __cffc.  I did a binutils build
> > > yesterday and various ld tests are now failing.  These are tests
> > > that compare function pointers.
> > 
> > I didn't feed anything new into debian-glibc. All my patches have always
> > strived to keep __cffc working, if I messup the function pointer
> > comparison I get a slew of glibc testsuite failures which I always
> > patchup by making sure __cffc works :)
> 
> I haven't touched fptr.c either, although there is a change in GCC
> 4.0 with respect to canonicalization.  I'm using the debian glibc,
> 2.3.2.ds1-20, on the system on which I noticed this problem.

Ok, ld is broken in the binutils CVS head.
__canonicalize_funcptr_for_compare doesn't load the correct address
for _GLOBAL_OFFSET_TABLE_ in shared libraries.  It loads the address
used by main.  As a result, it thinks the plabel for the function
has been resolved ;(

The testcase is:

foo.c:

extern void bar (void);
typedef void (*func_t)(void);
int
foo (func_t f)
{
  return f == bar;
}

bar.c:

void bar (void) {};
int
main ()
{
  if (!foo (bar))
    abort ();
  return 0;
}

gcc -g -fPIC -S foo.c
gcc -shared -fPIC -o foo.sl foo.o
gcc -c -g -w bar.c
gcc -o bar bar.o foo.sl

nm foo.sl
...
00010ab0 a _GLOBAL_OFFSET_TABLE_

nm bar
...
00020c54 d _GLOBAL_OFFSET_TABLE_

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: Comments?

[John David Anglin]

> Ok, ld is broken in the binutils CVS head.
> __canonicalize_funcptr_for_compare doesn't load the correct address
> for _GLOBAL_OFFSET_TABLE_ in shared libraries.  It loads the address
> used by main.  As a result, it thinks the plabel for the function
> has been resolved ;(

Found it:

2004-11-02  Hans-Peter Nilsson  <hp@axis.com>

        * elflink.c (_bfd_elf_create_got_section): Hide _GLOBAL_OFFSET_TABLE_.

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: Comments?

[Carlos O'Donell]

On Sat, Mar 05, 2005 at 07:22:27PM -0500, John David Anglin wrote:
> > Ok, ld is broken in the binutils CVS head.
> > __canonicalize_funcptr_for_compare doesn't load the correct address
> > for _GLOBAL_OFFSET_TABLE_ in shared libraries.  It loads the address
> > used by main.  As a result, it thinks the plabel for the function
> > has been resolved ;(
> 
> Found it:
> 
> 2004-11-02  Hans-Peter Nilsson  <hp@axis.com>
> 
>         * elflink.c (_bfd_elf_create_got_section): Hide _GLOBAL_OFFSET_TABLE_.

I'd seen that fly by on binutils and it caused a certain amount of grief
in glibc. I'm not quite sure what the rational was behind hiding _GOT_.

c.

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

[parisc-linux] Re: Comments?

[John David Anglin]

> > 2004-11-02  Hans-Peter Nilsson  <hp@axis.com>
> > 
> >         * elflink.c (_bfd_elf_create_got_section): Hide _GLOBAL_OFFSET_TABLE_.
> 
> I'd seen that fly by on binutils and it caused a certain amount of grief
> in glibc. I'm not quite sure what the rational was behind hiding _GOT_.

I believe that the idea was that main code would see its _GOT_ address
and shared libraries their respective _GOT_ address.  It turns out that
it was sort of a fluke that function pointer canonicalization worked.
Only function pointers in the main part of an application are not
resolved.  Shared library function pointers are resolved when the
library is loaded.  __cffc was always looking at the _GOT_ address
for the main app (i.e., the main _GLOBAL_OFFSET_TABLE_ value overrode
the shared library symbol).

This problem was fixed yesterday by Alan Modra.

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: Comments?

[Carlos O'Donell]

On Tue, Mar 08, 2005 at 12:44:53PM -0500, John David Anglin wrote:
> > > 2004-11-02  Hans-Peter Nilsson  <hp@axis.com>
> > > 
> > >         * elflink.c (_bfd_elf_create_got_section): Hide _GLOBAL_OFFSET_TABLE_.
> > 
> > I'd seen that fly by on binutils and it caused a certain amount of grief
> > in glibc. I'm not quite sure what the rational was behind hiding _GOT_.
> 
> I believe that the idea was that main code would see its _GOT_ address
> and shared libraries their respective _GOT_ address.  It turns out that
> it was sort of a fluke that function pointer canonicalization worked.
> Only function pointers in the main part of an application are not
> resolved.  Shared library function pointers are resolved when the
> library is loaded.  __cffc was always looking at the _GOT_ address
> for the main app (i.e., the main _GLOBAL_OFFSET_TABLE_ value overrode
> the shared library symbol).
> 
> This problem was fixed yesterday by Alan Modra.

I'm not sure what you mean in your statement "shared library function
pointers are resolved when the library is loaded?" The function pointers
exist as two-byte entries in the PLT, and are non-unique, and they
aren't resolved until call time with lazy resolution.

I would imagine that the main _GOT_ is supposed to override the shared
library _GOT_. __cffc is only looking at the _GOT_ to get the fptr that
the dynamic loader wrote there during setup, so that it can get called
for symbol resolution. This setup is done for all objects, which
includes all the _GOT_'s, from the application to all the loaded shared
libraries.

Or rather are you saying, that from a shared library, the library saw
only the _GOT_ from the main applicaiton? I would think that this 
wouldn't effect the library since the loader setup r19 properly, and
aslong as it doesn't use _GOT_ then it's fine.

c.

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

[parisc-linux] Re: Comments?

[John David Anglin]

> > This problem was fixed yesterday by Alan Modra.
> 
> I'm not sure what you mean in your statement "shared library function
> pointers are resolved when the library is loaded?" The function pointers
> exist as two-byte entries in the PLT, and are non-unique, and they
> aren't resolved until call time with lazy resolution.

This is what Alasn said:

  I checked.  &_GLOBAL_OFFSET_TABLE_ in fptr.c does resolve to the main
  app GOT before the change.  That in fact is what is needed, because
  according to what I see in dl-machine.h, plabels in shared libs will be
  resolved.  I think it's only plabels in the main app for global
  functions that won't be resolved (because they point into the plt).

  Hmm.  If PLABEL32 relocs in the main app were emitted as dynamic relocs,
  then ld.so would call _dl_make_fptr for them.  I think you wouldn't need
  __canonicalize_funcptr_for_compare any more..

I don't think we could completely do away with __cffc but if the
plabels were always resolved we could just look inside the plabel
to get the function address.

> I would imagine that the main _GOT_ is supposed to override the shared
> library _GOT_. __cffc is only looking at the _GOT_ to get the fptr that
> the dynamic loader wrote there during setup, so that it can get called
> for symbol resolution. This setup is done for all objects, which
> includes all the _GOT_'s, from the application to all the loaded shared
> libraries.

If the dynamic loader always uses the main app's got for the trampoline,
__cffc would work for plabels in shared libraries that used lazy linking.

> Or rather are you saying, that from a shared library, the library saw
> only the _GOT_ from the main applicaiton? I would think that this 
> wouldn't effect the library since the loader setup r19 properly, and
> aslong as it doesn't use _GOT_ then it's fine.

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] OPD's on hppa-linux, and what to do about __cffc's fragility.

[Carlos O'Donell]

On Tue, Mar 08, 2005 at 02:02:33PM -0500, John David Anglin wrote:
> > > This problem was fixed yesterday by Alan Modra.
> > 
> > I'm not sure what you mean in your statement "shared library function
> > pointers are resolved when the library is loaded?" The function pointers
> > exist as two-byte entries in the PLT, and are non-unique, and they
> > aren't resolved until call time with lazy resolution.

Once, we start quoting Alan, I believe it's time to atleast let him read
some of the remarks. Perhaps he will have some insightful comment.
 
> This is what Alasn said:
> 
>   I checked.  &_GLOBAL_OFFSET_TABLE_ in fptr.c does resolve to the main
>   app GOT before the change.  That in fact is what is needed, because
>   according to what I see in dl-machine.h, plabels in shared libs will be
>   resolved.  I think it's only plabels in the main app for global
>   functions that won't be resolved (because they point into the plt).
> 
>   Hmm.  If PLABEL32 relocs in the main app were emitted as dynamic relocs,
>   then ld.so would call _dl_make_fptr for them.  I think you wouldn't need
>   __canonicalize_funcptr_for_compare any more..
> 
> I don't think we could completely do away with __cffc but if the
> plabels were always resolved we could just look inside the plabel
> to get the function address.

Perhaps some background and clarification...

Okay, *ABS* (R_PARISC_IPLT, r_sym == 0) entries are automatically
relocated at startup, because we have enough information, we are already
walking the PLT list, and it takes only a single add to complete the
relocation. 

Next, anything else (R_PARISC_IPLT, r_sym != 0) is pointed at the
plt/got stub (which calls the trampoline _dl_runtime_resolve) since it
will require symbol resolution to fixup.

I don't quite understand what Alan is getting at when he says "If
PLABEL32 relocs in the main app were emitted as dynamic relocs,"

I'm really a stickler for nomeclature. In my mind a "resolved" plabel is
one whose ip/gp point to the true and final function address after the ELF
symbol resolution rules have been followed for that symbol. Is this the
generally accepted definition? I interchangably think plabel == fptr.

> > I would imagine that the main _GOT_ is supposed to override the shared
> > library _GOT_. __cffc is only looking at the _GOT_ to get the fptr that
> > the dynamic loader wrote there during setup, so that it can get called
> > for symbol resolution. This setup is done for all objects, which
> > includes all the _GOT_'s, from the application to all the loaded shared
> > libraries.
> 
> If the dynamic loader always uses the main app's got for the trampoline,
> __cffc would work for plabels in shared libraries that used lazy linking.

To clarify this, you mean to say if the loader always uses the main
app's plt/got stub then everything would be okay. The check in __cffc to
see if the plabel has been resolved would work (e.g. got !=
&_GLOBAL_OFFSET_TABLE_).

It didn't make a difference in the past because the shared library
plabels were already resolved? Wouldn't this mean that lazy linking
wasn't working at all?

So only the main app symbols had to be resolved, and this worked fine.
Thus the comparison worked fine.

I don't quite understand why this broke, if someone would be so kind as
the point out the error in my thinking.

c.

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

[parisc-linux] Re: OPD's on hppa-linux, and what to do about __cffc's fragility.

[John David Anglin]

> I'm really a stickler for nomeclature. In my mind a "resolved" plabel is
> one whose ip/gp point to the true and final function address after the ELF
> symbol resolution rules have been followed for that symbol. Is this the
> generally accepted definition? I interchangably think plabel == fptr.

I agree with the former definition regarding a resolved plabel.  I believe
that the term plabel is interchangeable with the term function descriptor.
A function pointer on the otherhand may point either directly to the
code address of the function or to a plabel.

> > > I would imagine that the main _GOT_ is supposed to override the shared
> > > library _GOT_. __cffc is only looking at the _GOT_ to get the fptr that
> > > the dynamic loader wrote there during setup, so that it can get called
> > > for symbol resolution. This setup is done for all objects, which
> > > includes all the _GOT_'s, from the application to all the loaded shared
> > > libraries.
> > 
> > If the dynamic loader always uses the main app's got for the trampoline,
> > __cffc would work for plabels in shared libraries that used lazy linking.
> 
> To clarify this, you mean to say if the loader always uses the main
> app's plt/got stub then everything would be okay. The check in __cffc to
> see if the plabel has been resolved would work (e.g. got !=
> &_GLOBAL_OFFSET_TABLE_).

Yes.

> It didn't make a difference in the past because the shared library
> plabels were already resolved? Wouldn't this mean that lazy linking
> wasn't working at all?

If shared libraries used the main app's &_GLOBAL_OFFSET_TABLE_, then
lazy linking could be working.   The testcase that I posted had a
plabel constructor in the shared library.  I recall now that the got
pointer for the plabel was the main app's &_GLOBAL_OFFSET_TABLE_.

> I don't quite understand why this broke, if someone would be so kind as
> the point out the error in my thinking.

Hiding _GLOBAL_OFFSET_TABLE_, resulted in _GLOBAL_OFFSET_TABLE_
being local to shared libraries, as a result __cffc no longer used
the main app's &_GLOBAL_OFFSET_TABLE_.

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: OPD's on hppa-linux, and what to do about __cffc's fragility.

[John David Anglin]

> A function pointer on the otherhand may point either directly to the
> code address of the function or to a plabel.

Further, there are some special function pointers like -1.

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: OPD's on hppa-linux, and what to do about __cffc's fragility.

[Alan Modra]

On Tue, Mar 08, 2005 at 04:08:51PM -0500, Carlos O'Donell wrote:
> On Tue, Mar 08, 2005 at 02:02:33PM -0500, John David Anglin wrote:
> > > > This problem was fixed yesterday by Alan Modra.
> > > 
> > > I'm not sure what you mean in your statement "shared library function
> > > pointers are resolved when the library is loaded?" The function pointers
> > > exist as two-byte entries in the PLT, and are non-unique, and they
> > > aren't resolved until call time with lazy resolution.

No, in an hppa-linux shared lib, a function pointer is accessed via a
word with a PLABEL32 reloc on it.  This reloc is processed before any
code in the shared lib runs, to point to a function descriptor created
by _dl_make_fptr.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: OPD's on hppa-linux, and what to do about __cffc's fragility.

[Carlos O'Donell]

On Wed, Mar 09, 2005 at 08:55:13AM +1030, Alan Modra wrote:
> No, in an hppa-linux shared lib, a function pointer is accessed via a
> word with a PLABEL32 reloc on it.  This reloc is processed before any
> code in the shared lib runs, to point to a function descriptor created
> by _dl_make_fptr.

In shared libraries the function pointer is also allocated a PLT slot
and an IPLT relocation. 

I don't understand the reasons for the allocation of a PLT slot if all
references generated go through the local label word that has the
PLABEL32 reloc, which now contains the address returned by
_dl_make_ftpr.

I'm still trying to understand your earlier recommendation. Do you
suggest that the executable have PLABEL32 relocs for all the symbols,
local and global, which assures that _dl_make_fptr creates a unique OPD?

Alan, thanks for your input.

c.

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

[parisc-linux] Re: OPD's on hppa-linux, and what to do about __cffc's fragility.

[Alan Modra]

On Thu, Mar 10, 2005 at 10:31:20AM -0500, Carlos O'Donell wrote:
> On Wed, Mar 09, 2005 at 08:55:13AM +1030, Alan Modra wrote:
> > No, in an hppa-linux shared lib, a function pointer is accessed via a
> > word with a PLABEL32 reloc on it.  This reloc is processed before any
> > code in the shared lib runs, to point to a function descriptor created
> > by _dl_make_fptr.
> 
> In shared libraries the function pointer is also allocated a PLT slot
> and an IPLT relocation. 
> 
> I don't understand the reasons for the allocation of a PLT slot if all
> references generated go through the local label word that has the
> PLABEL32 reloc, which now contains the address returned by
> _dl_make_ftpr.

There probably isn't a good reason.  Blame that on me not understanding
what I was doing when dhd and I hacked together ld and glibc hppa-linux
support.

> I'm still trying to understand your earlier recommendation. Do you
> suggest that the executable have PLABEL32 relocs for all the symbols,
> local and global, which assures that _dl_make_fptr creates a unique OPD?

I was really just thinking of global symbols.  If ld handles descriptors
for locals, you save on dynamic relocs and program startup time.  I
haven't spent a great deal of time thinking about it though, so it's
highly likely that there is some reason why it won't work.  eg. You
wouldn't want dynamic plabel relocs to appear in read-only sections.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Solution to OPD's in hppa-linux, including a transition plan?

[Carlos O'Donell]

On Fri, Mar 11, 2005 at 08:57:51AM +1030, Alan Modra wrote:
> > In shared libraries the function pointer is also allocated a PLT slot
> > and an IPLT relocation. 
> > 
> > I don't understand the reasons for the allocation of a PLT slot if all
> > references generated go through the local label word that has the
> > PLABEL32 reloc, which now contains the address returned by
> > _dl_make_ftpr.
> 
> There probably isn't a good reason.  Blame that on me not understanding
> what I was doing when dhd and I hacked together ld and glibc hppa-linux
> support.

I understand why you allocate a PLT slot, because function calls seem to
go through the PLT only without reference to the PLABEL32 word (in
shared libraries). This saves an indirection through the PLABEL32 word
during a call. I believe this to be what is happening, and I verfiied it
lightly.

I went through the sources again, and you made some argument in a
comment about passing "local function pointers" to other objects.

The only way to verify my ideas is to run some tests, so here is the
apparent summary.

- Executable passes local function pointer to shared object.
 = Passes the address of the PLT entry.
 = PLT entry has IPLT reloc.

- Shared object passes local function pointer to other shared object.
 = Passes the address of *(PLABEL32 word) which points to a fdesc
   made by _dl_make_fptr.
 = The PLABEL32 word has a PLABEL32 reloc.

- Shared object calls a local or global function.
 = Calls through the PLT, which has an IPLT reloc.

- Executable calls local function.
 = Jumps directly to address.

- Executable calls global function.
 = Uses dyncall on the address of hte PLT
 = PLT has IPLT reloc.

> > I'm still trying to understand your earlier recommendation. Do you
> > suggest that the executable have PLABEL32 relocs for all the symbols,
> > local and global, which assures that _dl_make_fptr creates a unique OPD?
> 
> I was really just thinking of global symbols.  If ld handles descriptors
> for locals, you save on dynamic relocs and program startup time.  I
> haven't spent a great deal of time thinking about it though, so it's
> highly likely that there is some reason why it won't work.  eg. You
> wouldn't want dynamic plabel relocs to appear in read-only sections.

I thought about this, and you are correct. Technically if the shared
object can do a comparison then the symbol must have been global, and
passed into the function.

How do I do this in a backwards compatible way?

Action
=======
If we emit a PLABEL32 reloc for all global symbols in the executable,
baring relocs in read-only sections, which I'm sure shared libraries
have the same problems, then the executable passes the address stored
in the plabel word.

Case 1:
=======
For these new executables gcc will not generate __cffc comparisons.
For new libraries gcc will not generate __cffc comparisons.

Case 2:
=======
Old executables will still pass the address of the plt entry, and
comparisons in new shared libraries will fail.

Case 3:
=======
New executables and old shared libraries will work just fine, since
__cffc will think that everything has been resolved properly and just
do comparison.

Fixes:
======
Transition all executables to use PLABEL32 relocs for global symbols,
the same as shared libraries. Keep gcc generating __cffc.
One day when all the executables have been rebuilt, we can start turning
off the generation of __cffc and "Case 2" will fail, but hopefully we
have transitioned away from that happening.

Thoughts?

Cheers,
Carlos.

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

[parisc-linux] Re: Solution to OPD's in hppa-linux, including a transition plan?

[John David Anglin]

> On Fri, Mar 11, 2005 at 08:57:51AM +1030, Alan Modra wrote:
> > > In shared libraries the function pointer is also allocated a PLT slot
> > > and an IPLT relocation. 
> > > 
> > > I don't understand the reasons for the allocation of a PLT slot if all
> > > references generated go through the local label word that has the
> > > PLABEL32 reloc, which now contains the address returned by
> > > _dl_make_ftpr.
> > 
> > There probably isn't a good reason.  Blame that on me not understanding
> > what I was doing when dhd and I hacked together ld and glibc hppa-linux
> > support.
> 
> I understand why you allocate a PLT slot, because function calls seem to
> go through the PLT only without reference to the PLABEL32 word (in
> shared libraries). This saves an indirection through the PLABEL32 word
> during a call. I believe this to be what is happening, and I verfiied it
> lightly.

I believe the PLT exists to support 'LTP and 'RTP relocations.
GCC doesn't generate these relocations as this support doesn't
work under HP-UX, although the HP-UX assembler manual describes
them.  GCC generates 32-bit plabels (deferred) when it encounters
a situation where a 'LTP/'RTP sequence would be desireable.  Thus,
we may not need the PLT slot.

I don't see that a level of indirection is being saved.  We either
go through the PLABEL32 word or the PLT.

I believe that GCC always create the PLABEL32 words in the data
section (definitely true for HP-UX) so that the word can be
successfully relocated when a shared library is loaded.

> I thought about this, and you are correct. Technically if the shared
> object can do a comparison then the symbol must have been global, and
> passed into the function.

I don't think this is correct.  It's theoretically possible to pass
two function pointers that both point to local functions in one object
and have the comparison done in another (shared) object.

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: Solution to OPD's in hppa-linux, including a transition plan?

[Carlos O'Donell]

On Wed, Mar 16, 2005 at 09:11:42AM +1030, Alan Modra wrote:
> On Tue, Mar 15, 2005 at 05:08:48PM -0500, Carlos O'Donell wrote:
> > The problem is that in a normal executable those words just point at the
> > PLT and they shouldn't. That case should just generate a PLABEL32 reloc
> > in the executable. 
> 
> ld still needs to generate function descriptors for plabels that resolve
> locally, eg. because the symbol is for a static function.

I don't understand how this case changes the situation, can you elaborate a 
bit more?

Thanks,
Carlos.


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

[parisc-linux] Re: Solution to OPD's in hppa-linux, including a transition plan?

[Carlos O'Donell]

On Tue, Mar 15, 2005 at 11:10:21PM -0500, John David Anglin wrote:
> > No. Read further, if I'm wrong please correct me.
> > 
> > The PLABEL32 contains the address of the function descriptor, while the
> > data in the PLT *is* the function descriptor. There is an extra lookup.
> > 
> > You have to load the address of the PLABEL32, load the value from there,
> > and then use that as your function descriptor. We currently *don't* do
> > this. The reason the indirection is there for PLABEL32 is such that the
> > dynamic loader can acutally assign the address of the OPD into that
> > word. 
> 
> No, I don't believe this is correct.  We do load the address
> from the PLABEL32 word.  That's the function pointer and what's
> passed to __cffc.  The problem is we don't have an OPD for the
> functions called in this manner.  We have more than one function
> descriptor for a any given function (possibly one for every
> PLABEL32 relocation).

We *do* have a n OPD for functions called in this manner, but only if
the plabel word carried a PLABEL32 reloc. The use of _dl_make_fptr
makes sure each symbol gets a unique function descriptor and will never
create duplicates.

The problem is that in the executable, we lazily point all the plabel
words at their associated plt entries and *splat* they are no longer
unique. Please note this *only* happens in the executable. Executables
do not generate PLABEL32 relocs for their plabel words.

I want to recommend that the executable emit PLABEL32 relocs against all
plabel word entries. The dynamic loader would then fill these entries
with unique OPD's as it has done so for shared libraries (this code was
originall wirtten by Bame et. al. and I ported hppa to use Lu's
non-locking generic version).
 
> On hppa64-hpux, we use essentially the same code to load function
> pointers from FPTR64 double words.  There we don't need to
> canonicalize the pointers because they point to the OPD for the
> function.

Sure, but the hpux libc probably does all the work to make sure that the
plabel words point to OPD's even for the executable :)

> > The problem is that in a normal executable those words just point at the
> > PLT and they shouldn't. That case should just generate a PLABEL32 reloc
> > in the executable. 
> > 
> > Do I understand the code correctly?
> 
> I think the situation envisioned in the parisc elf specification
> always envisioned a two level lookup.  In the relocations defined
> for 32-bit elf, the only way to load the address of a function
> descriptor is using the PLABEL32 relocation.  The 64-bit elf
> table also provides the LTOFF_FPTR21L and LTOFF_FPTR14R relocations.
> In this case, I believe that code has to load the address of the function
> descriptor from the linkage table, so it's still a two level lookup.

Yes, correct, I agree. Loading the *address* of a function descriptor
always requires a PLABEL32 reloction. The PLABEL32 reloction is handled
by the dynamic loader, which creates the OPD, and places the address of
the OPD into the plabel word.

Yes, as long as LTOFF_FTPR* load the address of the descriptor from the
linkage table (plt) then the system still works.

Hence, why I suggest executables also use PLABEL32 relocs if they take
the address of a function.

> The 32-bit ABI has the complication of the plabel bit in the function
> pointer.  While it might be possible to directly load the address
> of the function descriptor with an addil/ldo sequence if suitable
> relocations existed, saving one memory access, the code would still
> have to call $$dyncall or perform equivalent operations inline to
> test and strip off the plabel bit.

Yes, calling a function descriptor will always involve clearing the
plabel bit. I don't quite understand the performance gain to be made in
detecting that the plabel word contained a local address as opposed to a
function descriptor?

Yes, with a new relocation it *might* be possible to load the function
descriptor address directly from the plabel word, but as you say it 
would require writing into the code to change offsets?

> There are several disadvantages in the approach.  Plabels and linkage
> table entries can be shared for many calls to a given function.  Thus,
> the dynamic loader probably has an easier job doing the relocations.
> Also, I think that relocations might have to be redone (at least under
> hpux) when shared libraries are dynamically loaded by an application.
> This would require that the dynamic loader have the capability to
> write to code space after a program has started execution.  This is
> probably a security risk, particularly for shared libraries that are
> not privately mapped.  As I noted previously, the plabel words have
> to go in a read/write section because of this issue.

Do you really mean "disadvantages?"

Can you explain how plabels and plt entries can be shared for many calls
to a given function?

Are we still talking about the new reloc that could load the function
descriptor address directly?

Yes, plabel words go in read/write since they are written to by the
dynamic loader (only if they have a PLABEL32 reloc though).

---

This has definately been a good learning discussion, from the viewpoint
of optimal schemes for this type of architecture :)

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

[parisc-linux] Re: Solution to OPD's in hppa-linux, including a transition plan?

[Alan Modra]

On Wed, Mar 16, 2005 at 03:36:57PM -0500, Carlos O'Donell wrote:
> On Wed, Mar 16, 2005 at 09:11:42AM +1030, Alan Modra wrote:
> > On Tue, Mar 15, 2005 at 05:08:48PM -0500, Carlos O'Donell wrote:
> > > The problem is that in a normal executable those words just point at the
> > > PLT and they shouldn't. That case should just generate a PLABEL32 reloc
> > > in the executable. 
> > 
> > ld still needs to generate function descriptors for plabels that resolve
> > locally, eg. because the symbol is for a static function.
> 
> I don't understand how this case changes the situation, can you elaborate a 
> bit more?

If you take the address of a static function (or a hidden function),
you'll need a plabel somewhere.  You can't expect ld.so to handle this
via _dl_make_fptr, because the static function symbol isn't available to
ld.so.  Also, don't forget that ld needs to do everything for a fully
static link.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre
_______________________________________________
parisc-linux mailing list
parisc-linux@lists.parisc-linux.org
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

[parisc-linux] Re: Solution to OPD's in hppa-linux, including a transition plan?

[John David Anglin]

> We *do* have a n OPD for functions called in this manner, but only if
> the plabel word carried a PLABEL32 reloc. The use of _dl_make_fptr
> makes sure each symbol gets a unique function descriptor and will never
> create duplicates.
> 
> The problem is that in the executable, we lazily point all the plabel
> words at their associated plt entries and *splat* they are no longer
> unique. Please note this *only* happens in the executable. Executables
> do not generate PLABEL32 relocs for their plabel words.
> 
> I want to recommend that the executable emit PLABEL32 relocs against all
> plabel word entries. The dynamic loader would then fill these entries
> with unique OPD's as it has done so for shared libraries (this code was
> originall wirtten by Bame et. al. and I ported hppa to use Lu's
> non-locking generic version).

I think you are correct.  I hadn't realized that we are only dropping
the PLABEL32 in executables.

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: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> > I think gcc is to blame, or the constraints in the assembly?
> > 
> > --- GCC 4.0 ---
> > 
> > 0x40349890 <feclearexcept+0>:   ldo 40(sp),sp
> > 0x40349894 <feclearexcept+4>:   ldo -38(sp),ret0
> > 0x40349898 <feclearexcept+8>:   stw r19,-20(,sp)
> > 0x4034989c <feclearexcept+12>:  fstd fr0,0(,ret0)
> > 0x403498a0 <feclearexcept+16>:  fldd 0(,ret0),fr0
> > 0x403498a4 <feclearexcept+20>:  ldi 0,ret0
> > 0x403498a8 <feclearexcept+24>:  bv r0(rp)
> > 0x403498ac <feclearexcept+28>:  ldo -40(sp),sp
> 
> PR time.  Please add danglin@gcc.gnu.org to the CC list.

Changed my mind.  It's not a GCC bug.  The second asm has to show that
it uses the memory set by the first:

#include <fenv.h>

int
feclearexcept (int excepts)
{
  struct { unsigned int sw[2]; } s;

  /* Get the current status word. */
  __asm__ volatile ("fstd %%fr0,0(%1)" : "=m" (s) : "r" (&s));

  /* Clear all the relevant bits. */
  s.sw[0] &= ~((excepts & FE_ALL_EXCEPT) << 27);
  __asm__ volatile ("fldd 0(%0),%%fr0" : : "r" (&s), "m" (s));

  /* Success.  */
  return 0;
}

I used a struct so that GCC would know exactly what memory was affected.

There is one other issue that I'm not sure about.  I presume that you
used fldd to access the floating-point status register to avoid the
situation where a floating-point identify instruction has been previously
been executed and the status register is in format three.  It's not
clear from the arch whether the fldd returns the result of the identify
or not.

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: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Fri, Jul 15, 2005 at 10:55:26PM -0400, John David Anglin wrote:
> > PR time.  Please add danglin@gcc.gnu.org to the CC list.
> 
> Changed my mind.  It's not a GCC bug.  The second asm has to show that
> it uses the memory set by the first:

Ah, thank you for the clarification. I'll try to examine the rest of
them and cleanup the assembly.
 
> #include <fenv.h>
> 
> int
> feclearexcept (int excepts)
> {
>   struct { unsigned int sw[2]; } s;
> 
>   /* Get the current status word. */
>   __asm__ volatile ("fstd %%fr0,0(%1)" : "=m" (s) : "r" (&s));
> 
>   /* Clear all the relevant bits. */
>   s.sw[0] &= ~((excepts & FE_ALL_EXCEPT) << 27);
>   __asm__ volatile ("fldd 0(%0),%%fr0" : : "r" (&s), "m" (s));
> 
>   /* Success.  */
>   return 0;
> }
> 
> I used a struct so that GCC would know exactly what memory was affected.
> 
> There is one other issue that I'm not sure about.  I presume that you
> used fldd to access the floating-point status register to avoid the
> situation where a floating-point identify instruction has been previously
> been executed and the status register is in format three.  It's not
> clear from the arch whether the fldd returns the result of the identify
> or not.

Who previously executed the COPR,0,0?

I use the fldd to set the new cleared state of the status register.

If the thread had previously executed 'fstd' followed by a 'copr,0,0'
and had not immediately thereafter executed another 'fstd' then the
operation is *undefined* as per PA 1.1 6-63.

Context switching should save and restore the states properly for this
to work.

I think the arch is very clear about the issue, but perhaps I'm
misreading something. Do you have a case where the above wouldn't work?

c.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> Who previously executed the COPR,0,0?

I dunno, incorrect identify sequence?  I agree the 1.1 arch is specific
about how to do an identify sequence.

> I use the fldd to set the new cleared state of the status register.

I had been wondering if fstw and fldw could be used, but it's an
undefined operation to set T with fldw and fstd clears T, so I believe
your use of fstd and fldd is correct in this sequence.

However, you have to be careful in using fstd to get the fp status
register as it clears T after the insn.

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: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> However, you have to be careful in using fstd to get the fp status
> register as it clears T after the insn.

And, indeed the following is wrong for the above reason:

#include <fenv.h>

int
fetestexcept (int excepts)
{
  unsigned int sw[2];

  /* Get the current status word. */
  __asm__ ("fstd %%fr0,0(%1)" : "=m" (*sw) : "r" (sw));

  return (sw[0] >> 27) & excepts & FE_ALL_EXCEPT;
}

You need to add a 'fldd' to the asm to restore the T bit.  Another
option might be to use fstw to access the status register in this
situation.

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: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Sat, Jul 16, 2005 at 01:37:50PM -0400, John David Anglin wrote:
> > Who previously executed the COPR,0,0?
> 
> I dunno, incorrect identify sequence?  I agree the 1.1 arch is specific
> about how to do an identify sequence.
 
There is no way to prevent this. An application can always shoot itself
in the foot.

And since the identify sequence should be written in assembly the
compiler can't schedule it around.

It should also be save to execute such a sequence at any point in the
insn stream.

> > I use the fldd to set the new cleared state of the status register.
> 
> I had been wondering if fstw and fldw could be used, but it's an
> undefined operation to set T with fldw and fstd clears T, so I believe
> your use of fstd and fldd is correct in this sequence.

I have to read this again to make sure I did it all right.

> However, you have to be careful in using fstd to get the fp status
> register as it clears T after the insn.

Yes, I might have some mistakes there.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[Carlos O'Donell]

On Sat, Jul 16, 2005 at 01:54:48PM -0400, John David Anglin wrote:
> > However, you have to be careful in using fstd to get the fp status
> > register as it clears T after the insn.
> 
> And, indeed the following is wrong for the above reason:
> 
> #include <fenv.h>
> 
> int
> fetestexcept (int excepts)
> {
>   unsigned int sw[2];
> 
>   /* Get the current status word. */
>   __asm__ ("fstd %%fr0,0(%1)" : "=m" (*sw) : "r" (sw));
> 
>   return (sw[0] >> 27) & excepts & FE_ALL_EXCEPT;
> }
> 
> You need to add a 'fldd' to the asm to restore the T bit.  Another
> option might be to use fstw to access the status register in this
> situation.

I'm going to test the use of fstw.

fegetexcept, fegetround also need this fix (maybe more).

There is another potential bug, I should make sure the fr0 restore is
always at the end too incase it rearms a trap.

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

Re: [parisc-linux] Re: Non-inline math, and inline math broken, GCC to blame? (1 hppa tls toolchain regression).

[John David Anglin]

> There is another potential bug, I should make sure the fr0 restore is
> always at the end too incase it rearms a trap.

hpux uses two little hand-coded functions to avoid this problem.  The
get operation uses fstd but it immediately restores the previous status
value with fldd.  The put does the restore in the delay slot of the return.

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: gsyprf11 and 2.6.13-rc3-pa1

[John David Anglin]

> > static void sighandler(int sig)
> > {
> >         printf("Got signal %d\n", sig);
> >         exit(0);
> 
> I think you need to use _exit in a signal handler although this may
> not be an issue when there is only one thread.

GCC uses exit.  Either way, the kernel shouldn't hang.

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] strtold

[John David Anglin]

With libc6 2.3.5-8:

#include <stdlib.h>
int
main ()
{
  printf ("%Lf\n", strtold ("1", NULL));
    return 0;
}

dave@gsyprf11:~/gcc_test$ gcc -o ld1 ld1.c
dave@gsyprf11:~/gcc_test$ ./ld1
0.000000

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: nscd: error while loading shared libraries: unexpected reloc type 0x42

[John David Anglin]

> So they must come from an asm or assembly code.  I think libc used this
> reloc for loading the address of the function descriptor of main.

objdump -R nscd
...
00005970 R_PARISC_PLABEL21L  main
00005974 R_PARISC_PLABEL14R  main
00005980 R_PARISC_PLABEL21L  __libc_csu_init
00005984 R_PARISC_PLABEL14R  __libc_csu_init
00005988 R_PARISC_PLABEL21L  __libc_csu_fini
0000598c R_PARISC_PLABEL14R  __libc_csu_fini

If I recall correctly, there was a dynamic loader fix to handle these
relocations.  However, it doesn't seem to be in libc6 2.3.5-8.

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: strtold

[Carlos O'Donell]

On Mon, Dec 26, 2005 at 02:58:40PM -0500, John David Anglin wrote:
> With libc6 2.3.5-8:
> 
> #include <stdlib.h>
> int
> main ()
> {
>   printf ("%Lf\n", strtold ("1", NULL));
>     return 0;
> }
> 
> dave@gsyprf11:~/gcc_test$ gcc -o ld1 ld1.c
> dave@gsyprf11:~/gcc_test$ ./ld1
> 0.000000

strtold will never work, gcc and libc have different sizes for long
double. This is probably a side-effect of this.

If we really want long double to work we need to do something like set
it to be the same as double.

128-bit long double is just going to be a pain, and I don't know how
well the 80-bit long double from IBM supports IEEE modes.

c.

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

[parisc-linux] Re: strtold

[John David Anglin]

> strtold will never work, gcc and libc have different sizes for long
> double. This is probably a side-effect of this.

I'm not sure what has changed but this is the source of a number
of gfortran and libstdc++ regressions when using the current version
of libc in unstable.

> If we really want long double to work we need to do something like set
> it to be the same as double.

Long double has always been the same as double in GCC.  It allowed
by the C and C++ standards.  It fast and the hardware and corner
cases are well understood.

I've given up hope that HP will release their IEEE long double emulation
code for PA-RISC.  Although I don't have any hard evidence of bugs in it,
there is the suggestion from the ada testsuite run under hpux that there
may be bugs in the rounding and exception support.

> 128-bit long double is just going to be a pain, and I don't know how
> well the 80-bit long double from IBM supports IEEE modes.

The only viable alternatives at this point are:

  1) long double == double (64 bit long double), or
  2) IBM 128-bit double double implementation used by powerpc.

After more than a year of using the double-double format, the powerpc
folks are still working the bugs out from the corner cases.  While I
guess it more or less works, I wouldn't want to rely on it for
critical calculations.  RTH recented indicated that this would be a
poor choice for another port in the same situation.  The same viewpoint
was expressed to me by an Ada maintainer at the last GCC summit.  Ada
probably has the best numerics support in GCC.

There is no support for the 80-bit format (either in hardware or
software) on PA-RISC as far as I know.  So, this alternative isn't viable.

C99 requires long double support.  Thus, I believe we should go with
option 1 and libc should be changed.  We aren't the only target with
this problem, so there must be some libc support for 64-bit long double.

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: strtold

[Carlos O'Donell]

On Sat, Jan 07, 2006 at 05:41:52PM -0500, John David Anglin wrote:
> > strtold will never work, gcc and libc have different sizes for long
> > double. This is probably a side-effect of this.
> 
> I'm not sure what has changed but this is the source of a number
> of gfortran and libstdc++ regressions when using the current version
> of libc in unstable.

strold has always done funny things in the glibc testsuite, consider
yourself lucky.
 
> > If we really want long double to work we need to do something like set
> > it to be the same as double.
> 
> Long double has always been the same as double in GCC.  It allowed
> by the C and C++ standards.  It fast and the hardware and corner
> cases are well understood.

So long doubles have always been DFmode in GCC, okay, I thought it was
something else.

glibc thinks long double is 128-bit. If you want strtold to work then I
need to make the changes in glibc.

> I've given up hope that HP will release their IEEE long double emulation
> code for PA-RISC.  Although I don't have any hard evidence of bugs in it,
> there is the suggestion from the ada testsuite run under hpux that there
> may be bugs in the rounding and exception support.

I agree, I don't think it will ever be released. If it is released then
we'll jigger it out some other way :)

> > 128-bit long double is just going to be a pain, and I don't know how
> > well the 80-bit long double from IBM supports IEEE modes.
> 
> The only viable alternatives at this point are:
> 
>   1) long double == double (64 bit long double), or
>   2) IBM 128-bit double double implementation used by powerpc.

Or write our own library! ;-)

> After more than a year of using the double-double format, the powerpc
> folks are still working the bugs out from the corner cases.  While I
> guess it more or less works, I wouldn't want to rely on it for
> critical calculations.  RTH recented indicated that this would be a
> poor choice for another port in the same situation.  The same viewpoint
> was expressed to me by an Ada maintainer at the last GCC summit.  Ada
> probably has the best numerics support in GCC.

I say we go for (1).

> There is no support for the 80-bit format (either in hardware or
> software) on PA-RISC as far as I know.  So, this alternative isn't viable.

Okay.

> C99 requires long double support.  Thus, I believe we should go with
> option 1 and libc should be changed.  We aren't the only target with
> this problem, so there must be some libc support for 64-bit long double.

I believe it will only require removing the implies line for ldbl-128
from glibc.

I am building you a new debian glibc based on 2.3.5-8 for you to test,
would this be good?

c.

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

[parisc-linux] Re: strtold

[John David Anglin]

> I believe it will only require removing the implies line for ldbl-128
> from glibc.

Excellent.

> I am building you a new debian glibc based on 2.3.5-8 for you to test,
> would this be good?

Yes.

Do you also have a fix for FP exception support?

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: nscd: error while loading shared libraries: unexpected reloc type 0x42

[Carlos O'Donell]

On Mon, Dec 26, 2005 at 04:54:42PM -0500, John David Anglin wrote:
> > So they must come from an asm or assembly code.  I think libc used this
> > reloc for loading the address of the function descriptor of main.
> 
> objdump -R nscd
> ...
> 00005970 R_PARISC_PLABEL21L  main
> 00005974 R_PARISC_PLABEL14R  main
> 00005980 R_PARISC_PLABEL21L  __libc_csu_init
> 00005984 R_PARISC_PLABEL14R  __libc_csu_init
> 00005988 R_PARISC_PLABEL21L  __libc_csu_fini
> 0000598c R_PARISC_PLABEL14R  __libc_csu_fini
> 
> If I recall correctly, there was a dynamic loader fix to handle these
> relocations.  However, it doesn't seem to be in libc6 2.3.5-8.

It is in the one I have installed on my system :)

The proper fix was this:
http://cvs.parisc-linux.org/glibc/sysdeps/hppa/elf/start.S?r1=1.2&r2=1.3

Please verify.

c.

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

[parisc-linux] Re: strtold

[John David Anglin]

> So long doubles have always been DFmode in GCC, okay, I thought it was
> something else.

linux long doubles are DFmode (hardware+kernel support).  hpux long
doubles are TFmode (software emulation).  Sometimes I wish there was
an option to switch between hardware and software long doubles on
hpux.

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: nscd: error while loading shared libraries:

[John David Anglin]

> The proper fix was this:
> http://cvs.parisc-linux.org/glibc/sysdeps/hppa/elf/start.S?r1=1.2&r2=1.3
> 
> Please verify.

Looks right.

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: strtold

[Grant Grundler]

On Sat, Jan 07, 2006 at 06:42:30PM -0500, Carlos O'Donell wrote:
...
> > I've given up hope that HP will release their IEEE long double emulation
> > code for PA-RISC.  Although I don't have any hard evidence of bugs in it,
> > there is the suggestion from the ada testsuite run under hpux that there
> > may be bugs in the rounding and exception support.
> 
> I agree, I don't think it will ever be released. If it is released then
> we'll jigger it out some other way :)

Me too. But I wouldn't worry about an ABI event too much.
As long as the only dependency is debian/gentoo packages,
then I think we can tolerate an ABI event like this on the
next OS release if necessary.

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

[parisc-linux] long double on hppa64-*-linux*

[John David Anglin]

I noticed another long double issue.  Long double is defined to be 128
bits on all 64-bit targets on the PA.  I believe that it should be 128 bits
only on hpux.

I would like to change the long double default on PA64t o 64 bits as there
isn't any hardware support for the 128-bit type, and we currently don't
have software support for 128-bit long doubles implemented.  I can't see
this affecting anything, but it's another ABI change and I thought I should
ask.

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] long double on hppa64-*-linux*

[Grant Grundler]

On Sat, Feb 04, 2006 at 06:41:00PM -0500, John David Anglin wrote:
> I noticed another long double issue.  Long double is defined to be 128
> bits on all 64-bit targets on the PA.  I believe that it should be 128 bits
> only on hpux.
> 
> I would like to change the long double default on PA64t o 64 bits as there
> isn't any hardware support for the 128-bit type, and we currently don't
> have software support for 128-bit long doubles implemented.  I can't see
> this affecting anything, but it's another ABI change and I thought I should
> ask.

I'm ok with it. The only downside I can think of is hypothetical:
supporting HPUX binaries with "long double" on parisc-linux hmight get
interesting should any misaligned trap handlers or syscalls need to deal
with long double.

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

Re: [parisc-linux] long double on hppa64-*-linux*

[John David Anglin]

> I'm ok with it. The only downside I can think of is hypothetical:
> supporting HPUX binaries with "long double" on parisc-linux hmight get
> interesting should any misaligned trap handlers or syscalls need to deal
> with long double.

The HPUX support uses various _U routines from libc.  I'm not sure
if any kernel support is involved.  Possibly, some support is needed
to handle exceptions.  This is all vague since as far as I know the
_U routines are not publicly documented.  I don't believe there is kernel
support for the quad instructions in the PA 2.0 arch.  There's no
math library support for long doubles in HPUX.  As it seems HP won't
release the _U code, only static HPUX binaries using long double would
have any chance of running on parisc-linux.  So, I'm not sure being
able to run HPUX binaries with "long double" would ever prove particularly
useful.

As things currently stand on hppa64-*-linux*, any arithmetic involving
long doubles results in a call to a libgcc stub that calls abort.

It looks as glibc 2.4 potentially provides 128-bit long double support
as an option.  See patch to make -mlong-double-128 the default:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01958.html
The other option is the hardware support -mlong-double-64.

I'm fairly sure that the -mlong-double-128 format (except for a few
architectures) is similar to the rs6000 darwin long double format
(i.e., it's not compatible with the PA 2.0 format, IEEE quad).  It
might not be that much work to copy the rs6000 implementation.

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] User space locks -- what's wrong

[John David Anglin]

> There definitely are some funky things going on in the kernel.
> For example, if I try to build GCC with 'make -j 4 bootstrap' on
> gsyprf11, about 50% of the time make dies because of a malloc data
> corruption or a shell problem.  However, I never see this with
> just 'make bootstrap'.

This is an example:

/home/dave/gcc-4.2/objdir/./prev-gcc/xgcc -B/home/dave/gcc-4.2/objdir/./prev-gcc
/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -c   -g -O2 -DIN_GCC   -W -
Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-lon
g-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmis
sing-format-attribute -Werror -fno-common   -DHAVE_CONFIG_H -I. -I. -I../../gcc/
gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/inclu
de  -I../../gcc/gcc/../libdecnumber -I../libdecnumber    ../../gcc/gcc/c-typeck.
c -o c-typeck.o
/bin/sh: line 6: 24262 Segmentation fault      (core dumped) make "DESTDIR=" "RP
ATH_ENVVAR=LD_LIBRARY_PATH" "TARGET_SUBDIR=hppa-linux" "bindir=/home/dave/opt/gn
u/gcc/gcc-4.2.0/bin" "datadir=/home/dave/opt/gnu/gcc/gcc-4.2.0/share" "exec_pref
ix=/home/dave/opt/gnu/gcc/gcc-4.2.0" "includedir=/home/dave/opt/gnu/gcc/gcc-4.2.
0/include" "datarootdir=/home/dave/opt/gnu/gcc/gcc-4.2.0/share" "docdir=/home/da
ve/opt/gnu/gcc/gcc-4.2.0/share/doc" "infodir=/home/dave/opt/gnu/gcc/gcc-4.2.0/in
fo" "htmldir=/home/dave/opt/gnu/gcc/gcc-4.2.0/share/doc" "libdir=/home/dave/opt/
gnu/gcc/gcc-4.2.0/lib" "libexecdir=/home/dave/opt/gnu/gcc/gcc-4.2.0/libexec" "li
spdir=" "localstatedir=/home/dave/opt/gnu/gcc/gcc-4.2.0/var" "mandir=/home/dave/
opt/gnu/gcc/gcc-4.2.0/man" "oldincludedir=/usr/include" "prefix=/home/dave/opt/g
nu/gcc/gcc-4.2.0" "sbindir=/home/dave/opt/gnu/gcc/gcc-4.2.0/sbin" "sharedstatedi
r=/home/dave/opt/gnu/gcc/gcc-4.2.0/com" "sysconfdir=/home/dave/opt/gnu/gcc/gcc-4
.2.0/etc" "tooldir=/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux" "build_tooldir=/
home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux" "target_alias=hppa-linux" "BISON=bis
on" "CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=c++" "EXPECT=/ho
me/dave/opt/gnu/bin/expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_D
ATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_S
CRIPT=/usr/bin/install -c" "LEX=flex" "M4=m4" "MAKE=make" "RUNTEST=runtest" "RUN
TESTFLAGS=" "SHELL=/bin/sh" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][
^=]*=$/XFOO=/'`" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=' | sed -e s'/[^=][^=]*=$/X
FOO=/'`" "BOOT_CFLAGS=-g -O2" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2"
"LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "STAG
E1_CFLAGS=-g" "STAGE1_LANGUAGES=c,ada" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as" "CC
_FOR_TARGET=/home/dave/gcc-4.2/objdir/./gcc/xgcc -B/home/dave/gcc-4.2/objdir/./g
cc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/
gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/i
nclude -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-include" "CFLAGS
_FOR_TARGET=-O2 -g -O2 " "CPPFLAGS_FOR_TARGET=" "CXX_FOR_TARGET=/home/dave/gcc-4
.2/objdir/./gcc/g++ -B/home/dave/gcc-4.2/objdir/./gcc/ -nostdinc++  -L/home/dave
/gcc-4.2/objdir/hppa-linux/libstdc++-v3/src -L/home/dave/gcc-4.2/objdir/hppa-lin
ux/libstdc++-v3/src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/
home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/
gcc-4.2.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linu
x/sys-include" "CXXFLAGS_FOR_TARGET=-g -O2  -D_GNU_SOURCE" "DLLTOOL_FOR_TARGET=d
lltool" "GCJ_FOR_TARGET=/home/dave/gcc-4.2/objdir/./gcc/gcj -B/home/dave/gcc-4.2
/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/dave/o
pt/gnu/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/h
ppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys-inclu
de" "GFORTRAN_FOR_TARGET=/home/dave/gcc-4.2/objdir/./gcc/gfortran -B/home/dave/g
cc-4.2/objdir/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/bin/ -B/home/
dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4
.2.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/sys
-include" "LD_FOR_TARGET=ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCF
LAGS_FOR_TARGET=-O2 -g -O2 " "LIBCXXFLAGS_FOR_TARGET=-g -O2  -D_GNU_SOURCE -fno-
implicit-templates" "NM_FOR_TARGET=nm" "OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_
TARGET=ranlib" "STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" "`echo 'LAN
GUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "CONFIG_SHELL=/bin/sh" "
MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000
" 'AR=ar' 'AS=as' 'CC=gcc' 'CXX=c++' 'DLLTOOL=dlltool' 'LD=ld' 'LIPO=lipo' 'NM=n
m' 'OBJDUMP=objdump' 'RANLIB=ranlib' 'STRIP=strip' 'WINDRES=windres' CC="${CC}"
CC_FOR_BUILD="${CC_FOR_BUILD}" STAGE_PREFIX=$r/prev-gcc/ CFLAGS="-g -O2" LIBCFLA
GS="-g -O2" LDFLAGS="" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "GCC
_FOR_TARGET= $r/./gcc/xgcc -B$r/./gcc/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-l
inux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.2.0/hppa-linux/lib/ -isystem /home/dave
/opt/gnu/gcc/gcc-4.2.0/hppa-linux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.
2.0/hppa-linux/sys-include" "`echo 'STMP_FIXPROTO=' | sed -e s'/[^=][^=]*=$/XFOO
=/'`" "`echo 'LIMITS_H_TEST=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "`echo 'LIBGCC2_
CFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "`echo 'LIBGCC2_DEBUG_CFLAGS=' | sed
-e s'/[^=][^=]*=$/XFOO=/'`" "`echo 'LIBGCC2_INCLUDES=' | sed -e s'/[^=][^=]*=$/X
FOO=/'`" `if [ -f stage_last ]; then echo quickstrap ; else echo all; fi`
make[2]: *** [all-stage2-gcc] Error 139
make[2]: Leaving directory `/home/dave/gcc-4.2/objdir'
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory `/home/dave/gcc-4.2/objdir'
make: *** [bootstrap] Error 2
make: INTERNAL: Exiting with 1 jobserver tokens available; should be 4!
Wed Jun  7 20:19:18 PDT 2006

>>From /var/log/debug:

Jun  7 20:19:18 gsyprf11 kernel: do_page_fault() pid=24262 command='make' type=1
5 address=0x1118498f
Jun  7 20:19:18 gsyprf11 kernel: vm_start = 0x00048000, vm_end = 0x00607000
Jun  7 20:19:18 gsyprf11 kernel:
Jun  7 20:19:18 gsyprf11 kernel:      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
Jun  7 20:19:18 gsyprf11 kernel: PSW: 00000000000001000000000000001111 Not taint
ed
Jun  7 20:19:18 gsyprf11 kernel: r00-03  0000000000000000 00000000000476e8 00000
00000029b03 00000000bff07800
Jun  7 20:19:18 gsyprf11 kernel: r04-07  000000000009b268 0000000000000000 00000
0000010fe80 00000000000d8680
Jun  7 20:19:18 gsyprf11 kernel: r08-11  00000000000d8680 0000000000000000 00000
0000010fe80 0000000000000000
Jun  7 20:19:18 gsyprf11 kernel: r12-15  000000000009b1f0 0000000000000000 00000
00000000014 0000000000000000
Jun  7 20:19:18 gsyprf11 kernel: r16-19  0000000000000001 0000000000000001 00000
000000476e8 0000000000000000
Jun  7 20:19:18 gsyprf11 kernel: r20-23  00000000001dfca0 0000000000000000 00000
000c0000003 0000000000000000
Jun  7 20:19:18 gsyprf11 kernel: r24-27  0000000000000001 0000000000000016 00000
000001dfca0 00000000000466e8
Jun  7 20:19:18 gsyprf11 kernel: r28-31  0000000011184943 0000000040000003 00000
00003bd6800 0000000003bd6800
Jun  7 20:19:18 gsyprf11 kernel:
Jun  7 20:19:18 gsyprf11 kernel: IASQ: 0000000003bd6800 0000000003bd6800 IAOQ: 0
000000000029aa3 0000000000029aa7
Jun  7 20:19:18 gsyprf11 kernel:  IIR: 4b930098    ISR: 0000000003bd6800  IOR: 0
00000001118498f
Jun  7 20:19:18 gsyprf11 kernel:  CPU:        1   CR30: 000000001abb0000 CR31: 0
000000000008020
Jun  7 20:19:18 gsyprf11 kernel:  ORIG_R28: 0000000000000000
Jun  7 20:19:18 gsyprf11 kernel:  IAOQ[0]: 0x29aa3
Jun  7 20:19:18 gsyprf11 kernel:  IAOQ[1]: 0x29aa7
Jun  7 20:19:18 gsyprf11 kernel:  RP(r2): 0x29b03

dave@hiauly6:~/opt/gnu/bin$ disasm 0x4b930098
   0:   4b 93 00 98     ldw 4c(ret0),r19

(gdb) disass 0x29a90 0x29ab0
Dump of assembler code from 0x29a90 to 0x29ab0:
0x00029a90 <close_stdout+25828>:        copy ret0,r20
0x00029a94 <close_stdout+25832>:        ldw 48(r20),ret0
0x00029a98 <close_stdout+25836>:        cmpiclr,<> 0,ret0,r0
0x00029a9c <close_stdout+25840>:        copy r20,ret0
0x00029aa0 <close_stdout+25844>:        ldw 4c(ret0),r19

%ret0 is both misaligned and appears outside the VM range for the application.

The backtrace isn't particularly enlightening (need debug version of make).

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: PA8800 Status (Happy New Year)

[John David Anglin]

> Bad Address (null pointer deref?): Code=15 regs=0000000245b4f590 (Addr=00000625733a213a)
> 
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00001000000001001011110100001111 Not tainted
> r00-03  000000ff0804bd0f 000000004050f8c0 0000000040311010 0000000084f664ff
> r04-07  00000000405038c0 0000000000000002 0000000084f664c1 000000007fe0a000
> r08-11  0000000000000000 000000007fe0a000 00000000000002b1 000000007ea85600
> r12-15  000000004f2241c0 000000007e96c000 000000007fe0a000 0000000000000040
> r16-19  0000000000000000 000000007fe0a494 000000007ad0b012 00000000404ba2d4
> r20-23  3c353e25733a2046 000000004050f8c0 000000007fe0a000 0000000000000000
> r24-27  0000000084f664c1 0000000000013c43 0000000078340400 00000000405038c0
> r28-31  0000000000000003 0000000245b4f560 0000000245b4f590 00000000404ba2c0
> sr00-03  0000000001436800 0000000000000000 0000000000000000 0000000001436800
> sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
> 
> IASQ: 0000000000000000 0000000000000000 IAOQ: 000000004031104c 0000000040311050
>  IIR: 4a9c01e8    ISR: 000000003c353800  IOR: 00000625733a213a
>  CPU:        0   CR30: 0000000241ee0000 CR31: 00000000404c4000
>  ORIG_R28: 00000054000000c8
>  IAOQ[0]: ip_route_input+0xb4/0xca8
>  IAOQ[1]: ip_route_input+0xb8/0xca8
>  RP(r2): ip_route_input+0x78/0xca8
> Kernel panic - not syncing: Bad Address (null pointer deref?)
>  <0>Rebooting in 5 seconds..

The code seems to be:

    40311008:   eb fe ac 25     b,l 4030e620 <rt_hash_code>,rp
    4031100c:   0b 97 02 28     and r23,ret0,r8
    40311010:   08 04 02 5b     copy r4,dp
    40311014:   2b 63 20 00     addil L%7000,dp,r1
    40311018:   50 3f 04 f0     ldd 278(r1),r31
    4031101c:   0f e0 10 d3     ldd 0(r31),r19
    40311020:   0e 7c 20 dc     ldd,s ret0(r19),ret0
    40311024:   9f 80 22 00     cmpb,*= r0,ret0,4031112c <ip_route_input+0x194>
    40311028:   2b 66 00 00     addil L%c000,dp,r1
    4031102c:   08 1c 02 54     copy ret0,r20
    40311030:   50 33 0e a0     ldd 750(r1),r19
    40311034:   e8 00 00 20     b,l 4031104c <ip_route_input+0xb4>,r0
    40311038:   08 01 02 55     copy r1,r21
    4031103c:   37 9c 00 02     ldo 1(ret0),ret0
    40311040:   6a 7c 00 70     stw ret0,38(r19)
    40311044:   0e 80 10 d4     ldd 0(r20),r20
    40311048:   9e 80 21 ba     cmpb,*=,n r0,r20,4031112c <ip_route_input+0x194>
    4031104c:   4a 9c 01 e8     ldw f4(r20),ret0

It seems like there must be some way to get to 4031104c avoiding the
on r20/ret0.  Don't see any branches to the region between 40311024
and 40311044 in the function, or any other direct branches to 4031104c.

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: PA8800 Status (Happy New Year)

[John David Anglin]

> expect (pid 20348): Protection id trap (code 27)
> Backtrace:
>       _______________________________
>      < Your System ate a SPARC! Gah! >

It looks like show_stack is broken.

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: call_init in libc6 2.3.6.ds1-11

[John David Anglin]

> /* The test for "addr & 2" below is to accomodate old binaries which
>    violated the ELF ABI by pointing DT_INIT and DT_FINI at a function
>    descriptor.  */
> #define DL_DT_INIT_ADDRESS(map, addr) \
>   ((Elf32_Addr)(addr) & 2 ? (addr) : DL_AUTO_FUNCTION_ADDRESS (map, addr))

This is the ia64 define:

#define DL_DT_INIT_ADDRESS(map, addr) DL_AUTO_FUNCTION_ADDRESS (map, addr)

Calls to init on ia64 always use a function descriptor.

While it's possible that DT_INIT and DT_FINI shouldn't point at function
descriptors, the above hack can't be right since DL_DT_INIT_ADDRESS is used
for calling init() from dl-init.c:

      init_t init = (init_t) DL_DT_INIT_ADDRESS
	(l, l->l_addr + l->l_info[DT_INIT]->d_un.d_ptr);

      /* Call the function.  */
      init (argc, argv, env);

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] 2.6.23-rc5 warnings

[John David Anglin]

Thumbs down on 2.6.23-rc5.  I had segmentation faults in tools like
'make' twice in a row.  Back to 2.6.22.6.

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: X won't start with VisEG and 2.6.22.19

[John David Anglin]

> > Tracing with gdb gives the following:
> > 
> > Breakpoint 1, fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8)
> >      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
> > 256     }
> > (gdb) p *set
> > $1 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
> > xoffset = 0, yoffset = 0,
> >    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
> > msb_right = 0}, green = {offset = 0,
> >      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
> > msb_right = 0}, transp = {offset = 0,
> >      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
> > width = 0, accel_flags = 0,
> >    pixclock = 0, left_margin = 0, right_margin = 0, upper_margin = 0, 
> > lower_margin = 0, hsync_len = 0,
> >    vsync_len = 0, sync = 0, vmode = 0, reserved = {0, 0, 0, 0, 0, 0}}
> > 
> > (gdb) p *req
> > $2 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
> > xoffset = 0, yoffset = 0,
> >    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
> > msb_right = 0}, green = {offset = 0,
> >      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
> > msb_right = 0}, transp = {offset = 0,
> >      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
> > width = 0, accel_flags = 0,
> >    pixclock = 22271, left_margin = 56, right_margin = 8, upper_margin = 
> > 41, lower_margin = 0,
> >    hsync_len = 176, vsync_len = 8, sync = 3, vmode = 1, reserved = {0, 
> > 0, 0, 0, 0, 0}}
> > 
> > (gdb) bt
> > #0  fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8) at 
> > ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
> > #1  0x40bcfb64 in fbdevHWSetMode (pScrn=0x2142a0, mode=<value optimized 
> > out>, check=1)
> >      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:528
> > #2  0x40bd07e8 in fbdevHWSetVideoModes (pScrn=0x2142a0) at 
> > ../../../../hw/xfree86/fbdevhw/fbdevhw.c:568
> > #3  0x40cf5bec in ?? () from /usr/lib/xorg/modules/drivers//fbdev_drv.so
> > #4  0x00074e88 in InitOutput ()
> > #5  0x00039d04 in main ()
> > 
> > As you can see, the main video parameters are OK, while the 
> > monitor/modeline values (pixclock, left_margin, right_margin, 
> > upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
> > were changed to zero.

It would appear that none of these values are relevant to the stifb.
The stifb.c code uses kzalloc to allocate the struct stifb_info, so
I think the above values should be zero.  Some code is clearly computing
values for pixclock, etc.  I don't see that this code is in the kernel.
It may be X that's making up these values.

I see in the log:

(II) FBDEV(0): hardware: stifb (video memory: 2048kB)
(II) FBDEV(0): checking modes against framebuffer device...
(II) FBDEV(0):  mode "1280x1024" test failed
(II) FBDEV(0): checking modes against monitor...
(--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280)
(**) FBDEV(0):  Built-in mode "current": 28000.0 MHz, 21875.0 kHz, 21362.3 Hz
(II) FBDEV(0): Modeline "current"x0.0  28000.00  1280 1280 1280 1280  1024 1024 
1024 1024 -hsync -vsync -csync (21875.0 kHz)
(==) FBDEV(0): DPI set to (96, 96)

Could X be requesting a mode with invalid mode parameters?

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

Re: X won't start with VisEG and 2.6.22.19

[Helge Deller]

John David Anglin wrote:
>>> Tracing with gdb gives the following:
>>>
>>> Breakpoint 1, fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8)
>>>      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
>>> 256     }
>>> (gdb) p *set
>>> $1 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
>>> xoffset = 0, yoffset = 0,
>>>    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
>>> msb_right = 0}, green = {offset = 0,
>>>      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
>>> msb_right = 0}, transp = {offset = 0,
>>>      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
>>> width = 0, accel_flags = 0,
>>>    pixclock = 0, left_margin = 0, right_margin = 0, upper_margin = 0, 
>>> lower_margin = 0, hsync_len = 0,
>>>    vsync_len = 0, sync = 0, vmode = 0, reserved = {0, 0, 0, 0, 0, 0}}
>>>
>>> (gdb) p *req
>>> $2 = {xres = 1024, yres = 768, xres_virtual = 1024, yres_virtual = 768, 
>>> xoffset = 0, yoffset = 0,
>>>    bits_per_pixel = 8, grayscale = 0, red = {offset = 0, length = 8, 
>>> msb_right = 0}, green = {offset = 0,
>>>      length = 8, msb_right = 0}, blue = {offset = 0, length = 8, 
>>> msb_right = 0}, transp = {offset = 0,
>>>      length = 0, msb_right = 0}, nonstd = 0, activate = 0, height = 0, 
>>> width = 0, accel_flags = 0,
>>>    pixclock = 22271, left_margin = 56, right_margin = 8, upper_margin = 
>>> 41, lower_margin = 0,
>>>    hsync_len = 176, vsync_len = 8, sync = 3, vmode = 1, reserved = {0, 
>>> 0, 0, 0, 0, 0}}
>>>
>>> (gdb) bt
>>> #0  fbdev_modes_equal (set=0xfb5ed568, req=0xfb5ed4c8) at 
>>> ../../../../hw/xfree86/fbdevhw/fbdevhw.c:256
>>> #1  0x40bcfb64 in fbdevHWSetMode (pScrn=0x2142a0, mode=<value optimized 
>>> out>, check=1)
>>>      at ../../../../hw/xfree86/fbdevhw/fbdevhw.c:528
>>> #2  0x40bd07e8 in fbdevHWSetVideoModes (pScrn=0x2142a0) at 
>>> ../../../../hw/xfree86/fbdevhw/fbdevhw.c:568
>>> #3  0x40cf5bec in ?? () from /usr/lib/xorg/modules/drivers//fbdev_drv.so
>>> #4  0x00074e88 in InitOutput ()
>>> #5  0x00039d04 in main ()
>>>
>>> As you can see, the main video parameters are OK, while the 
>>> monitor/modeline values (pixclock, left_margin, right_margin, 
>>> upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
>>> were changed to zero.
> 
> It would appear that none of these values are relevant to the stifb.
> The stifb.c code uses kzalloc to allocate the struct stifb_info, so
> I think the above values should be zero.  Some code is clearly computing
> values for pixclock, etc.  I don't see that this code is in the kernel.
> It may be X that's making up these values.
> 
> I see in the log:
> 
> (II) FBDEV(0): hardware: stifb (video memory: 2048kB)
> (II) FBDEV(0): checking modes against framebuffer device...
> (II) FBDEV(0):  mode "1280x1024" test failed
> (II) FBDEV(0): checking modes against monitor...
> (--) FBDEV(0): Virtual size is 1280x1024 (pitch 1280)
> (**) FBDEV(0):  Built-in mode "current": 28000.0 MHz, 21875.0 kHz, 21362.3 Hz
> (II) FBDEV(0): Modeline "current"x0.0  28000.00  1280 1280 1280 1280  1024 1024 
> 1024 1024 -hsync -vsync -csync (21875.0 kHz)
> (==) FBDEV(0): DPI set to (96, 96)
> 
> Could X be requesting a mode with invalid mode parameters?

In general X behaves correctly if you have a fb device, which is able to 
set sync timings.
But stifb and a few other fb drivers are not able to set sync timings, 
and for those X behaves IMHO wrong. For those X should assume that the 
timings set by the driver are correct as long as the resolution and bit 
depth are correct.

This is what happens:
1. In xorg.conf you configured a pixel resolution and bpp (e.g. 
1280x1024-16)
2. In xorg.conf you might have configured a monitor (with or without 
some timing/sync informations)
3. X reads those config parameters and try to set them through kernel calls.
4. Kernel returns that it now has set up the mode (1280x1024-16) and has 
set up the timings. Since stifb does not support timing modes, it 
returns zeros in those values (IMHO thats correct behavior if you look 
at the comments in skeletonfb.c)
5. X verifies the returned values and aborts since the timing values are 
different to what it fed to the kernel, although the resolution 
(1280x1024-16) is correctly set and returned like that.

I think X is right in noticing that the timing/sync values are not what 
it expected. Nevertheless, I would prefer that it would just warn (in 
the fbdev drivers only!) that the timings are incorrect instead of 
aborting completely. X is right to abort, if the pixel resolution and 
bpp can not be set.
So, X's tests should be like that:
a) resolution and bpp different -> abort
b) resolution and bpp correct, but sync timings/monitor timings 
different -> warn but continue

Right now X's tests are:
resolution, bpp or sync/monitor timings different -> abort.

Of course it's easily possible to change stifb in that it just takes any 
timing values, but that is not how it is documented in skeletonfb.

Helge

Re: X won't start with VisEG and 2.6.22.19

[John David Anglin]

> >>> As you can see, the main video parameters are OK, while the 
> >>> monitor/modeline values (pixclock, left_margin, right_margin, 
> >>> upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
> >>> were changed to zero.

The skeletonfb.c code makes it very clear that the only place where
a mode can be changed is in xxxfb_check_var:

*      Exception to the above rule:  Some drivers have a fixed mode, ie,
*      the hardware is already set at boot up, and cannot be changed.  In
*      this case, it is more acceptable that this function just return
*      a copy of the currently working var (info->var). Better is to not
*      implement this function, as the upper layer will do the copying
*      of the current var for you.
*
*      Note:  This is the only function where the contents of var can be
*      freely adjusted after the driver has been registered. If you find
*      that you have code outside of this function that alters the content
*      of var, then you are doing something wrong.  Note also that the
*      contents of info->var must be left untouched at all times after
*      driver registration.

As xxxfb_check_var is not implemented in stifb.c, it must be the upper
level that is changing the parameters.  Possibly, something to try is
the following:

 *      However, even if your hardware does not support mode changing,
 *      a set_par might be needed to at least initialize the hardware to
 *      a known working state, especially if it came back from another
 *      process that also modifies the same hardware, such as X.
 *
 *      If this is the case, a combination such as the following should work:
 *
 *      static int xxxfb_check_var(struct fb_var_screeninfo *var,
 *                                struct fb_info *info)
 *      {
 *              *var = info->var;
 *              return 0;
 *      }
 *
 *      static int xxxfb_set_par(struct fb_info *info)
 *      {
 *              init your hardware here
 *      }

> But stifb and a few other fb drivers are not able to set sync timings, 
> and for those X behaves IMHO wrong. For those X should assume that the 
> timings set by the driver are correct as long as the resolution and bit 
> depth are correct.
> 
> This is what happens:
> 1. In xorg.conf you configured a pixel resolution and bpp (e.g. 
> 1280x1024-16)
> 2. In xorg.conf you might have configured a monitor (with or without 
> some timing/sync informations)
> 3. X reads those config parameters and try to set them through kernel calls.
> 4. Kernel returns that it now has set up the mode (1280x1024-16) and has 
> set up the timings. Since stifb does not support timing modes, it 
> returns zeros in those values (IMHO thats correct behavior if you look 
> at the comments in skeletonfb.c)
> 5. X verifies the returned values and aborts since the timing values are 
> different to what it fed to the kernel, although the resolution 
> (1280x1024-16) is correctly set and returned like that.
> 
> I think X is right in noticing that the timing/sync values are not what 
> it expected. Nevertheless, I would prefer that it would just warn (in 
> the fbdev drivers only!) that the timings are incorrect instead of 
> aborting completely. X is right to abort, if the pixel resolution and 
> bpp can not be set.
> So, X's tests should be like that:
> a) resolution and bpp different -> abort
> b) resolution and bpp correct, but sync timings/monitor timings 
> different -> warn but continue
> 
> Right now X's tests are:
> resolution, bpp or sync/monitor timings different -> abort.
> 
> Of course it's easily possible to change stifb in that it just takes any 
> timing values, but that is not how it is documented in skeletonfb.

My sense in looking at the PR is that the freedesktop people won't
accept this approach.

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

Re: X won't start with VisEG and 2.6.22.19

[Helge Deller]

John David Anglin wrote:
>>>>> As you can see, the main video parameters are OK, while the 
>>>>> monitor/modeline values (pixclock, left_margin, right_margin, 
>>>>> upper_margin, lower_margin, hsync_len, vsync_len, sync and vmode)
>>>>> were changed to zero.
> 
> The skeletonfb.c code makes it very clear that the only place where
> a mode can be changed is in xxxfb_check_var:
> 
> *      Exception to the above rule:  Some drivers have a fixed mode, ie,
> *      the hardware is already set at boot up, and cannot be changed.  In
> *      this case, it is more acceptable that this function just return
> *      a copy of the currently working var (info->var). Better is to not
> *      implement this function, as the upper layer will do the copying
> *      of the current var for you.
> *
> *      Note:  This is the only function where the contents of var can be
> *      freely adjusted after the driver has been registered. If you find
> *      that you have code outside of this function that alters the content
> *      of var, then you are doing something wrong.  Note also that the
> *      contents of info->var must be left untouched at all times after
> *      driver registration.
> 
> As xxxfb_check_var is not implemented in stifb.c, it must be the upper
> level that is changing the parameters.  Possibly, something to try is
> the following:
> 
>  *      However, even if your hardware does not support mode changing,
>  *      a set_par might be needed to at least initialize the hardware to
>  *      a known working state, especially if it came back from another
>  *      process that also modifies the same hardware, such as X.
>  *
>  *      If this is the case, a combination such as the following should work:
>  *
>  *      static int xxxfb_check_var(struct fb_var_screeninfo *var,
>  *                                struct fb_info *info)
>  *      {
>  *              *var = info->var;
>  *              return 0;
>  *      }
>  *
>  *      static int xxxfb_set_par(struct fb_info *info)
>  *      {
>  *              init your hardware here
>  *      }


Yes, exactly that would be the patch to make it work.


>> But stifb and a few other fb drivers are not able to set sync timings, 
>> and for those X behaves IMHO wrong. For those X should assume that the 
>> timings set by the driver are correct as long as the resolution and bit 
>> depth are correct.
>>
>> This is what happens:
>> 1. In xorg.conf you configured a pixel resolution and bpp (e.g. 
>> 1280x1024-16)
>> 2. In xorg.conf you might have configured a monitor (with or without 
>> some timing/sync informations)
>> 3. X reads those config parameters and try to set them through kernel calls.
>> 4. Kernel returns that it now has set up the mode (1280x1024-16) and has 
>> set up the timings. Since stifb does not support timing modes, it 
>> returns zeros in those values (IMHO thats correct behavior if you look 
>> at the comments in skeletonfb.c)
>> 5. X verifies the returned values and aborts since the timing values are 
>> different to what it fed to the kernel, although the resolution 
>> (1280x1024-16) is correctly set and returned like that.
>>
>> I think X is right in noticing that the timing/sync values are not what 
>> it expected. Nevertheless, I would prefer that it would just warn (in 
>> the fbdev drivers only!) that the timings are incorrect instead of 
>> aborting completely. X is right to abort, if the pixel resolution and 
>> bpp can not be set.
>> So, X's tests should be like that:
>> a) resolution and bpp different -> abort
>> b) resolution and bpp correct, but sync timings/monitor timings 
>> different -> warn but continue
>>
>> Right now X's tests are:
>> resolution, bpp or sync/monitor timings different -> abort.
>>
>> Of course it's easily possible to change stifb in that it just takes any 
>> timing values, but that is not how it is documented in skeletonfb.
> 
> My sense in looking at the PR is that the freedesktop people won't
> accept this approach.

Sadly I have the same feeling.
But just scan yourself through the kernel fb drivers and look how many 
drivers haven't implemented this workaround with check_var and set_par.
All those fb drivers are probably broken due to this X behavior.

Helge

Re: Kernel Panic during init with 2.6.29-gb609308 (fresh clone of git

[John David Anglin]

> You might try building with the 4.1 branch.  I have had more luck
> with it.

I tried building 2.6.22.19 with debian 4.3.  Boot fails here:

md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Freeing unused kernel memory: <0>------------[ cut here ]------------
Badness at 000000004011e44c [verbose debug info unavailable]
Backtrace:
Backtrace:
 [<00000000401128c0>] dump_stack+0x18/0x28

Have to hit 'RS' twice.  The first time there is a hpmc in the memory test:

#  Location|Alert| Encoded Field    |  Data Field    |   Keyword / Timestamp
-------------------------------------------------------------------------------
52951  SFW  0   0  0x030010D500E00000 0000000000000000 CPU_STOP
52950  SFW  0   2  0x438010EF00E01B50 00000000FFFFFFFF MEM_UNEXPECTED_HPMC
                                                      03 May 2009 00:35:26
52949  SFW  0   0  0x160000C400E00000 0000000280000000 MEM_INIT
52948  SFW  0   0  0x370000FB00E00000 000000F000004002 MEM_WARN_INIT_ONLY

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

Re: Reproducible random python crash.

[John David Anglin]

> I booted 2.6.30.5 from gsyprf11 because I had one random segv and
> one command hang while running the GCC testsuite.  I suspect that some
> hangs are due to dropped signals.  I'm tempted to try the sequence
> with 2.6.22.19.

SMP 2.6.22.19 also fails with random segvs and hangs.

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

futex wait failure

[John David Anglin]

I recently update gsyprf11 to the latest debian testing.  I also
tried 2.6.32.2, first SMP, then UP because of /bin/sh segmentation
faults.

I think the /bin/sh segmentation faults are the vfork issue, but
the vfork testcases run successfully on the above.

My first attempt at running the GCC testsuite hung:

dave@gsyprf11:~/gcc-4.5/objdir$ ps -ef|grep dave|grep 18073
dave     18073 18064  2 Dec21 ?        00:11:07 expect -- /usr/share/dejagnu/runtest.exp --tool gfortran
dave     18091 18073  0 02:09 ?        00:00:00 [gfortran] <defunct>

dave@gsyprf11:~/gcc-4.5/objdir$ strace -p 18073
Process 18073 attached - interrupt to quit
futex(0x1c538, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
Process 18073 detached
dave@gsyprf11:~/gcc-4.5/objdir$ strace -p 18091
attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted

This is the backtrace for expect:

0x4039934c in __lll_lock_wait () from /lib/libpthread.so.0
(gdb) bt
#0  0x4039934c in __lll_lock_wait () from /lib/libpthread.so.0
#1  0x4038f9c4 in pthread_mutex_lock () from /lib/libpthread.so.0
#2  0x40b73008 in pthread_mutex_lock () from /lib/libc.so.6
#3  0x4085eeb8 in Tcl_WaitForEvent () from /usr/lib/libtcl8.5.so.0
#4  0x4081ccdc in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
#5  0x4003d9c4 in exp_get_next_event () from /usr/lib/libexpect.so.5.44.1.14
#6  0x4001c6bc in expRead () from /usr/lib/libexpect.so.5.44.1.14
#7  0x4001eea0 in Exp_ExpectObjCmd () from /usr/lib/libexpect.so.5.44.1.14
...

This is just a guess but I would guess that the gfortran task either
didn't update the futex address, or is blocked from doing so.

libc6 is 2.10.2-2.

This is probably related to the long standing problem with expect
and tcl8.4 and later.  expect-tcl8.3 works better.

Any thoughts?

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

Re: futex wait failure

[Carlos O'Donell]

On Tue, Dec 22, 2009 at 10:03 AM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> I recently update gsyprf11 to the latest debian testing. =A0I also
> tried 2.6.32.2, first SMP, then UP because of /bin/sh segmentation
> faults.
>
> I think the /bin/sh segmentation faults are the vfork issue, but
> the vfork testcases run successfully on the above.

That's a shame, the testcase was pretty straight forward. I will try
to update the test case when I have my new kernel running.

> My first attempt at running the GCC testsuite hung:
> dave@gsyprf11:~/gcc-4.5/objdir$ strace -p 18073
> Process 18073 attached - interrupt to quit
> futex(0x1c538, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
> Process 18073 detached
> dave@gsyprf11:~/gcc-4.5/objdir$ strace -p 18091
> attach: ptrace(PTRACE_ATTACH, ...): Operation not permitted
>
> This is the backtrace for expect:
>
> 0x4039934c in __lll_lock_wait () from /lib/libpthread.so.0
> (gdb) bt
> #0 =A00x4039934c in __lll_lock_wait () from /lib/libpthread.so.0
> #1 =A00x4038f9c4 in pthread_mutex_lock () from /lib/libpthread.so.0
> #2 =A00x40b73008 in pthread_mutex_lock () from /lib/libc.so.6
> #3 =A00x4085eeb8 in Tcl_WaitForEvent () from /usr/lib/libtcl8.5.so.0
> #4 =A00x4081ccdc in Tcl_DoOneEvent () from /usr/lib/libtcl8.5.so.0
> #5 =A00x4003d9c4 in exp_get_next_event () from /usr/lib/libexpect.so.=
5.44.1.14
> #6 =A00x4001c6bc in expRead () from /usr/lib/libexpect.so.5.44.1.14
> #7 =A00x4001eea0 in Exp_ExpectObjCmd () from /usr/lib/libexpect.so.5.=
44.1.14
> ...
>
> This is just a guess but I would guess that the gfortran task either
> didn't update the futex address, or is blocked from doing so.
>
> libc6 is 2.10.2-2.
>
> This is probably related to the long standing problem with expect
> and tcl8.4 and later. =A0expect-tcl8.3 works better.
>
> Any thoughts?

You should be looking for the thread (not process) that is supposed to
wake this thread up. It's a private futex, meaning it isn't going to
be shared with any other process. If it is shared, and the wakeup (or
pthread_mutex_unlock) is issued from another thread in another process
then it won't be seen by the thread in this process.

We might have an hppa specific glibc bug related to the futex private f=
lag.

The hppa lowlevellock.h is a copy of the generic version. Perhaps I
need to update our copy to get recent bug fixes from other targets.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Carlos O'Donell]

On Tue, Dec 22, 2009 at 11:48 AM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> Debian gdb 7.0 provides slightly different backtraces:
>
> (gdb) bt
> #0 =A00x4039934c in __lll_lock_wait (futex=3D0x1c538,
> =A0 =A0private=3D<value optimized out>)
> ...
>
> and
>
> (gdb) bt
> #0 =A00x4038f92c in __lll_mutex_lock (mutex=3D0x1c538)

Any idea why both threads would try to lock the same mutex? This is
never going to work?

I think we need to step back from the edge and ask ourselves what
Tcl_WaitForEvent() is trying to do with the locks.

Do you know?

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

> I think we need to step back from the edge and ask ourselves what
> Tcl_WaitForEvent() is trying to do with the locks.
> 
> Do you know?

In unix/tclUnixNotify.c:

#ifdef TCL_THREADS
    /*
     * Place this thread on the list of interested threads, signal the
     * notifier thread, and wait for a response or a timeout.
     */

    Tcl_MutexLock(&notifierMutex);
    ...
#endif

    ...

#ifdef TCL_THREADS
    Tcl_MutexUnlock(&notifierMutex);
#endif /* TCL_THREADS */
    return 0;
}

There may be a timed wait while holding the lock.  Something is broken
in the tcl/expect handling of timed waits as there were a couple of
compile timeouts for compilations that shouldn't have timed out.

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

Re: futex wait failure

[Carlos O'Donell]

On Tue, Dec 22, 2009 at 4:29 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> It would seem to me we have deadlock. =A0Two threads trying to lock
> the same mutex. =A0One should win... =A0It may be the mutex was left
> locked by some other thread.

Yes, it was left locked by thread #2, which then tried to acquire it
again. See below.

> This is the mutex:
>
> (gdb) p *mutex
> $1 =3D {__data =3D {__lock =3D 2, __count =3D 0, __owner =3D 18093, _=
_kind =3D 0,
> =A0 =A0__compat_padding =3D {0, 0, 0, 0}, __nusers =3D 1, {__spins =3D=
 0, __list =3D {
> =A0 =A0__next =3D 0x0}}, __reserved1 =3D 0, __reserved2 =3D 0},
> =A0 =A0__size =3D "\000\000\000\002\000\000\000\000\000\000F\255", '\=
000' <repeats 23 times>, "\001", '\000' <repeats 11 times>, __align =3D=
 2}

The __nusers field indicates that one user, namely __owner tid 18093
has already taken the lock.

The mutex owner is thread #2 in your example (tid shown in your backtra=
ce).

Thread #2 is also trying to lock the mutex again and is deadlocked.

The mutex is the default __kind of PTHREAD_MUTEX_TIMED_NP, but that
doesn't mean it's timed, only that it supports a timed lock, if you
call it using pthread_mutex_lock it will lock just like any other
mutex.

The lock value is 2, which indicates a private lock. Your backtrace
indicates you have called __lll_lock_wait_private, which is correct
for this case.

Under what conditions would thread #2 have a chance to try take it's
own lock again?

> It's hard to see what's happening because I don't seem to be able to
> single step the threads.

Yeah, there are some gdb/ptrace issues I need to sort out for the
newly minted nptl support.

>>
>> I think we need to step back from the edge and ask ourselves what
>> Tcl_WaitForEvent() is trying to do with the locks.
>>
>> Do you know?
>
> No. =A0Note thread 2 called pthread_mutex_lock from a different locat=
ion.

We need to determine under what conditions thread #2 would be able to
take the lock again and deadlock.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Carlos O'Donell]

On Tue, Dec 22, 2009 at 5:05 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> I think we need to step back from the edge and ask ourselves what
>> Tcl_WaitForEvent() is trying to do with the locks.
>>
>> Do you know?
>
> In unix/tclUnixNotify.c:
>
> #ifdef TCL_THREADS
> =A0 =A0/*
> =A0 =A0 * Place this thread on the list of interested threads, signal=
 the
> =A0 =A0 * notifier thread, and wait for a response or a timeout.
> =A0 =A0 */

There will never be a timeout if you call pthread_mutex_lock as the
underlying operation. So this comment is a bit odd?

> =A0 =A0Tcl_MutexLock(&notifierMutex);
> =A0 =A0...
> #endif
>
> =A0 =A0...
>
> #ifdef TCL_THREADS
> =A0 =A0Tcl_MutexUnlock(&notifierMutex);
> #endif /* TCL_THREADS */
> =A0 =A0return 0;
> }
>
> There may be a timed wait while holding the lock. =A0Something is bro=
ken
> in the tcl/expect handling of timed waits as there were a couple of
> compile timeouts for compilations that shouldn't have timed out.

There is no timed wait possible, you have called pthread_mutex_lock,
instead of pthread_mutex_timedlock.

What are Tcl's expectations here? It looks like we are stuck in
libtcl.so for both threads, which are trying to access this event
queue.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

On Wed, 23 Dec 2009, Carlos O'Donell wrote:

> On Tue, Dec 22, 2009 at 5:05 PM, John David Anglin
> <dave@hiauly1.hia.nrc.ca> wrote:
> >> I think we need to step back from the edge and ask ourselves what
> >> Tcl_WaitForEvent() is trying to do with the locks.
> >>
> >> Do you know?
> >
> > In unix/tclUnixNotify.c:
> >
> > #ifdef TCL_THREADS
> > =A0 =A0/*
> > =A0 =A0 * Place this thread on the list of interested threads, sign=
al the
> > =A0 =A0 * notifier thread, and wait for a response or a timeout.
> > =A0 =A0 */
>=20
> There will never be a timeout if you call pthread_mutex_lock as the
> underlying operation. So this comment is a bit odd?

The wait is done by Tcl_ConditionWait.  It uses  pthread_cond_wait
if timePtr is NULL, otherwise it uses
pthread_cond_timedwait(pcondPtr, pmutexPtr, &ptime).  Do these work
holding a lock?  Any chance that these try to take a lock?

It sems like bad coding to do a wait holding a lock.  In any case,
I don't think this is the problem.

As you noted, the lock is held by the other thread.  The return pc is
beyond Tcl_WaitForEvent.  The only users of the notifierMutex mutex
are in tclUnixNotfy.c.  The only interesting thing done holding the
notifierMutex mutex in code after Tcl_WaitForEvent is to call
Tcl_ConditionNotify.  It calls pthread_cond_broadcast if the condition
pointer isn't NULL.

Could this deadlock?  It's hard to see how it could since the mutex
doesn't seem to be involved.

Dave
--=20
J. David Anglin                                  dave.anglin@nrc-cnrc.g=
c.ca
National Research Council of Canada              (613) 990-0752 (FAX: 9=
52-6602)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

On Wed, 23 Dec 2009, John David Anglin wrote:

> As you noted, the lock is held by the other thread.  The return pc is
> beyond Tcl_WaitForEvent.  The only users of the notifierMutex mutex
> are in tclUnixNotfy.c.  The only interesting thing done holding the
> notifierMutex mutex in code after Tcl_WaitForEvent is to call
> Tcl_ConditionNotify.  It calls pthread_cond_broadcast if the condition
> pointer isn't NULL.
> 
> Could this deadlock?  It's hard to see how it could since the mutex
> doesn't seem to be involved.

Actually, I see that the mutex and futex are part of the pthread_cond_t
type, so pthread_cond_broadcast could deadlock if not implemented properly.

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

Re: futex wait failure

[Carlos O'Donell]

On Wed, Dec 23, 2009 at 11:15 AM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> There will never be a timeout if you call pthread_mutex_lock as the
>> underlying operation. So this comment is a bit odd?
>
> The wait is done by Tcl_ConditionWait. =A0It uses =A0pthread_cond_wai=
t
> if timePtr is NULL, otherwise it uses
> pthread_cond_timedwait(pcondPtr, pmutexPtr, &ptime). =A0Do these work
> holding a lock? =A0Any chance that these try to take a lock?

When you call pthread_cond_timedwait you must be holding pmutexPtr.

The call to pthread_cond_timedwait atomically release mutex and cause
the calling thread to sleep on the condition variable cond; atomically
here means "atomically with respect to access by another thread to
the mutex and then the condition variable". Once awoken by a broadcast,
it retakes the mutex pmutexPtr.

The glibc implementation with futexes reads pretty much exactly like
the description here:
http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_ti=
medwait.html

> It sems like bad coding to do a wait holding a lock. =A0In any case,
> I don't think this is the problem.

You shouldn't be holding a lock while waiting. The call to
pthread_cond_timedwait
should have released the mutex before sleeping.

> As you noted, the lock is held by the other thread. =A0The return pc =
is
> beyond Tcl_WaitForEvent. =A0The only users of the notifierMutex mutex
> are in tclUnixNotfy.c. =A0The only interesting thing done holding the
> notifierMutex mutex in code after Tcl_WaitForEvent is to call
> Tcl_ConditionNotify. =A0It calls pthread_cond_broadcast if the condit=
ion
> pointer isn't NULL.
> Could this deadlock? =A0It's hard to see how it could since the mutex
> doesn't seem to be involved.

It shouldn't deadlock.

Is this a UP kernel?

Perhaps what I'm not clear about here, is which mutex is the one that
we are stuck on?

Are we stuck on the mutex we want to pass to pthread_cond_timedwait?

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

On Wed, 23 Dec 2009, John David Anglin wrote:

> On Wed, 23 Dec 2009, John David Anglin wrote:
> 
> > As you noted, the lock is held by the other thread.  The return pc is
> > beyond Tcl_WaitForEvent.  The only users of the notifierMutex mutex
> > are in tclUnixNotfy.c.  The only interesting thing done holding the
> > notifierMutex mutex in code after Tcl_WaitForEvent is to call
> > Tcl_ConditionNotify.  It calls pthread_cond_broadcast if the condition
> > pointer isn't NULL.
> > 
> > Could this deadlock?  It's hard to see how it could since the mutex
> > doesn't seem to be involved.
> 
> Actually, I see that the mutex and futex are part of the pthread_cond_t
> type, so pthread_cond_broadcast could deadlock if not implemented properly.

The deadlock occurs at the third call to Tcl_MutexLock in NotifierThreadProc
(tclUnixNotfy.c:997).  This is in a while(1) loop, so I have to think
the previous call to Tcl_MutexUnlock failed, possibly because of a call
to Tcl_ConditionNotify.

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

Re: futex wait failure

[Carlos O'Donell]

On Wed, Dec 23, 2009 at 3:39 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> The deadlock occurs at the third call to Tcl_MutexLock in NotifierThr=
eadProc
> (tclUnixNotfy.c:997). =A0This is in a while(1) loop, so I have to thi=
nk
> the previous call to Tcl_MutexUnlock failed, possibly because of a ca=
ll
> to Tcl_ConditionNotify.

You might get a better idea if you run this under strace and look at
the futex syscalls being made. You won't see the locks since the fast
path is through the light-weight-syscall compare-and-swap, but you
will see the unlocks, and you can count them.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Carlos O'Donell]

On Wed, Dec 23, 2009 at 3:45 PM, Carlos O'Donell
<carlos@systemhalted.org> wrote:
> On Wed, Dec 23, 2009 at 3:39 PM, John David Anglin
> <dave@hiauly1.hia.nrc.ca> wrote:
>> The deadlock occurs at the third call to Tcl_MutexLock in NotifierTh=
readProc
>> (tclUnixNotfy.c:997). =A0This is in a while(1) loop, so I have to th=
ink
>> the previous call to Tcl_MutexUnlock failed, possibly because of a c=
all
>> to Tcl_ConditionNotify.
>
> You might get a better idea if you run this under strace and look at
> the futex syscalls being made. You won't see the locks since the fast
> path is through the light-weight-syscall compare-and-swap, but you
> will see the unlocks, and you can count them.

Sorry, let me be clearer here. The *first* lock is through the fast
path of the lws CAS operation. All subsequent locks take the form of a
futex wait. All subsequent unlocks are a futex wake.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

On Wed, 23 Dec 2009, Carlos O'Donell wrote:

> On Wed, Dec 23, 2009 at 11:15 AM, John David Anglin
> <dave@hiauly1.hia.nrc.ca> wrote:
> >> There will never be a timeout if you call pthread_mutex_lock as th=
e
> >> underlying operation. So this comment is a bit odd?
> >
> > The wait is done by Tcl_ConditionWait. =A0It uses =A0pthread_cond_w=
ait
> > if timePtr is NULL, otherwise it uses
> > pthread_cond_timedwait(pcondPtr, pmutexPtr, &ptime). =A0Do these wo=
rk
> > holding a lock? =A0Any chance that these try to take a lock?
>=20
> When you call pthread_cond_timedwait you must be holding pmutexPtr.
>=20
> The call to pthread_cond_timedwait atomically release mutex and cause
> the calling thread to sleep on the condition variable cond; atomicall=
y
> here means "atomically with respect to access by another thread to
> the mutex and then the condition variable". Once awoken by a broadcas=
t,
> it retakes the mutex pmutexPtr.
>=20
> The glibc implementation with futexes reads pretty much exactly like
> the description here:
> http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_=
timedwait.html
>=20
> > It sems like bad coding to do a wait holding a lock. =A0In any case=
,
> > I don't think this is the problem.
>=20
> You shouldn't be holding a lock while waiting. The call to
> pthread_cond_timedwait
> should have released the mutex before sleeping.

No, the manpage for pthread_cond_wait and pthread_cond_timedwait
indicates that these calls atomically unlock the mutex, so the implemen=
tation
appears correct.  Before returning to the calling thread, they relock
the mutex.  So, the mutex shouldn't be held while the thread is
sleeping.

>=20
> > As you noted, the lock is held by the other thread. =A0The return p=
c is
> > beyond Tcl_WaitForEvent. =A0The only users of the notifierMutex mut=
ex
> > are in tclUnixNotfy.c. =A0The only interesting thing done holding t=
he
> > notifierMutex mutex in code after Tcl_WaitForEvent is to call
> > Tcl_ConditionNotify. =A0It calls pthread_cond_broadcast if the cond=
ition
> > pointer isn't NULL.
> > Could this deadlock? =A0It's hard to see how it could since the mut=
ex
> > doesn't seem to be involved.
>=20
> It shouldn't deadlock.
>=20
> Is this a UP kernel?

Yes.  This has now happened twice in one testsuite run.

> Perhaps what I'm not clear about here, is which mutex is the one that
> we are stuck on?

notifierMutex.  It controls all activities in tclUnixNotfy.c.

> Are we stuck on the mutex we want to pass to pthread_cond_timedwait?

Yes.

Dave
--=20
J. David Anglin                                  dave.anglin@nrc-cnrc.g=
c.ca
National Research Council of Canada              (613) 990-0752 (FAX: 9=
52-6602)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

On Wed, 23 Dec 2009, Carlos O'Donell wrote:

> On Wed, Dec 23, 2009 at 3:39 PM, John David Anglin
> <dave@hiauly1.hia.nrc.ca> wrote:
> > The deadlock occurs at the third call to Tcl_MutexLock in NotifierT=
hreadProc
> > (tclUnixNotfy.c:997). =A0This is in a while(1) loop, so I have to t=
hink
> > the previous call to Tcl_MutexUnlock failed, possibly because of a =
call
> > to Tcl_ConditionNotify.
>=20
> You might get a better idea if you run this under strace and look at
> the futex syscalls being made. You won't see the locks since the fast
> path is through the light-weight-syscall compare-and-swap, but you
> will see the unlocks, and you can count them.

I would guess that the notifierMutex is locked/unlocked millions of
time in a typical GCC testsuite run.  So, the problem won't be easy
to duplicate manually.

Dave
--=20
J. David Anglin                                  dave.anglin@nrc-cnrc.g=
c.ca
National Research Council of Canada              (613) 990-0752 (FAX: 9=
52-6602)
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Carlos O'Donell]

On Wed, Dec 23, 2009 at 4:08 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> You might get a better idea if you run this under strace and look at
>> the futex syscalls being made. You won't see the locks since the fas=
t
>> path is through the light-weight-syscall compare-and-swap, but you
>> will see the unlocks, and you can count them.
>
> I would guess that the notifierMutex is locked/unlocked millions of
> time in a typical GCC testsuite run. =A0So, the problem won't be easy
> to duplicate manually.

You would be surprised how easy it is to duplicate some of these
problems. We need to write a small skeleton application that does
something similar to the notification done by tcl and uses
pthread_cond_timedwait. Setup main to run forever signaling the child
which does something and then goes back to waiting. Eventually this
should lock up like it does in tcl.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

> I have noticed that the notifierMutex mutex is initialized to all
> zeros (i.e., it's declared static).  Is this ok with our nptl implementation?

Forget this, it's done in Tcl_MutexLock.

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

Re: futex wait failure

[Carlos O'Donell]

On Wed, Dec 23, 2009 at 5:18 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> I have noticed that the notifierMutex mutex is initialized to all
>> zeros (i.e., it's declared static). =A0Is this ok with our nptl impl=
ementation?
>
> Forget this, it's done in Tcl_MutexLock.

In NPTL the hppa locks are all zero. We no longer use
load-and-clear-word for anything in userspace.

Even the dynamic initialization will zero the lock.

We are just like every other architecture... with the exception that
we currently have more bugs :-)

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 857 bytes --]

On Wed, 23 Dec 2009, Carlos O'Donell wrote:

> We are just like every other architecture... with the exception that
> we currently have more bugs :-)

I have been looking at the lws implementation.  I've attached a patch
with a couple of tweaks:

1) I changed the unconditional branch at the entry point to a gate.
Didn't think it was a good idea to execute code at user priveledge.
This seems to have improved things (got through a complete testsuite
run on gsyprf11 without a deadlock).  However, I hit a slightly
different lockup on c3750.

2) Change return space register to sr7.  sr3 is not set correctly
if the entry number is invalid.

Have nasty suspicion that sr3 is getting hit...

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

[-- Attachment #2: syscall.S.d.1 --]
[-- Type: text/plain, Size: 1206 bytes --]

--- a/arch/parisc/kernel/syscall.S
+++ b/arch/parisc/kernel/syscall.S
@@ -47,18 +47,17 @@ ENTRY(linux_gateway_page)
 	KILL_INSN
 	.endr
 
-	/* ADDRESS 0xb0 to 0xb4, lws uses 1 insns for entry */
+	/* ADDRESS 0xb0 to 0xb8, lws uses two insns for entry */
 	/* Light-weight-syscall entry must always be located at 0xb0 */
 	/* WARNING: Keep this number updated with table size changes */
 #define __NR_lws_entries (2)
 
 lws_entry:
-	/* Unconditional branch to lws_start, located on the 
-	   same gateway page */
-	b,n	lws_start
+	gate	lws_start, %r0		/* increase privilege */
+	depi	3, 31, 2, %r31		/* Ensure we return into user mode. */
 
-	/* Fill from 0xb4 to 0xe0 */
-	.rept 11
+	/* Fill from 0xb8 to 0xe0 */
+	.rept 10
 	KILL_INSN
 	.endr
 
@@ -423,9 +422,6 @@ tracesys_sigexit:
 
 	*********************************************************/
 lws_start:
-	/* Gate and ensure we return to userspace */
-	gate	.+8, %r0
-	depi	3, 31, 2, %r31	/* Ensure we return to userspace */
 
 #ifdef CONFIG_64BIT
 	/* FIXME: If we are a 64-bit kernel just
@@ -473,7 +469,7 @@ lws_exit:
 	/* now reset the lowest bit of sp if it was set */
 	xor	%r30,%r1,%r30
 #endif
-	be,n	0(%sr3, %r31)
+	be,n	0(%sr7, %r31)
 
 
 	

Re: futex wait failure

[Helge Deller]

On 12/28/2009 07:59 PM, John David Anglin wrote:
> On Wed, 23 Dec 2009, Carlos O'Donell wrote:
>
>> We are just like every other architecture... with the exception that
>> we currently have more bugs :-)
>
> I have been looking at the lws implementation.  I've attached a patch
> with a couple of tweaks:

The patch looks good.

> 1) I changed the unconditional branch at the entry point to a gate.
> Didn't think it was a good idea to execute code at user priveledge.

Can you explain that?
The branch might get interrupted, before the process get privileged?

> This seems to have improved things (got through a complete testsuite
> run on gsyprf11 without a deadlock).

Good. I'll test too.

>However, I hit a slightly different lockup on c3750.

Any info?

> 2) Change return space register to sr7.  sr3 is not set correctly
> if the entry number is invalid.

Yep.

> Have nasty suspicion that sr3 is getting hit...

Helge

Re: futex wait failure

[John David Anglin]

> The patch looks good.
> 
> > 1) I changed the unconditional branch at the entry point to a gate.
> > Didn't think it was a good idea to execute code at user priveledge.
> 
> Can you explain that?

Not really, except that we gate immediately in the other code paths.
The gateway page is special in that processes are not supposed to get
scheduled off the page.

> The branch might get interrupted, before the process get privileged?

That was the concern.  At worst, an unnecessary branch is eliminated.
It's clear that this doesn't fix the futex deadlock, but the timing of
the lws lock code has changed resulting in slightly different symptoms.

> > This seems to have improved things (got through a complete testsuite
> > run on gsyprf11 without a deadlock).
> 
> Good. I'll test too.
> 
> >However, I hit a slightly different lockup on c3750.
> 
> Any info?

No, I restarted a new GCC build on this machine.  As with the previous
case on gsyprf11, thread 2 in expect seemed confused about its holding
the lock.  I've got a new hang on gsyprf11 to look at.

In my build last night on the c3750, expect dropped core in the GCC
testsuite.  Otherwise, it completed the GCC build and check.  I'll
look a bit at the core dump today.

On my rp3440 (UP kernel), I had several segmentation faults in /bin/sh
building GCC with 2.6.32.2.  For some reason, 2.6.31.9 is better.  I
haven't tried expect 5.44.1.14-5 on it.  It currently using expect-tcl8.3
which avoids the pthread issue.

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

Re: futex wait failure

[Randolph Chung]

> Not really, except that we gate immediately in the other code paths.
> The gateway page is special in that processes are not supposed to get
> scheduled off the page.
> 
>> The branch might get interrupted, before the process get privileged?
> 
> That was the concern.  At worst, an unnecessary branch is eliminated.
> It's clear that this doesn't fix the futex deadlock, but the timing of
> the lws lock code has changed resulting in slightly different symptoms.

IIRC we had to move the gate in the regular syscall path earlier as well 
to fix some security problems before. I don't recall the exact details, 
but I seem to recall it had to do with using ptrace(SINGLESTEP).

randolph

Re: futex wait failure

[Carlos O'Donell]

On Tue, Dec 29, 2009 at 8:47 AM, Helge Deller <deller@gmx.de> wrote:
>> 2) Change return space register to sr7. =A0sr3 is not set correctly
>> if the entry number is invalid.
>
> Yep.
>
>> Have nasty suspicion that sr3 is getting hit...

Is the thought here that we take an interrupt, and sr3 is not
guaranteed saved/restored, while sr7 is guaranteed?

I don't see anything wrong with moving the gate earlier (unless
someone can come up with a case where an LWS may not want to gate).

It has the benefit of making the fast path 1 instruction shorter,
however I don't see that it makes the implementation more correct.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Helge Deller]

On 12/31/2009 07:14 PM, Carlos O'Donell wrote:
> On Tue, Dec 29, 2009 at 8:47 AM, Helge Deller<deller@gmx.de>  wrote:
>>> 2) Change return space register to sr7.  sr3 is not set correctly
>>> if the entry number is invalid.
>>
>> Yep.
>>
>>> Have nasty suspicion that sr3 is getting hit...
>
> Is the thought here that we take an interrupt, and sr3 is not
> guaranteed saved/restored, while sr7 is guaranteed?
>
> I don't see anything wrong with moving the gate earlier (unless
> someone can come up with a case where an LWS may not want to gate).
>
> It has the benefit of making the fast path 1 instruction shorter,
> however I don't see that it makes the implementation more correct.

I tested the patch and the testcase in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203
still segfaults.

Nevertheless, I think Dave's patch should be applied...

Helge

Re: futex wait failure

[John David Anglin]

> 
> On Tue, Dec 29, 2009 at 8:47 AM, Helge Deller <deller@gmx.de> wrote:
> >> 2) Change return space register to sr7. =A0sr3 is not set correctly
> >> if the entry number is invalid.
> >
> > Yep.
> >
> >> Have nasty suspicion that sr3 is getting hit...
> 
> Is the thought here that we take an interrupt, and sr3 is not
> guaranteed saved/restored, while sr7 is guaranteed?

sr3 isn't guaranteed because user could have changed its value.  So,
it is better to use sr7 for the return, particularly when lws entry
number isn't valid.

Regarding the handling of space registers during interruptions, they
are not saved.  syscall_exit_rfi restores them to proper values:

        /*
	 * If we aren't being traced, we never saved space registers
	 * (we don't store them in the sigcontext), so set them
	 * to "proper" values now (otherwise we'll wind up restoring
	 * whatever was last stored in the task structure, which might
	 * be inconsistent if an interrupt occured while on the gateway
	 * page). Note that we may be "trashing" values the user put in
	 * them, but we don't support the user changing them.
	*/

	STREG   %r0,PT_SR2(%r16)
	mfsp    %sr3,%r19
	STREG   %r19,PT_SR0(%r16)
	STREG   %r19,PT_SR1(%r16)
	STREG   %r19,PT_SR3(%r16)

As can be seen, sr2 set to the kernel space and sr3 to the user space.
This is consistent with the usage in the LWS code, so an interruption
shouldn't be a problem on most syscall returns via this path.  However,
execve doesn't restore the space register values (at least in this path).

The comment in the LWS code is a bit misleading:

        /* WARNING: Trashing sr2 and sr3 */
	mfsp    %sr7,%r1                        /* get userspace into sr3 */
	mtsp    %r1,%sr3
	mtsp    %r0,%sr2                        /* get kernel space into sr2 */

Actually, sr2 and sr3 are restored to their "proper" values.

The TLB code seems to assume a consistent use of sr3.  So, this may not
be a space register issue.

The syscall_restore uses a rsm/ssm pair to make the operation atomic.
Maybe we don't catch all situations where process is scheduled.

As an aside, it seems gdb doesn't print space registers correctly
when debugging a program.  I would guess this is because they are
not saved in the context.  It does print them from a core dump.

> I don't see anything wrong with moving the gate earlier (unless
> someone can come up with a case where an LWS may not want to gate).
> 
> It has the benefit of making the fast path 1 instruction shorter,
> however I don't see that it makes the implementation more correct.

I believe that it does have an effect.  See for example, the discussion
regarding delivery of signals to processes executing on the gateway page
in traps.c.  With the branch, it is possible that a signal could be
sent to a process executing on the gateway page.  See also space_check
macro in entry.S.  There's also the ptrace issue mentioned by Randolph.

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

Re: futex wait failure

[John David Anglin]

> >> Actually I did tested this with the minifail test program, and changed
> >> thread_run() to call _exit(0) at the end instead of "return 0":
> >> void* thread_run(void* arg) {
> >>         ...
> >> /*      return (void *)&status;  */
> >>         _exit(0);
> >> }
> >> With strace I then suddenly got exit_group() which seems more correct:
> >> [pid  1910] write(1, "Thread OK.\n", 11) = 11
> >> [pid  1910] exit_group(0)               = ?

Did this fix minifail?

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

Re: futex wait failure

[John David Anglin]

> Regarding the handling of space registers during interruptions, they
> are not saved.  syscall_exit_rfi restores them to proper values:

This is potentially an implementation bug, particularly with respect to
interruptions.   User space probably should have sr0-sr3 available to
do icache flushes, etc.  Currently, gcc uses sr0 for icache flushes.

It may be sr0 is never clobbered, but this isn't clear.  I'm fairly sure
HP-UX saves sr0-sr4 if necessary.

Possibly, the icache flush sequence should be changed for linux to not
use sr0.

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

Re: futex wait failure

[John David Anglin]

> I tested the patch and the testcase in
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203
> still segfaults.

I think the expect/tcl bug and the bug 561203 are related.  Looking
at the minifail core dump, I see:

Core was generated by `./minifail'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000 in ?? ()

So, how did we get to 0?  $rp is 0, so we might have executed a
return to this location.  $r31 conains 0x4157cc4f.

(gdb) disass 0x4157cc3c 0x4157cc5c
Dump of assembler code from 0x4157cc3c to 0x4157cc5c:
0x4157cc3c <_IO_puts+332>:      copy rp,r25
0x4157cc40 <_IO_puts+336>:      copy r6,r24
0x4157cc44 <_IO_puts+340>:      be,l b0(sr2,r0),sr0,r31
0x4157cc48 <_IO_puts+344>:      ldi 0,r20
0x4157cc4c <_IO_puts+348>:      ldi -b,r24
0x4157cc50 <_IO_puts+352>:      cmpb,=,n r24,r21,0x4157cc38 <_IO_puts+328>
0x4157cc54 <_IO_puts+356>:      nop
0x4157cc58 <_IO_puts+360>:      ldi -2d,r25

So, it would see $r31 was last set by a call to the lws code.

(gdb) info thread
  2 Thread 2397  *__GI__IO_list_lock () at genops.c:1297
* 1 Thread 2398  0x00000000 in ?? ()

(gdb) thread 2
[Switching to thread 2 (Thread 2397)]#0  *__GI__IO_list_lock ()
    at genops.c:1297
1297    genops.c: No such file or directory.
        in genops.c
(gdb) bt
#0  *__GI__IO_list_lock () at genops.c:1297
#1  0x415c06d0 in __libc_fork () at ../nptl/sysdeps/unix/sysv/linux/fork.c:117
#2  0x00011068 in pure_test () at minifail.cpp:55
#3  0x00011350 in main (argc=1, argv=0xc0497028) at minifail.cpp:80

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

Re: futex wait failure

[John David Anglin]

> Core was generated by `./minifail'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00000000 in ?? ()

I wasn't able to duplicate the above running minifail under gdb.
However, I did eventually get it to hang.

(gdb) info thread
  2 Thread 0x42169480 (LWP 3246)  0x40240760 in start_thread (arg=0x42169480)
    at pthread_create.c:293
* 1 Thread 0x400040c0 (LWP 3245)  0x40240c2c in pthread_join (
  threadid=1108776064, thread_return=0x0) at pthread_join.c:89
(gdb) bt
#0  0x40240c2c in pthread_join (threadid=1108776064, thread_return=0x0)
    at pthread_join.c:89
#1  0x00011118 in pure_test () at minifail.cpp:70
#2  0x00011350 in main (argc=1, argv=0xbffd3020) at minifail.cpp:80
(gdb) disass 0x40240c1c 0x40240c3c
Dump of assembler code from 0x40240c1c to 0x40240c3c:
0x40240c1c <pthread_join+268>:  copy r3,r26
0x40240c20 <pthread_join+272>:  copy r19,r4
0x40240c24 <pthread_join+276>:  be,l 100(sr2,r0),sr0,r31
0x40240c28 <pthread_join+280>:  ldi d2,r20
0x40240c2c <pthread_join+284>:  copy r4,r19
0x40240c30 <pthread_join+288>:  ldw 68(r5),r24
0x40240c34 <pthread_join+292>:  cmpib,<> 0,r24,0x40240c18 <pthread_join+264>
0x40240c38 <pthread_join+296>:  ldi 0,r23
End of assembler dump.

So, thread 1 is in a syscall.

(gdb) thread 2
[Switching to thread 2 (Thread 0x42169480 (LWP 3246))]#0  0x40240760 in start_thread (arg=0x42169480) at pthread_create.c:293
293     pthread_create.c: No such file or directory.
        in pthread_create.c
(gdb) bt
#0  0x40240760 in start_thread (arg=0x42169480) at pthread_create.c:293
#1  0x412082bc in clone () from /lib/libc.so.6
#2  0x00000000 in ?? ()
(gdb) disass 0x40240760 0x402407a0
Dump of assembler code from 0x40240754 to 0x402407a8:
0x40240754 <start_thread+1108>: ldw 214(ret0),rp
0x40240758 <start_thread+1112>: copy r3,r26
0x40240760 <start_thread+1120>: copy r4,r24
0x40240764 <start_thread+1124>: be,l b0(sr2,r0),sr0,r31
0x40240768 <start_thread+1128>: ldi 0,r20
0x4024076c <start_thread+1132>: ldi -b,r24
0x40240770 <start_thread+1136>: cmpb,=,n r24,r21,0x40240758 <start_thread+1112>
0x40240774 <start_thread+1140>: nop
0x40240778 <start_thread+1144>: ldi -2d,r25
0x4024077c <start_thread+1148>: cmpb,=,n r25,r21,0x40240758 <start_thread+1112>
0x40240780 <start_thread+1152>: nop
0x40240784 <start_thread+1156>: stw ret0,-1b8(sp)
0x40240788 <start_thread+1160>: sub r0,r21,r21
0x4024078c <start_thread+1164>: stw r21,-1b4(sp)
0x40240790 <start_thread+1168>: ldw -1b4(sp),ret1
0x40240794 <start_thread+1172>: cmpib,=,n e,ret1,0x40240804 <start_thread+1284>
0x40240798 <start_thread+1176>: ldw -1b4(sp),ret0
0x4024079c <start_thread+1180>: cmpb,=,n r5,ret0,0x40240804 <start_thread+1284>
0x402407a0 <start_thread+1184>: ldw -1b8(sp),ret0
0x402407a4 <start_thread+1188>: cmpb,<> ret0,rp,0x40240754 <start_thread+1108>

Thread 2 is in a loop calling the lws code.

(gdb) p/x $rp
$5 = 0x0
(gdb) p/x $ret0
$6 = 0x42169480

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

Re: futex wait failure

[Helge Deller]

> > I tested the patch and the testcase in
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D561203
> > still segfaults.
>=20
> I think the expect/tcl bug and the bug 561203 are related.  Looking
> at the minifail core dump, I see:
>=20
> Core was generated by `./minifail'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x00000000 in ?? ()
>=20
> So, how did we get to 0?  $rp is 0, so we might have executed a
> return to this location.  $r31 conains 0x4157cc4f.
>=20
> (gdb) disass 0x4157cc3c 0x4157cc5c
> Dump of assembler code from 0x4157cc3c to 0x4157cc5c:
> 0x4157cc3c <_IO_puts+332>:      copy rp,r25
> 0x4157cc40 <_IO_puts+336>:      copy r6,r24
> 0x4157cc44 <_IO_puts+340>:      be,l b0(sr2,r0),sr0,r31
> 0x4157cc48 <_IO_puts+344>:      ldi 0,r20
> 0x4157cc4c <_IO_puts+348>:      ldi -b,r24
> 0x4157cc50 <_IO_puts+352>:      cmpb,=3D,n r24,r21,0x4157cc38 <_IO_pu=
ts+328>
> 0x4157cc54 <_IO_puts+356>:      nop
> 0x4157cc58 <_IO_puts+360>:      ldi -2d,r25


I think I have an idea what could have happened and why it most of the =
times (but not always) crashes in the child process...

In ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h we have:
#define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \
  ({                                                                   =
 \
     volatile int lws_errno;                                           =
 \
     volatile int lws_ret;                                             =
 \
     asm volatile(                                                     =
 \
=2E..some assembly...
        "stw    %%r28, %0                       \n\t"                  =
 \
        "sub    %%r0, %%r21, %%r21              \n\t"                  =
 \
        "stw    %%r21, %1                       \n\t"                  =
 \
        : "=3Dm" (lws_ret), "=3Dm" (lws_errno)                         =
     \
        : "r" (mem), "r" (oldval), "r" (newval)                        =
 \
        : _LWS_CLOBBER          =20

this means, that lws_errno and lws_ret are located on the stack.

With gdb I see this expanded to:
0x40705494 <start_thread+1204>: stw ret0,-1b8(sp)
0x40705498 <start_thread+1208>: sub r0,r21,r21
0x4070549c <start_thread+1212>: stw r21,-1b4(sp)

So, lws_ret/lws_errno are at -1b8/-1b4(sp).

And this LWS code is called from=20
=2E./nptl/sysdeps/pthread/createthread.c:
static int create_thread (struct pthread *pd, const struct pthread_attr=
 *attr, STACK_VARIABLES_PARMS)
=2E..
          int res =3D do_clone (pd, attr, clone_flags, start_thread,
                              STACK_VARIABLES_ARGS, 1);
          if (res =3D=3D 0)
            {
=2E..(line 216):
              /* Enqueue the descriptor.  */
              do
                pd->nextevent =3D __nptl_last_event;
              while (atomic_compare_and_exchange_bool_acq(&__nptl_last_=
event, pd, pd->nextevent) !=3D 0);


And here is what could have happened:
a) do_clone() creates the child process.
b) the child process gets a new stack
c) the child calls atomic_compare_and_exchange_bool_acq() and thus the =
LWS code above.
d) the LWS code writes to the stack location at -1b8(sp), which is out =
of bounds for the child process (the child stack got only ~ 0x40 bytes =
initial room)
e) Thus the child either crashes, overwrites memory of the parent or do=
es other things wrong.

Additionally:
Due to the LWS assembly code and because we don't have many registers f=
ree while using LWS, gcc used %rp as a temporary register which may hav=
e fooled us in our thinking?

0x40705458 <start_thread+1144>: ldi 0,rp
0x4070545c <start_thread+1148>: ldi fb,r3
0x40705460 <start_thread+1152>: ldw -70(sp),ret0
0x40705464 <start_thread+1156>: ldw 214(ret0),ret1
0x40705468 <start_thread+1160>: copy r5,r26
0x4070546c <start_thread+1164>: copy ret1,r25
0x40705470 <start_thread+1168>: copy rp,r24
0x40705474 <start_thread+1172>: be,l b0(sr2,r0),sr0,r31
0x40705478 <start_thread+1176>: ldi 0,r20
0x4070547c <start_thread+1180>: ldi -b,r24
0x40705480 <start_thread+1184>: cmpb,=3D,n r24,r21,0x40705468 <start_th=
read+1160>
0x40705484 <start_thread+1188>: nop
0x40705488 <start_thread+1192>: ldi -2d,r25
0x4070548c <start_thread+1196>: cmpb,=3D,n r25,r21,0x40705468 <start_th=
read+1160>
0x40705490 <start_thread+1200>: nop
0x40705494 <start_thread+1204>: stw ret0,-1b8(sp)
0x40705498 <start_thread+1208>: sub r0,r21,r21
0x4070549c <start_thread+1212>: stw r21,-1b4(sp)
0x407054a0 <start_thread+1216>: ldw -1b4(sp),ret0


If my assumptions are correct, then we either could

a) use the gcc atomic builtins instead of own atomic code in libc6:
E.g: add to ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:
=2E..
#if __GNUC_PREREQ (4, 1)
# define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \
  __sync_val_compare_and_swap (mem, oldval, newval)
#  define atomic_compare_and_exchange_bool_acq(mem, newval, oldval) \
  (! __sync_bool_compare_and_swap (mem, oldval, newval))

#elif __ASSUME_LWS_CAS
=2E...

b) change the assembly in=20
atomic_compare_and_exchange_val_acq()
to not put it's local variables (lws_errno and lws_ret) on the stack.

I'm currently testing option a).

Helge
(PS: I used a webmailer, so the indenting might be strange...)
--=20
GRATIS f=FCr alle GMX-Mitglieder: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Carlos O'Donell]

On Mon, Jan 4, 2010 at 11:27 AM, Helge Deller <deller@gmx.de> wrote:
> I think I have an idea what could have happened and why it most of th=
e times (but not always) crashes in the child process...
>
> In ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h we have:
> #define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \
> =A0({ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
\
> =A0 =A0 volatile int lws_errno; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> =A0 =A0 volatile int lws_ret; =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> =A0 =A0 asm volatile( =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> ...some assembly...
> =A0 =A0 =A0 =A0"stw =A0 =A0%%r28, %0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 \n\t" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0 =A0 =A0 =A0"sub =A0 =A0%%r0, %%r21, %%r21 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0\n\t" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0 =A0 =A0 =A0"stw =A0 =A0%%r21, %1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 \n\t" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0 =A0 =A0 =A0: "=3Dm" (lws_ret), "=3Dm" (lws_errno) =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> =A0 =A0 =A0 =A0: "r" (mem), "r" (oldval), "r" (newval) =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \
> =A0 =A0 =A0 =A0: _LWS_CLOBBER
>
> this means, that lws_errno and lws_ret are located on the stack.

Correct. We could place them in registers if we wanted, they are
registers r28 (lws return) and r21 (lws error).

> With gdb I see this expanded to:
> 0x40705494 <start_thread+1204>: stw ret0,-1b8(sp)
> 0x40705498 <start_thread+1208>: sub r0,r21,r21
> 0x4070549c <start_thread+1212>: stw r21,-1b4(sp)
>
> So, lws_ret/lws_errno are at -1b8/-1b4(sp).

Correct.

> And this LWS code is called from
> ../nptl/sysdeps/pthread/createthread.c:
> static int create_thread (struct pthread *pd, const struct pthread_at=
tr *attr, STACK_VARIABLES_PARMS)
> ...
> =A0 =A0 =A0 =A0 =A0int res =3D do_clone (pd, attr, clone_flags, start=
_thread,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0STACK_VARI=
ABLES_ARGS, 1);
> =A0 =A0 =A0 =A0 =A0if (res =3D=3D 0)
> =A0 =A0 =A0 =A0 =A0 =A0{
> ...(line 216):
> =A0 =A0 =A0 =A0 =A0 =A0 =A0/* Enqueue the descriptor. =A0*/
> =A0 =A0 =A0 =A0 =A0 =A0 =A0do
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0pd->nextevent =3D __nptl_last_event;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0while (atomic_compare_and_exchange_bool_ac=
q(&__nptl_last_event, pd, pd->nextevent) !=3D 0);
>
>
> And here is what could have happened:
> a) do_clone() creates the child process.
> b) the child process gets a new stack
> c) the child calls atomic_compare_and_exchange_bool_acq() and thus th=
e LWS code above.
> d) the LWS code writes to the stack location at -1b8(sp), which is ou=
t of bounds for the child process (the child stack got only ~ 0x40 byte=
s initial room)

This is wrong. Each thread should have 8MB of stack. If we only get ~
0x40 bytes then npt/nptl-init.c is setting __default_stacksize
incorrectly.

Even PTHREAD_STACK_MIN should be 16kb?

Could you verify that your assertion that only ~ 0x40 bytes of initial
room were allocated?

> e) Thus the child either crashes, overwrites memory of the parent or =
does other things wrong.

I agree with your analysis, but the error is that more stack should be
allocated.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

> I think I have an idea what could have happened and why it most of the times (but not always) crashes in the child process...
> 
> In ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h we have:
> #define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \
>   ({                                                                    \
>      volatile int lws_errno;                                            \
>      volatile int lws_ret;                                              \
>      asm volatile(                                                      \
> ...some assembly...
>         "stw    %%r28, %0                       \n\t"                   \
>         "sub    %%r0, %%r21, %%r21              \n\t"                   \
>         "stw    %%r21, %1                       \n\t"                   \
>         : "=m" (lws_ret), "=m" (lws_errno)                              \
>         : "r" (mem), "r" (oldval), "r" (newval)                         \
>         : _LWS_CLOBBER           
> 
> this means, that lws_errno and lws_ret are located on the stack.
> 
> With gdb I see this expanded to:
> 0x40705494 <start_thread+1204>: stw ret0,-1b8(sp)
> 0x40705498 <start_thread+1208>: sub r0,r21,r21
> 0x4070549c <start_thread+1212>: stw r21,-1b4(sp)
> 
> So, lws_ret/lws_errno are at -1b8/-1b4(sp).
> 
> And this LWS code is called from 
> ../nptl/sysdeps/pthread/createthread.c:
> static int create_thread (struct pthread *pd, const struct pthread_attr *attr, STACK_VARIABLES_PARMS)
> ...
>           int res = do_clone (pd, attr, clone_flags, start_thread,
>                               STACK_VARIABLES_ARGS, 1);
>           if (res == 0)
>             {
> ...(line 216):
>               /* Enqueue the descriptor.  */
>               do
>                 pd->nextevent = __nptl_last_event;
>               while (atomic_compare_and_exchange_bool_acq(&__nptl_last_event, pd, pd->nextevent) != 0);
> 
> 
> And here is what could have happened:
> a) do_clone() creates the child process.
> b) the child process gets a new stack
> c) the child calls atomic_compare_and_exchange_bool_acq() and thus the LWS code above.
> d) the LWS code writes to the stack location at -1b8(sp), which is out of bounds for the child process (the child stack got only ~ 0x40 bytes initial room)

I think the stack locations should be ok because start_thread allocates
an additional 0x1c0 bytes:

Dump of assembler code for function start_thread:
   0x40a40300 <+0>:     stw rp,-14(sp)
   0x40a40304 <+4>:     ldo 1c0(sp),sp

In all the fails I have looked at, the saved $rp value is clobbered.
The stack pointer value seems consistent with 0x40 + 0x1c0.  The data
placed at the beginning of the stack for the child thread is not clobbered.

> e) Thus the child either crashes, overwrites memory of the parent or does other things wrong.

I don't see how the forked child can affect the memory of the parent.
It can close files and affect the parent that way (child should use
_exit and not exit).

If the forked child actually overwrites memory of the parent, this is
a big bug in the linux fork code.

> Additionally:
> Due to the LWS assembly code and because we don't have many registers free while using LWS, gcc used %rp as a temporary register which may have fooled us in our thinking?

$rp is saved in the first instruction of start_thread.  So, its use
below should be ok.

> 0x40705458 <start_thread+1144>: ldi 0,rp
> 0x4070545c <start_thread+1148>: ldi fb,r3
> 0x40705460 <start_thread+1152>: ldw -70(sp),ret0
> 0x40705464 <start_thread+1156>: ldw 214(ret0),ret1
> 0x40705468 <start_thread+1160>: copy r5,r26
> 0x4070546c <start_thread+1164>: copy ret1,r25
> 0x40705470 <start_thread+1168>: copy rp,r24
> 0x40705474 <start_thread+1172>: be,l b0(sr2,r0),sr0,r31
> 0x40705478 <start_thread+1176>: ldi 0,r20
> 0x4070547c <start_thread+1180>: ldi -b,r24
> 0x40705480 <start_thread+1184>: cmpb,=,n r24,r21,0x40705468 <start_thread+1160>
> 0x40705484 <start_thread+1188>: nop
> 0x40705488 <start_thread+1192>: ldi -2d,r25
> 0x4070548c <start_thread+1196>: cmpb,=,n r25,r21,0x40705468 <start_thread+1160>
> 0x40705490 <start_thread+1200>: nop
> 0x40705494 <start_thread+1204>: stw ret0,-1b8(sp)
> 0x40705498 <start_thread+1208>: sub r0,r21,r21
> 0x4070549c <start_thread+1212>: stw r21,-1b4(sp)
> 0x407054a0 <start_thread+1216>: ldw -1b4(sp),ret0
> 
> 
> If my assumptions are correct, then we either could
> 
> a) use the gcc atomic builtins instead of own atomic code in libc6:
> E.g: add to ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:
> ...
> #if __GNUC_PREREQ (4, 1)
> # define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \
>   __sync_val_compare_and_swap (mem, oldval, newval)
> #  define atomic_compare_and_exchange_bool_acq(mem, newval, oldval) \
>   (! __sync_bool_compare_and_swap (mem, oldval, newval))
> 
> #elif __ASSUME_LWS_CAS
> ....

There may be a bug in the gcc atomic builtins.  We shanged recently
to using the sync builtins in libstdc++.  Then, two fails appeared
recently that I haven't had time to look at:

WARNING: program timed out.
FAIL: 29_atomics/atomic_flag/clear/1.c execution test
FAIL: 29_atomics/atomic_flag/test_and_set/explicit.c execution test

That said, this is an interesting test.  Does it fix minifail?

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

Re: futex wait failure

[Carlos O'Donell]

On Mon, Jan 4, 2010 at 12:32 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> e) Thus the child either crashes, overwrites memory of the parent or does other things wrong.
>
> I don't see how the forked child can affect the memory of the parent.
> It can close files and affect the parent that way (child should use
> _exit and not exit).
>
> If the forked child actually overwrites memory of the parent, this is
> a big bug in the linux fork code.

We have two bugs that are getting mixed here.

Your original post has to do with a futex wait failure, this is
possibly related to the hppa low level lock implementation. I am
updating the hppa implementation to see if I can fix this for you.

Helge's comments relate only to the vfork crash, and the Qt thread
creation issue being seen by debian.

Cheers,
Carlos.

Re: futex wait failure

[John David Anglin]

On Mon, 04 Jan 2010, Carlos O'Donell wrote:

> On Mon, Jan 4, 2010 at 11:27 AM, Helge Deller <deller@gmx.de> wrote:
> This is wrong. Each thread should have 8MB of stack. If we only get ~
> 0x40 bytes then npt/nptl-init.c is setting __default_stacksize
> incorrectly.

The 0x40 bytes is the initial frame allocated for clone running in
the child thread.   The code is not running out of stack space.

> Even PTHREAD_STACK_MIN should be 16kb?
> 
> Could you verify that your assertion that only ~ 0x40 bytes of initial
> room were allocated?
> 
> > e) Thus the child either crashes, overwrites memory of the parent or does other things wrong.
> 
> I agree with your analysis, but the error is that more stack should be
> allocated.

I don't follow that conclusion.  The stack grows upward and the stack
pointer isn't out of range.   The fork operation is somehow
corrupting the stack memory of the thread created by pthread_create.
I would say the parent is corrupting its own memory.  I doubt the
forked child is affecting the parent.  Fork would have to behave like
vfork to do this.  I have seen the pthread_create thread fail before
the clone syscall of the following fork.

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

Re: futex wait failure

[John David Anglin]

On Mon, 04 Jan 2010, Carlos O'Donell wrote:

> On Mon, Jan 4, 2010 at 12:32 PM, John David Anglin
> <dave@hiauly1.hia.nrc.ca> wrote:
> >> e) Thus the child either crashes, overwrites memory of the parent or does other things wrong.
> >
> > I don't see how the forked child can affect the memory of the parent.
> > It can close files and affect the parent that way (child should use
> > _exit and not exit).
> >
> > If the forked child actually overwrites memory of the parent, this is
> > a big bug in the linux fork code.
> 
> We have two bugs that are getting mixed here.
> 
> Your original post has to do with a futex wait failure, this is
> possibly related to the hppa low level lock implementation. I am
> updating the hppa implementation to see if I can fix this for you.
> 
> Helge's comments relate only to the vfork crash, and the Qt thread
> creation issue being seen by debian.

I was talking about the debian thread creation bug in the above.
I haven't been able to duplicate the vfork crash that you posted.
The expect/tcl futex bug is likely related to the debian bug (this
is what expect does in testsuite runs).  Reduced minifail testcase
is below.

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

#include <pthread.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

/*
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203

  clone(child_stack=0x4088d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x4108c4e8, tls=0x4108c900, child_tidptr=0x4108c4e8) = 14819
[pid 14819] set_robust_list(0x4108c4f0, 0xc) = 0
[pid 14818] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 14820

 g++  minifail.cpp -o minifail -O0 -pthread -g

 i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail; done;

 */
void* thread_run(void* arg) {
	write(1,"Thread OK.\n",11);
}

int pure_test() {
	pthread_t thread;
	pthread_create(&thread, NULL, thread_run, NULL);

	switch (fork()) {
		case -1:
			perror("fork() failed");
		case 0:
			write(1,"Child OK.\n",10);
			_exit(0);
		default:
			break;
		
	}
	
	pthread_join(thread, NULL);
	return 0;
}

int main(int argc, char** argv) {
	return pure_test();
}

Re: futex wait failure

[John David Anglin]

> On Mon, 04 Jan 2010, Carlos O'Donell wrote:
> 
> > On Mon, Jan 4, 2010 at 11:27 AM, Helge Deller <deller@gmx.de> wrote:
> > This is wrong. Each thread should have 8MB of stack. If we only get ~
> > 0x40 bytes then npt/nptl-init.c is setting __default_stacksize
> > incorrectly.
> 
> The 0x40 bytes is the initial frame allocated for clone running in
> the child thread.   The code is not running out of stack space.

If only 0x40 bytes of stack were allocated, start_thread would fault
almost immediately:

Dump of assembler code for function start_thread:
   0x40a40300 <+0>:     stw rp,-14(sp)
   0x40a40304 <+4>:     ldo 1c0(sp),sp
   0x40a40308 <+8>:     ldo 274(r26),r21
   0x40a4030c <+12>:    stw r9,-6c(sp)

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

Re: futex wait failure

[Helge Deller]

On 01/04/2010 07:11 PM, John David Anglin wrote:
> On Mon, 04 Jan 2010, Carlos O'Donell wrote:
>
>> On Mon, Jan 4, 2010 at 11:27 AM, Helge Deller<deller@gmx.de>  wrote:
>> This is wrong. Each thread should have 8MB of stack. If we only get ~
>> 0x40 bytes then npt/nptl-init.c is setting __default_stacksize
>> incorrectly.
>
> The 0x40 bytes is the initial frame allocated for clone running in
> the child thread.   The code is not running out of stack space.

Hmmm...

strace on minifail (as attached to Dave's mail) gives me:

getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
mmap(NULL, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4076d000
brk(0)                                  = 0x12000
brk(0x33000)                            = 0x33000
mprotect(0x40f6b000, 4096, PROT_NONE)   = 0
clone(Process 1684 attached (waiting for parent)
Process 1684 resumed (parent 1683 ready)
child_stack=0x4076d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40f6c4e8, tls=0x40f6c900, child_tidptr=0x40f6c4e8) = 1684

The mmap() allocates and maps the new child stack -> at 0x4076d000
The clone() syscall is called with child_stack=0x4076d040

I might be wrong, but that's the 0x40 bytes I mentioned.
  
>> Even PTHREAD_STACK_MIN should be 16kb?

The example above allocates 8MB.
But my point is, that child_stack starts at 0x4076d040, and
that LWS (in the child process with the stack as given above) tries to
store something to an address lower than 0x4076d000.

>> Could you verify that your assertion that only ~ 0x40 bytes of initial
>> room were allocated?
>>
>>> e) Thus the child either crashes, overwrites memory of the parent or does other things wrong.
>>
>> I agree with your analysis, but the error is that more stack should be
>> allocated.

Not more stack.
Just increasing the 0x40 initial byte offset, but that's IMHO a hack...

> I don't follow that conclusion.  The stack grows upward and the stack
> pointer isn't out of range.   The fork operation is somehow
> corrupting the stack memory of the thread created by pthread_create.
> I would say the parent is corrupting its own memory.  I doubt the
> forked child is affecting the parent.  Fork would have to behave like
> vfork to do this.  I have seen the pthread_create thread fail before
> the clone syscall of the following fork.

Doesn't pthread_create() created processes share the memory with
their parents? In that case, the child can crash or even overwrite memory
of the parent process...?

Helge

Re: futex wait failure

[Helge Deller]

On 01/04/2010 05:27 PM, Helge Deller wrote:
> If my assumptions are correct, then we either could
>
> a) use the gcc atomic builtins instead of own atomic code in libc6:
> E.g: add to ports/sysdeps/unix/sysv/linux/hppa/bits/atomic.h:
> ...
> #if __GNUC_PREREQ (4, 1)
> # define atomic_compare_and_exchange_val_acq(mem, newval, oldval) \
>    __sync_val_compare_and_swap (mem, oldval, newval)
> #  define atomic_compare_and_exchange_bool_acq(mem, newval, oldval) \
>    (! __sync_bool_compare_and_swap (mem, oldval, newval))
>
> #elif __ASSUME_LWS_CAS
> ....


Even with this change, minifail sadly still segfaults :-(

Helge

Re: futex wait failure

[John David Anglin]

> On 01/04/2010 07:11 PM, John David Anglin wrote:
> > On Mon, 04 Jan 2010, Carlos O'Donell wrote:
> >
> >> On Mon, Jan 4, 2010 at 11:27 AM, Helge Deller<deller@gmx.de>  wrote:
> >> This is wrong. Each thread should have 8MB of stack. If we only get ~
> >> 0x40 bytes then npt/nptl-init.c is setting __default_stacksize
> >> incorrectly.
> >
> > The 0x40 bytes is the initial frame allocated for clone running in
> > the child thread.   The code is not running out of stack space.
> 
> Hmmm...
> 
> strace on minifail (as attached to Dave's mail) gives me:
> 
> getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
> mmap(NULL, 8388608, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4076d000
> brk(0)                                  = 0x12000
> brk(0x33000)                            = 0x33000
> mprotect(0x40f6b000, 4096, PROT_NONE)   = 0
> clone(Process 1684 attached (waiting for parent)
> Process 1684 resumed (parent 1683 ready)
> child_stack=0x4076d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40f6c4e8, tls=0x40f6c900, child_tidptr=0x40f6c4e8) = 1684
> 
> The mmap() allocates and maps the new child stack -> at 0x4076d000
> The clone() syscall is called with child_stack=0x4076d040

So, in this case, start_thread will be called with $sp = 0x4076d040.
The second instruction of start_thread increments $sp by 0x1c0.

> 
> I might be wrong, but that's the 0x40 bytes I mentioned.
>   
> >> Even PTHREAD_STACK_MIN should be 16kb?
> 
> The example above allocates 8MB.
> But my point is, that child_stack starts at 0x4076d040, and
> that LWS (in the child process with the stack as given above) tries to
> store something to an address lower than 0x4076d000.

This would be bad.  However, the LWS calls are in "start_thread", so
it didn't appear that the stack offsets that you mentioned were out
of range.  GCC would be terribly broken if it got these offsets wrong
in general.

> >> Could you verify that your assertion that only ~ 0x40 bytes of initial
> >> room were allocated?
> >>
> >>> e) Thus the child either crashes, overwrites memory of the parent or does other things wrong.
> >>
> >> I agree with your analysis, but the error is that more stack should be
> >> allocated.
> 
> Not more stack.
> Just increasing the 0x40 initial byte offset, but that's IMHO a hack...
> 
> > I don't follow that conclusion.  The stack grows upward and the stack
> > pointer isn't out of range.   The fork operation is somehow
> > corrupting the stack memory of the thread created by pthread_create.
> > I would say the parent is corrupting its own memory.  I doubt the
> > forked child is affecting the parent.  Fork would have to behave like
> > vfork to do this.  I have seen the pthread_create thread fail before
> > the clone syscall of the following fork.
> 
> Doesn't pthread_create() created processes share the memory with
> their parents? In that case, the child can crash or even overwrite memory
> of the parent process...?

We have to be careful about semantics.  The child of the fork runs
in a different address space, so it is unlikely that it can corrupt
the parent directly.  It is true that the child inherits all the
pthread mutexs and the thread context of the thread which called fork.
The child could close the file descriptors of the parent.  It could
affect any context that is stored in the kernel.

The fork call is involved in this bug.  I have verified that the faults
don't occur if it is removed.  The faults don't occur if a sleep(1) call
is added between the pthread_create and fork calls.

I think the parent thread is corrupting the stack of the child thread
created by pthread_create, but I don't know how this happens.  I have
seen at least one case where this corruption occurs prior to the system
clone call for the fork.  I think we must have some kind of lock
failure which is timing dependent (i.e., the scheduling of the parent
and child threads).

I thought this likely indicated the lws code wasn't atomic.  We don't
allow schedule to run if we are on the gateway page.  I'm starting
to wonder if threads (not processes) are still being scheduled.

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

Re: futex wait failure

[John David Anglin]

> clone(Process 1684 attached (waiting for parent)
> Process 1684 resumed (parent 1683 ready)
> child_stack=0x4076d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40f6c4e8, tls=0x40f6c900, child_tidptr=0x40f6c4e8) = 1684

I noticed the tidptr for the fork may not be correct:

clone(child_stack=0x40e87040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x416864e8, tls=0x41686900, child_tidptr=0x416864e8) = 31613
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 31614

I would have thought the value should have been the same as that in the
clone from the pthread_create call.

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

Re: futex wait failure

[John David Anglin]

> > clone(Process 1684 attached (waiting for parent)
> > Process 1684 resumed (parent 1683 ready)
> > child_stack=0x4076d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40f6c4e8, tls=0x40f6c900, child_tidptr=0x40f6c4e8) = 1684
> 
> I noticed the tidptr for the fork may not be correct:
> 
> clone(child_stack=0x40e87040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x416864e8, tls=0x41686900, child_tidptr=0x416864e8) = 31613
> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 31614
> 
> I would have thought the value should have been the same as that in the
> clone from the pthread_create call.

It's possible that this is done intentionally...  The parent_tidptr
is the one that's wrong in the first clone.

I have noticed something else in the minifail kernel register dumps:

Jan  6 15:54:05 hiauly6 kernel: sr00-03  00000024 0000001b 00000000 00000024
Jan  6 15:54:05 hiauly6 kernel: sr04-07  00000024 00000024 00000024 00000024

sr1 seems to contain an odd value.  This seems to be the case in all
minifail register dumps.  I checked that the sr1 value doesn't belong
to the child of the fork call.  This might indicate a tlb/cache issue
as sr1 is used for these operations.

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

Re: futex wait failure

[Helge Deller]

On 01/07/2010 12:33 AM, John David Anglin wrote:
>>> clone(Process 1684 attached (waiting for parent)
>>> Process 1684 resumed (parent 1683 ready)
>>> child_stack=0x4076d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40f6c4e8, tls=0x40f6c900, child_tidptr=0x40f6c4e8) = 1684
>>
>> I noticed the tidptr for the fork may not be correct:
>>
>> clone(child_stack=0x40e87040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x416864e8, tls=0x41686900, child_tidptr=0x416864e8) = 31613
>> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 31614
>>
>> I would have thought the value should have been the same as that in the
>> clone from the pthread_create call.
>
> It's possible that this is done intentionally...  The parent_tidptr
> is the one that's wrong in the first clone.
>
> I have noticed something else in the minifail kernel register dumps:
>
> Jan  6 15:54:05 hiauly6 kernel: sr00-03  00000024 0000001b 00000000 00000024
> Jan  6 15:54:05 hiauly6 kernel: sr04-07  00000024 00000024 00000024 00000024
>
> sr1 seems to contain an odd value.  This seems to be the case in all
> minifail register dumps.

IIRC, for me most crashes had sr1=0. Only a very few had sr1 != 0.

> I checked that the sr1 value doesn't belong
> to the child of the fork call.  This might indicate a tlb/cache issue
> as sr1 is used for these operations.

Helge

Re: futex wait failure

[John David Anglin]

> 
> On 01/07/2010 12:33 AM, John David Anglin wrote:
> >>> clone(Process 1684 attached (waiting for parent)
> >>> Process 1684 resumed (parent 1683 ready)
> >>> child_stack=0x4076d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40f6c4e8, tls=0x40f6c900, child_tidptr=0x40f6c4e8) = 1684
> >>
> >> I noticed the tidptr for the fork may not be correct:
> >>
> >> clone(child_stack=0x40e87040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x416864e8, tls=0x41686900, child_tidptr=0x416864e8) = 31613
> >> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 31614
> >>
> >> I would have thought the value should have been the same as that in the
> >> clone from the pthread_create call.
> >
> > It's possible that this is done intentionally...  The parent_tidptr
> > is the one that's wrong in the first clone.

I now think this probably is a glibc bug.  The kernel uses this value
when the CLONE_PARENT_SETTID flag is passed.

> > I have noticed something else in the minifail kernel register dumps:
> >
> > Jan  6 15:54:05 hiauly6 kernel: sr00-03  00000024 0000001b 00000000 00000024
> > Jan  6 15:54:05 hiauly6 kernel: sr04-07  00000024 00000024 00000024 00000024
> >
> > sr1 seems to contain an odd value.  This seems to be the case in all
> > minifail register dumps.
> 
> IIRC, for me most crashes had sr1=0. Only a very few had sr1 != 0.
> 
> > I checked that the sr1 value doesn't belong
> > to the child of the fork call.  This might indicate a tlb/cache issue
> > as sr1 is used for these operations.

I added some loops in the parent and child threads.  I also added code
in the child thread to watch the return point location on the stack
for start_thread.  What I found is the stack gets overwritten after
the thread has started.  At the same time, the parent is looping
post fork.

So, the problem has to be with fork (i.e., its not with pthread_join
or pthread_exit).  Still think the problem involves sr1 (it's unusual
the sr1 contains a value that's not the user or kernel values).

I played with saving sr1 in some additional places (tlb and cache
flushing) but this didn't alter things.  Haven't played with pa_memcpy.

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

Re: futex wait failure

[John David Anglin]

> I added some loops in the parent and child threads.  I also added code
> in the child thread to watch the return point location on the stack
> for start_thread.  What I found is the stack gets overwritten after
> the thread has started.  At the same time, the parent is looping
> post fork.

More debugging.  It seems bad news to have more than one clone
syscall active at a time.  The thread child may still be in the kernel
when the fork syscall is made by the parent.  The testcase doesn't
fail if the parent waits for the child thread to start.  See below.

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

#include <pthread.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

/*
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203

  clone(child_stack=0x4088d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x4108c4e8, tls=0x4108c900, child_tidptr=0x4108c4e8) = 14819
[pid 14819] set_robust_list(0x4108c4f0, 0xc) = 0
[pid 14818] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 14820

 g++  minifail.cpp -o minifail -O0 -pthread -g

 i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail; done;

 */

static volatile int run;

void* thread_run(void* arg) {
	static long status;
	int i;
        
	run = 1;
	pthread_yield();
	for (i = 10000000; i; i--)
	   continue;
	write(1,"Thread OK.\n",11);
	return (void *)&status;
}

int pure_test() {
	pthread_t thread;
	pthread_create(&thread, NULL, thread_run, NULL);

	while (!run)
	  continue;
	switch (fork()) {
		case -1:
			perror("fork() failed");
		case 0:
			write(1,"Child OK.\n",10);
			_exit(0);
		default:
			break;
		
	}
	pthread_join(thread, NULL);
	return 0;
}

int main(int argc, char** argv) {
	return pure_test();
}

Re: futex wait failure

[Helge Deller]

On 01/08/2010 05:37 PM, John David Anglin wrote:
>>
>> On 01/07/2010 12:33 AM, John David Anglin wrote:
>>>>> clone(Process 1684 attached (waiting for parent)
>>>>> Process 1684 resumed (parent 1683 ready)
>>>>> child_stack=0x4076d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x40f6c4e8, tls=0x40f6c900, child_tidptr=0x40f6c4e8) = 1684
>>>>
>>>> I noticed the tidptr for the fork may not be correct:
>>>>
>>>> clone(child_stack=0x40e87040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x416864e8, tls=0x41686900, child_tidptr=0x416864e8) = 31613
>>>> clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 31614
>>>>
>>>> I would have thought the value should have been the same as that in the
>>>> clone from the pthread_create call.
>>>
>>> It's possible that this is done intentionally...  The parent_tidptr
>>> is the one that's wrong in the first clone.
>
> I now think this probably is a glibc bug.  The kernel uses this value
> when the CLONE_PARENT_SETTID flag is passed.


Maybe we have a futex problem in glibc on hppa?
In glibc nptl/pthread_mutex_trylock.c we check the return value of a futex syscall against EWOULDBLOCK.
Since on parisc - in contrast to all other architectures - we have EWOULDBLOCK!=EAGAIN, we maybe missed a check?

Helge

Re: futex wait failure

[John David Anglin]

> Maybe we have a futex problem in glibc on hppa?
> In glibc nptl/pthread_mutex_trylock.c we check the return value of a futex syscall against EWOULDBLOCK.
> Since on parisc - in contrast to all other architectures - we have EWOULDBLOCK!=EAGAIN, we maybe missed a check?

That's a very interesting observation!  The manpage doesn't say
EWOULDBLOCK is a valid error return for FUTEX(2).  I wonder is there
are more slips like this.  It looks like the same bug is present in
nptl/sysdeps/unix/sysv/linux/sem_wait.c and
nptl/sysdeps/unix/sysv/linux/sem_timedwait.c.

This might explain my previous mail.

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

Re: futex wait failure

[Carlos O'Donell]

On Fri, Jan 8, 2010 at 4:18 PM, Helge Deller <deller@gmx.de> wrote:
>> I now think this probably is a glibc bug. =A0The kernel uses this va=
lue
>> when the CLONE_PARENT_SETTID flag is passed.
>
>
> Maybe we have a futex problem in glibc on hppa?
> In glibc nptl/pthread_mutex_trylock.c we check the return value of a =
futex
> syscall against EWOULDBLOCK.
> Since on parisc - in contrast to all other architectures - we have
> EWOULDBLOCK!=3DEAGAIN, we maybe missed a check?

That's a bug. There are several kernel paths that could return EAGAIN
*or* EWOULDBLOCK via the FUTEX_TRYLOCK_PI futex operation.

However, I think Dave is on to something with the

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Carlos O'Donell]

On Fri, Jan 8, 2010 at 4:44 PM, Carlos O'Donell <carlos@systemhalted.or=
g> wrote:
> On Fri, Jan 8, 2010 at 4:18 PM, Helge Deller <deller@gmx.de> wrote:
>>> I now think this probably is a glibc bug. =A0The kernel uses this v=
alue
>>> when the CLONE_PARENT_SETTID flag is passed.
>>
>>
>> Maybe we have a futex problem in glibc on hppa?
>> In glibc nptl/pthread_mutex_trylock.c we check the return value of a=
 futex
>> syscall against EWOULDBLOCK.
>> Since on parisc - in contrast to all other architectures - we have
>> EWOULDBLOCK!=3DEAGAIN, we maybe missed a check?
>
> That's a bug. There are several kernel paths that could return EAGAIN
> *or* EWOULDBLOCK via the FUTEX_TRYLOCK_PI futex operation.
>
> However, I think Dave is on to something with the

=2E..kernel issue.

We might have *several* outstanding bugs :-)

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Kyle McMartin]

On Fri, Jan 08, 2010 at 04:44:51PM -0500, Carlos O'Donell wrote:
> >
> > However, I think Dave is on to something with the
> 
> ...kernel issue.
> 
> We might have *several* outstanding bugs :-)
> 

Hrm. We discussed this on IRC a while ago, I can't remember what we
decided was the best approach... there's probably many many dragons
here.

I wonder what would break if we set any EAGAIN returns to EWOULDBLOCK in
the exit path.

Re: futex wait failure

[John David Anglin]

> On Fri, Jan 08, 2010 at 04:44:51PM -0500, Carlos O'Donell wrote:
> > >
> > > However, I think Dave is on to something with the
> > 
> > ...kernel issue.
> > 
> > We might have *several* outstanding bugs :-)
> > 
> 
> Hrm. We discussed this on IRC a while ago, I can't remember what we
> decided was the best approach... there's probably many many dragons
> here.
> 
> I wonder what would break if we set any EAGAIN returns to EWOULDBLOCK in
> the exit path.

That seems reversed.  x86_64 translates the system's EWOULDBLOCK error
into EAGAIN in sysdeps/unix/x86_64/sysdep.S.  However, don't know if this
impacts the futex and sem_wait checks.

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

Re: futex wait failure

[John David Anglin]

> On Fri, Jan 8, 2010 at 4:44 PM, Carlos O'Donell <carlos@systemhalted.org> w=
> rote:
> > On Fri, Jan 8, 2010 at 4:18 PM, Helge Deller <deller@gmx.de> wrote:
> >>> I now think this probably is a glibc bug. =A0The kernel uses this value
> >>> when the CLONE_PARENT_SETTID flag is passed.
> >>
> >>
> >> Maybe we have a futex problem in glibc on hppa?
> >> In glibc nptl/pthread_mutex_trylock.c we check the return value of a fut=
> ex
> >> syscall against EWOULDBLOCK.
> >> Since on parisc - in contrast to all other architectures - we have
> >> EWOULDBLOCK!=3DEAGAIN, we maybe missed a check?
> >
> > That's a bug. There are several kernel paths that could return EAGAIN
> > *or* EWOULDBLOCK via the FUTEX_TRYLOCK_PI futex operation.

Hacking glibc to check for both does not fix the testcase ;(

> > However, I think Dave is on to something with the
> 
> ...kernel issue.
> 
> We might have *several* outstanding bugs :-)

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

Re: futex wait failure

[Kyle McMartin]

On Fri, Jan 08, 2010 at 05:28:58PM -0500, John David Anglin wrote:
> > On Fri, Jan 08, 2010 at 04:44:51PM -0500, Carlos O'Donell wrote:
> > > >
> > > > However, I think Dave is on to something with the
> > > 
> > > ...kernel issue.
> > > 
> > > We might have *several* outstanding bugs :-)
> > > 
> > 
> > Hrm. We discussed this on IRC a while ago, I can't remember what we
> > decided was the best approach... there's probably many many dragons
> > here.
> > 
> > I wonder what would break if we set any EAGAIN returns to EWOULDBLOCK in
> > the exit path.
> 
> That seems reversed.  x86_64 translates the system's EWOULDBLOCK error
> into EAGAIN in sysdeps/unix/x86_64/sysdep.S.  However, don't know if this
> impacts the futex and sem_wait checks.

Yeah, you're right.

regards, Kyle

Re: futex wait failure

[Helge Deller]

On 01/08/2010 10:44 PM, Carlos O'Donell wrote:
> On Fri, Jan 8, 2010 at 4:18 PM, Helge Deller<deller@gmx.de>  wrote:
>>> I now think this probably is a glibc bug.  The kernel uses this value
>>> when the CLONE_PARENT_SETTID flag is passed.
>>
>>
>> Maybe we have a futex problem in glibc on hppa?
>> In glibc nptl/pthread_mutex_trylock.c we check the return value of a futex
>> syscall against EWOULDBLOCK.
>> Since on parisc - in contrast to all other architectures - we have
>> EWOULDBLOCK!=EAGAIN, we maybe missed a check?
>
> That's a bug. [...]

Carlos,  Dave,

I'm wondering if we have another bug in glibc...?

When running strace, I noticed that a thread which returns with "return 0",
exits the process on hppa with exit(0):
[pid  1875] write(1, "Thread OK.\n", 11) = 11
[pid  1875] exit(0)

On my x86_64 I see:
[pid  8154] write(1, "Thread OK.\n", 11) = 11
[pid  8154] _exit(0)                    =

In ports/sysdeps/unix/sysv/linux/hppa/clone.S (line 170) I do see:
         /* The call to _exit needs saved r19.  */
         bl      _exit, %rp
         copy    %ret0, %arg0

This coding seems to indicate that we call _exit(), but we aren't (as
you see above in the strace).
So I'm wondering if the "bl _exit,%rp" needs changing.
Something with HIDDEN_JUMPTARGET(_exit) or similar, so that
_exit() instead of exit() is called?

Actually I did tested this with the minifail test program, and changed
thread_run() to call _exit(0) at the end instead of "return 0":
void* thread_run(void* arg) {
	...
/*	return (void *)&status;  */
         _exit(0);
}
With strace I then suddenly got exit_group() which seems more correct:
[pid  1910] write(1, "Thread OK.\n", 11) = 11
[pid  1910] exit_group(0)               = ?

Helge

Re: futex wait failure

[John David Anglin]

Hi Helge,

If you link the test with -static, you should be able to set
breaks in your test application and determine why _exit isn't
called.

I'm in the process of moving homes, so I don't have much time
to investigate myself.

Dave

> On 01/08/2010 10:44 PM, Carlos O'Donell wrote:
> > On Fri, Jan 8, 2010 at 4:18 PM, Helge Deller<deller@gmx.de>  wrote:
> >>> I now think this probably is a glibc bug.  The kernel uses this value
> >>> when the CLONE_PARENT_SETTID flag is passed.
> >>
> >>
> >> Maybe we have a futex problem in glibc on hppa?
> >> In glibc nptl/pthread_mutex_trylock.c we check the return value of a futex
> >> syscall against EWOULDBLOCK.
> >> Since on parisc - in contrast to all other architectures - we have
> >> EWOULDBLOCK!=EAGAIN, we maybe missed a check?
> >
> > That's a bug. [...]
> 
> Carlos,  Dave,
> 
> I'm wondering if we have another bug in glibc...?
> 
> When running strace, I noticed that a thread which returns with "return 0",
> exits the process on hppa with exit(0):
> [pid  1875] write(1, "Thread OK.\n", 11) = 11
> [pid  1875] exit(0)
> 
> On my x86_64 I see:
> [pid  8154] write(1, "Thread OK.\n", 11) = 11
> [pid  8154] _exit(0)                    =
> 
> In ports/sysdeps/unix/sysv/linux/hppa/clone.S (line 170) I do see:
>          /* The call to _exit needs saved r19.  */
>          bl      _exit, %rp
>          copy    %ret0, %arg0
> 
> This coding seems to indicate that we call _exit(), but we aren't (as
> you see above in the strace).
> So I'm wondering if the "bl _exit,%rp" needs changing.
> Something with HIDDEN_JUMPTARGET(_exit) or similar, so that
> _exit() instead of exit() is called?
> 
> Actually I did tested this with the minifail test program, and changed
> thread_run() to call _exit(0) at the end instead of "return 0":
> void* thread_run(void* arg) {
> 	...
> /*	return (void *)&status;  */
>          _exit(0);
> }
> With strace I then suddenly got exit_group() which seems more correct:
> [pid  1910] write(1, "Thread OK.\n", 11) = 11
> [pid  1910] exit_group(0)               = ?
> 
> Helge
> 


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

Re: futex wait failure

[John David Anglin]

> Actually I did tested this with the minifail test program, and changed
> thread_run() to call _exit(0) at the end instead of "return 0":
> void* thread_run(void* arg) {
> 	...
> /*	return (void *)&status;  */
>          _exit(0);
> }
> With strace I then suddenly got exit_group() which seems more correct:
> [pid  1910] write(1, "Thread OK.\n", 11) = 11
> [pid  1910] exit_group(0)               = ?

The child of the fork should exit using _exit(0).  Otherwise, it messes
with the file descriptors of the parent.

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

Re: futex wait failure

[Carlos O'Donell]

On Mon, Jan 18, 2010 at 3:44 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> Actually I did tested this with the minifail test program, and chang=
ed
>> thread_run() to call _exit(0) at the end instead of "return 0":
>> void* thread_run(void* arg) {
>> =A0 =A0 =A0 ...
>> /* =A0 =A0return (void *)&status; =A0*/
>> =A0 =A0 =A0 =A0 =A0_exit(0);
>> }
>> With strace I then suddenly got exit_group() which seems more correc=
t:
>> [pid =A01910] write(1, "Thread OK.\n", 11) =3D 11
>> [pid =A01910] exit_group(0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D ?
>
> The child of the fork should exit using _exit(0). =A0Otherwise, it me=
sses
> with the file descriptors of the parent.

Thanks for verifying this. I'm looking into this.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Carlos O'Donell]

On Sat, Jan 16, 2010 at 6:17 PM, Helge Deller <deller@gmx.de> wrote:
> This coding seems to indicate that we call _exit(), but we aren't (as
> you see above in the strace).
> So I'm wondering if the "bl _exit,%rp" needs changing.
> Something with HIDDEN_JUMPTARGET(_exit) or similar, so that
> _exit() instead of exit() is called?
>
> Actually I did tested this with the minifail test program, and change=
d
> thread_run() to call _exit(0) at the end instead of "return 0":
> void* thread_run(void* arg) {
> =A0 =A0 =A0 =A0...
> /* =A0 =A0 =A0return (void *)&status; =A0*/
> =A0 =A0 =A0 =A0_exit(0);
> }
> With strace I then suddenly got exit_group() which seems more correct=
:
> [pid =A01910] write(1, "Thread OK.\n", 11) =3D 11
> [pid =A01910] exit_group(0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D ?

I agree with this analysis. I'm testing a change which uses
HIDDEN_JUMPTARGET(). I will tell you how it goes.

Calling exit_group is important for threads.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Helge Deller]

On 01/29/2010 06:53 PM, Carlos O'Donell wrote:
> On Sat, Jan 16, 2010 at 6:17 PM, Helge Deller<deller@gmx.de>  wrote:
>> This coding seems to indicate that we call _exit(), but we aren't (as
>> you see above in the strace).
>> So I'm wondering if the "bl _exit,%rp" needs changing.
>> Something with HIDDEN_JUMPTARGET(_exit) or similar, so that
>> _exit() instead of exit() is called?
>>
>> Actually I did tested this with the minifail test program, and changed
>> thread_run() to call _exit(0) at the end instead of "return 0":
>> void* thread_run(void* arg) {
>>         ...
>> /*      return (void *)&status;  */
>>         _exit(0);
>> }
>> With strace I then suddenly got exit_group() which seems more correct:
>> [pid  1910] write(1, "Thread OK.\n", 11) = 11
>> [pid  1910] exit_group(0)               = ?
>
> I agree with this analysis. I'm testing a change which uses
> HIDDEN_JUMPTARGET(). I will tell you how it goes.

I think I tested it once, and it doesn't help.
Threads are started by calling start_thread(), and I think we need changes there, e.g. (untested):

diff -up ./nptl/pthread_create.c.org ./nptl/pthread_create.c
--- ./nptl/pthread_create.c.org 2010-01-17 20:54:19.000000000 +0100
+++ ./nptl/pthread_create.c     2010-01-17 20:56:24.000000000 +0100
@@ -316,7 +316,7 @@ start_thread (void *arg)
       is no thread left.  */
    if (__builtin_expect (atomic_decrement_and_test (&__nptl_nthreads), 0))
      /* This was the last thread.  */
-    exit (0);
+    _exit (0);
                                                                                                                                            
    /* Report the death of the thread if this is wanted.  */
    if (__builtin_expect (pd->report_events, 0))
  

> Calling exit_group is important for threads.

Yep.

Helge

Re: futex wait failure

[Carlos O'Donell]

On Thu, Jan 28, 2010 at 11:56 AM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>> >> Actually I did tested this with the minifail test program, and ch=
anged
>> >> thread_run() to call _exit(0) at the end instead of "return 0":
>> >> void* thread_run(void* arg) {
>> >> =A0 =A0 =A0 =A0 ...
>> >> /* =A0 =A0 =A0return (void *)&status; =A0*/
>> >> =A0 =A0 =A0 =A0 _exit(0);
>> >> }
>> >> With strace I then suddenly got exit_group() which seems more cor=
rect:
>> >> [pid =A01910] write(1, "Thread OK.\n", 11) =3D 11
>> >> [pid =A01910] exit_group(0) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =3D ?
>
> Did this fix minifail?

Do you have a copy of minifail I can run as a contained test case?

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On Mon, 01 Feb 2010, Carlos O'Donell wrote:

> Do you have a copy of minifail I can run as a contained test case?

I've attached two versions -- the original and a simpler revised version.

The revised version shows that this is a clone/fork problem.  If the
parent waits for the child thread to set run before forking, the test
doesn't fail.  If the static definition of run is changed to 1, the
test fails.  I had added some loops at one time to show that this isn't
an exit issue. 

This is not to say that Helge isn't right about threads incorrectly using
exit.

The failure is always the stack of the child thread is overwritten with
zeros.

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

[-- Attachment #2: minifail.cpp --]
[-- Type: text/plain, Size: 1169 bytes --]

#include <QtCore/QCoreApplication>
#include <QtCore/QThread>
#include <pthread.h>
#include <stdio.h>
#include <stdlib.h>

class MyThread : public QThread
{
	void run();
};

void MyThread::run() {
	printf("Thread OK.\n");
}

int qt_test(int argc, char** argv) {
	QCoreApplication app(argc, argv);

	MyThread thread;
	thread.start();

	int p[2];
	char buf;
	pipe(p);

	switch (fork()) {
		case -1:
			perror("fork() failed");
		case 0:
			printf("Child OK.\n");
			write(p[1], "\0", 1);
			exit(0);
		default:
			break;
		
	}
	close(p[1]);
	read(p[0], &buf, 1);
	thread.wait();
	return 0;
}

void* thread_run(void* arg) {
	printf("Thread OK.\n");
}

int pure_test() {
	pthread_t thread;
	pthread_create(&thread, NULL, thread_run, NULL);

	int p[2];
	char buf;
	pipe(p);

	switch (fork()) {
		case -1:
			perror("fork() failed");
		case 0:
			close(p[0]);
			printf("Child OK.\n");
			write(p[1], "\0", 1);
			exit(0);
		default:
			break;
		
	}
	
	close(p[1]);
	read(p[0], &buf, 1);
	pthread_join(thread, NULL);
	return 0;
}

int main(int argc, char** argv) {
	if (argc == 2) {
		if (!strcmp("qt", argv[1])) {
			return qt_test(argc, argv);
		}
	}
	return pure_test();
}

[-- Attachment #3: minifail6.cpp --]
[-- Type: text/plain, Size: 1246 bytes --]

#include <pthread.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

/*
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203

  clone(child_stack=0x4088d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x4108c4e8, tls=0x4108c900, child_tidptr=0x4108c4e8) = 14819
[pid 14819] set_robust_list(0x4108c4f0, 0xc) = 0
[pid 14818] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 14820

 g++  minifail.cpp -o minifail -O0 -pthread -g

 i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail; done;

 */

static volatile int run;

void* thread_run(void* arg) {
	static long status;
	int i;
        
	run = 1;
	pthread_yield();
	for (i = 10000000; i; i--)
	   continue;
	write(1,"Thread OK.\n",11);
	return (void *)&status;
}

int pure_test() {
	pthread_t thread;
	pthread_create(&thread, NULL, thread_run, NULL);

	while (!run)
	  continue;
	switch (fork()) {
		case -1:
			perror("fork() failed");
		case 0:
			write(1,"Child OK.\n",10);
			_exit(0);
		default:
			break;
		
	}
	pthread_join(thread, NULL);
	return 0;
}

int main(int argc, char** argv) {
	return pure_test();
}

Re: futex wait failure

[Helge Deller]

On 02/01/2010 01:26 AM, John David Anglin wrote:
>>>> Actually I did tested this with the minifail test program, and changed
>>>> thread_run() to call _exit(0) at the end instead of "return 0":
>>>> void* thread_run(void* arg) {
>>>>          ...
>>>> /*      return (void *)&status;  */
>>>>          _exit(0);
>>>> }
>>>> With strace I then suddenly got exit_group() which seems more correct:
>>>> [pid  1910] write(1, "Thread OK.\n", 11) = 11
>>>> [pid  1910] exit_group(0)               = ?
>
> Did this fix minifail?

No, sadly it didn't fixed it.

Helge

Re: futex wait failure

[John David Anglin]

> On 02/01/2010 01:26 AM, John David Anglin wrote:
> >>>> Actually I did tested this with the minifail test program, and changed
> >>>> thread_run() to call _exit(0) at the end instead of "return 0":
> >>>> void* thread_run(void* arg) {
> >>>>          ...
> >>>> /*      return (void *)&status;  */
> >>>>          _exit(0);
> >>>> }
> >>>> With strace I then suddenly got exit_group() which seems more correct:
> >>>> [pid  1910] write(1, "Thread OK.\n", 11) = 11
> >>>> [pid  1910] exit_group(0)               = ?
> >
> > Did this fix minifail?
> 
> No, sadly it didn't fixed it.

I tend to think clone/fork syscalls need to be guarded to ensure a stable
configuration while the syscall executes.  It may be the problem arises
because we use clone for fork.  Do any other targets do this?

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

Re: futex wait failure

[Carlos O'Donell]

On Mon, Feb 1, 2010 at 2:11 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
>>
>> No, sadly it didn't fixed it.
>
> I tend to think clone/fork syscalls need to be guarded to ensure a st=
able
> configuration while the syscall executes. =A0It may be the problem ar=
ises
> because we use clone for fork. =A0Do any other targets do this?

All targets call nptl/sysdeps/unix/sysv/linux/fork.c, which calls
ARCH_FORK, which is implemented using clone() for *all* targets.

In fact, owing to the POSIX atfork requirements, it's very difficult
to implement fork properly without using Linux clone.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 1049 bytes --]

I wonder if we have some problems with the LWS code path in the kernel
regarding atomic locking with futexes?

In arch/parisc/kernel/syscall.S we use a lock table called lws_lock_start[]
to guard the LWS code against other competing userspace processes.
I wonder if this really enough, esp. since we do implement futex syscalls
(e.g. clone/exit calls uses futex functions to change userspace values
because of CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID).

Do we maybe need to protect the LWS code path with the same locking table as the
generic kernel? Atomicity of futexes writing to userspace are not in sync
with the locking of the LWS/lws_lock_start[] code.

I tried to come up with a patch for that which I attached here, but sadly
it hangs as soon as the init process is started on a 64bit/SMP kernel.
So either my thinking here is stupid, or I do have a stupid coding bug.

Furthermore, the coding for futex_atomic_op_inuser() in
arch/parisc/include/asm/futex.h seems to miss real functionality.
I didn't looked closer into this though.

Helge

[-- Attachment #2: z1 --]
[-- Type: text/plain, Size: 2970 bytes --]

diff --git a/arch/parisc/kernel/asm-offsets.c b/arch/parisc/kernel/asm-offsets.c
index ec787b4..50353bd 100644
--- a/arch/parisc/kernel/asm-offsets.c
+++ b/arch/parisc/kernel/asm-offsets.c
@@ -290,5 +290,11 @@ int main(void)
 	BLANK();
 	DEFINE(ASM_PDC_RESULT_SIZE, NUM_PDC_RESULT * sizeof(unsigned long));
 	BLANK();
+
+#ifdef CONFIG_SMP
+	DEFINE(ASM_ATOMIC_HASH_SIZE_SHIFT, __builtin_ffs(ATOMIC_HASH_SIZE)-1);
+	DEFINE(ASM_ATOMIC_HASH_ENTRY_SHIFT, __builtin_ffs(sizeof(__atomic_hash[0]))-1);
+#endif
+
 	return 0;
 }
diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
index cb71f3d..878f42c 100644
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -128,6 +131,14 @@ void __init setup_arch(char **cmdline_p)
 	printk(KERN_INFO "The 32-bit Kernel has started...\n");
 #endif
 
+	/* Consistency check on the size and alignments of our spinlocks */
+#ifdef CONFIG_SMP
+	BUILD_BUG_ON(sizeof(arch_spinlock_t) != __PA_LDCW_ALIGNMENT);
+	BUG_ON((unsigned long)&__atomic_hash[0] & (__PA_LDCW_ALIGNMENT-1));
+	BUG_ON((unsigned long)&__atomic_hash[1] & (__PA_LDCW_ALIGNMENT-1));
+#endif
+	BUILD_BUG_ON((1<<L1_CACHE_SHIFT) != L1_CACHE_BYTES);
+
 	pdc_console_init();
 
 #ifdef CONFIG_64BIT
diff --git a/arch/parisc/kernel/syscall.S b/arch/parisc/kernel/syscall.S
index f5f9602..7925a68 100644
--- a/arch/parisc/kernel/syscall.S
+++ b/arch/parisc/kernel/syscall.S
@@ -11,6 +11,7 @@
 #include <asm/unistd.h>
 #include <asm/errno.h>
 #include <asm/page.h>
+#include <asm/cache.h>
 #include <asm/psw.h>
 #include <asm/thread_info.h>
 #include <asm/assembly.h>
@@ -530,18 +527,17 @@ lws_compare_and_swap32:
 
 lws_compare_and_swap:
 #ifdef CONFIG_SMP
-	/* Load start of lock table */
-	ldil	L%lws_lock_start, %r20
-	ldo	R%lws_lock_start(%r20), %r28
+	/* Calculate lock table entry via ATOMIC_HASH(%r26) */
+	ldil	L%__atomic_hash, %r20
+	ldo	R%__atomic_hash(%r20), %r28
 
-	/* Extract four bits from r26 and hash lock (Bits 4-7) */
-	extru  %r26, 27, 4, %r20
+#ifdef CONFIG_64BIT
+	extrd,u %r26, 63-L1_CACHE_SHIFT, ASM_ATOMIC_HASH_SIZE_SHIFT, %r20
+#else
+	extru	%r26, 31-L1_CACHE_SHIFT, ASM_ATOMIC_HASH_SIZE_SHIFT, %r20
+#endif
+	shladd,l %r20, ASM_ATOMIC_HASH_ENTRY_SHIFT, %r28, %r20
 
-	/* Find lock to use, the hash is either one of 0 to
-	   15, multiplied by 16 (keep it 16-byte aligned)
-	   and add to the lock table offset. */
-	shlw	%r20, 4, %r20
-	add	%r20, %r28, %r20
 
 # if ENABLE_LWS_DEBUG
 	/*	
@@ -672,31 +668,6 @@ ENTRY(sys_call_table64)
 END(sys_call_table64)
 #endif
 
-#ifdef CONFIG_SMP
-	/*
-		All light-weight-syscall atomic operations 
-		will use this set of locks 
-
-		NOTE: The lws_lock_start symbol must be
-		at least 16-byte aligned for safe use
-		with ldcw.
-	*/
-	.section .data
-	.align	PAGE_SIZE
-ENTRY(lws_lock_start)
-	/* lws locks */
-	.rept 16
-	/* Keep locks aligned at 16-bytes */
-	.word 1
-	.word 0 
-	.word 0
-	.word 0
-	.endr
-END(lws_lock_start)
-	.previous
-#endif
-/* CONFIG_SMP for lws_lock_start */

Re: futex wait failure

[John David Anglin]

On Tue, 02 Feb 2010, Helge Deller wrote:

> I wonder if we have some problems with the LWS code path in the kernel
> regarding atomic locking with futexes?
>
> In arch/parisc/kernel/syscall.S we use a lock table called lws_lock_start[]
> to guard the LWS code against other competing userspace processes.
> I wonder if this really enough, esp. since we do implement futex syscalls
> (e.g. clone/exit calls uses futex functions to change userspace values
> because of CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID).
>
> Do we maybe need to protect the LWS code path with the same locking table 
> as the
> generic kernel? Atomicity of futexes writing to userspace are not in sync
> with the locking of the LWS/lws_lock_start[] code.
>
> I tried to come up with a patch for that which I attached here, but sadly
> it hangs as soon as the init process is started on a 64bit/SMP kernel.
> So either my thinking here is stupid, or I do have a stupid coding bug.
>
> Furthermore, the coding for futex_atomic_op_inuser() in
> arch/parisc/include/asm/futex.h seems to miss real functionality.
> I didn't looked closer into this though.

While locking may be a problem, it is not the main reason the minifail
program fails.  The program fails on my c3750 with a 32-bit UP kernel.
There is no locking in this kernel.  The LWS code relies on the scheduler
for atomicity.

I tried disabling interrupts around the crucial three instructions but
it didn't help.

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

Re: futex wait failure

[Helge Deller]

[-- Attachment #1: Type: text/plain, Size: 2164 bytes --]

On 02/03/2010 04:44 AM, John David Anglin wrote:
> On Tue, 02 Feb 2010, Helge Deller wrote:
>
>> I wonder if we have some problems with the LWS code path in the kernel
>> regarding atomic locking with futexes?
>>
>> In arch/parisc/kernel/syscall.S we use a lock table called lws_lock_start[]
>> to guard the LWS code against other competing userspace processes.
>> I wonder if this really enough, esp. since we do implement futex syscalls
>> (e.g. clone/exit calls uses futex functions to change userspace values
>> because of CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID).
>>
>> Do we maybe need to protect the LWS code path with the same locking table
>> as the
>> generic kernel? Atomicity of futexes writing to userspace are not in sync
>> with the locking of the LWS/lws_lock_start[] code.
>>
>> I tried to come up with a patch for that which I attached here, but sadly
>> it hangs as soon as the init process is started on a 64bit/SMP kernel.
>> So either my thinking here is stupid, or I do have a stupid coding bug.
>>
>> Furthermore, the coding for futex_atomic_op_inuser() in
>> arch/parisc/include/asm/futex.h seems to miss real functionality.
>> I didn't looked closer into this though.
>
> While locking may be a problem, it is not the main reason the minifail
> program fails.  The program fails on my c3750 with a 32-bit UP kernel.

Hmm, I can't reproduce it at the moment with a 32bit UP kernel on my
c3000. The minifail3 test program I currently use (to avoid glibc issues)
is attached.

> There is no locking in this kernel.  The LWS code relies on the scheduler
> for atomicity.

yep. This should then work an a UP kernel.

> I tried disabling interrupts around the crucial three instructions but
> it didn't help.

Ugh.

Anyway, my current patch which compiles and runs fine is attached here as
well. Maybe you want to try it on your SMP builds? It includes the syscall.S
changes you sent last time too.
In this version of the patch I added on own LWS locking hash table for user-space accesses,
which is used in the LWS code and when some (probably not all) put_user()/
get_user() calls are made in the futex code.

Feedback still welcome.

Helge

[-- Attachment #2: minifail3.c --]
[-- Type: text/plain, Size: 652 bytes --]

#include <pthread.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

/*
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203

 gcc  minifail3.c -o minifail3 -O0 -pthread -g

 Run as: i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail3; done;

 */

static volatile int run;

void* thread_run(void* arg) {
	write(1,"Thread OK.\n",11);
	_exit(0);
}

int main(int argc, char** argv) {
	pthread_t thread;
	pthread_create(&thread, NULL, thread_run, NULL);

	switch (fork()) {
		case -1:
			perror("fork() failed");
		case 0:
			write(1,"Child OK.\n",10);
			exit(0);
		default:
			break;
		
	}
	pthread_join(thread, NULL);
	return 0;
}

[-- Attachment #3: parisc_lock_v2.patch --]
[-- Type: text/x-patch, Size: 9485 bytes --]

diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
index 716634d..18d57c8 100644
--- a/arch/parisc/include/asm/atomic.h
+++ b/arch/parisc/include/asm/atomic.h
@@ -24,29 +24,46 @@
  * Hash function to index into a different SPINLOCK.
  * Since "a" is usually an address, use one spinlock per cacheline.
  */
-#  define ATOMIC_HASH_SIZE 4
-#  define ATOMIC_HASH(a) (&(__atomic_hash[ (((unsigned long) (a))/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
+#  define ATOMIC_HASH_SIZE (4096/L1_CACHE_BYTES)  /* 4 */
+#  define ATOMIC_HASH(a)      (&(__atomic_hash[ (((unsigned long) (a))/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
+#  define ATOMIC_USER_HASH(a) (&(__atomic_user_hash[ (((unsigned long) (a))/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
 
 extern arch_spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] __lock_aligned;
+extern arch_spinlock_t __atomic_user_hash[ATOMIC_HASH_SIZE] __lock_aligned;
 
 /* Can't use raw_spin_lock_irq because of #include problems, so
  * this is the substitute */
-#define _atomic_spin_lock_irqsave(l,f) do {	\
-	arch_spinlock_t *s = ATOMIC_HASH(l);		\
+#define _atomic_spin_lock_irqsave_template(l,f,hash_func) do {	\
+	arch_spinlock_t *s = hash_func;		\
 	local_irq_save(f);			\
 	arch_spin_lock(s);			\
 } while(0)
 
-#define _atomic_spin_unlock_irqrestore(l,f) do {	\
-	arch_spinlock_t *s = ATOMIC_HASH(l);			\
+#define _atomic_spin_unlock_irqrestore_template(l,f,hash_func) do {	\
+	arch_spinlock_t *s = hash_func;			\
 	arch_spin_unlock(s);				\
 	local_irq_restore(f);				\
 } while(0)
 
+/* kernel memory locks */
+#define _atomic_spin_lock_irqsave(l,f)	\
+	_atomic_spin_lock_irqsave_template(l,f,ATOMIC_HASH(l))
+
+#define _atomic_spin_unlock_irqrestore(l,f)	\
+	_atomic_spin_unlock_irqrestore_template(l,f,ATOMIC_HASH(l))
+
+/* userspace memory locks */
+#define _atomic_spin_lock_irqsave_user(l,f)	\
+	_atomic_spin_lock_irqsave_template(l,f,ATOMIC_USER_HASH(l))
+
+#define _atomic_spin_unlock_irqrestore_user(l,f)	\
+	_atomic_spin_unlock_irqrestore_template(l,f,ATOMIC_USER_HASH(l))
 
 #else
 #  define _atomic_spin_lock_irqsave(l,f) do { local_irq_save(f); } while (0)
 #  define _atomic_spin_unlock_irqrestore(l,f) do { local_irq_restore(f); } while (0)
+#  define _atomic_spin_lock_irqsave_user(l,f) _atomic_spin_lock_irqsave(l,f)
+#  define _atomic_spin_unlock_irqrestore_user(l,f) _atomic_spin_lock_irqsave_user(l,f)
 #endif
 
 /* This should get optimized out since it's never called.
diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h
index 0c705c3..7bc963e 100644
--- a/arch/parisc/include/asm/futex.h
+++ b/arch/parisc/include/asm/futex.h
@@ -55,6 +55,7 @@ futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
 {
 	int err = 0;
 	int uval;
+	unsigned long flags;
 
 	/* futex.c wants to do a cmpxchg_inatomic on kernel NULL, which is
 	 * our gateway page, and causes no end of trouble...
@@ -65,10 +66,15 @@ futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
 	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
 		return -EFAULT;
 
+	_atomic_spin_lock_irqsave_user(uaddr, flags);
+
 	err = get_user(uval, uaddr);
-	if (err) return -EFAULT;
-	if (uval == oldval)
-		err = put_user(newval, uaddr);
+	if (!err)
+		if (uval == oldval)
+			err = put_user(newval, uaddr);
+
+	_atomic_spin_unlock_irqrestore_user(uaddr, flags);
+
 	if (err) return -EFAULT;
 	return uval;
 }
diff --git a/arch/parisc/include/asm/system.h b/arch/parisc/include/asm/system.h
index d91357b..4653c77 100644
--- a/arch/parisc/include/asm/system.h
+++ b/arch/parisc/include/asm/system.h
@@ -160,7 +160,7 @@ static inline void set_eiem(unsigned long val)
    ldcd). */
 
 #define __PA_LDCW_ALIGNMENT	4
-#define __ldcw_align(a) ((volatile unsigned int *)a)
+#define __ldcw_align(a) (&(a)->slock)
 #define __LDCW	"ldcw,co"
 
 #endif /*!CONFIG_PA20*/
diff --git a/arch/parisc/kernel/asm-offsets.c b/arch/parisc/kernel/asm-offsets.c
index ec787b4..50353bd 100644
--- a/arch/parisc/kernel/asm-offsets.c
+++ b/arch/parisc/kernel/asm-offsets.c
@@ -290,5 +290,11 @@ int main(void)
 	BLANK();
 	DEFINE(ASM_PDC_RESULT_SIZE, NUM_PDC_RESULT * sizeof(unsigned long));
 	BLANK();
+
+#ifdef CONFIG_SMP
+	DEFINE(ASM_ATOMIC_HASH_SIZE_SHIFT, __builtin_ffs(ATOMIC_HASH_SIZE)-1);
+	DEFINE(ASM_ATOMIC_HASH_ENTRY_SHIFT, __builtin_ffs(sizeof(__atomic_hash[0]))-1);
+#endif
+
 	return 0;
 }
diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
index cb71f3d..878f42c 100644
--- a/arch/parisc/kernel/setup.c
+++ b/arch/parisc/kernel/setup.c
@@ -128,6 +131,14 @@ void __init setup_arch(char **cmdline_p)
 	printk(KERN_INFO "The 32-bit Kernel has started...\n");
 #endif
 
+	/* Consistency check on the size and alignments of our spinlocks */
+#ifdef CONFIG_SMP
+	BUILD_BUG_ON(sizeof(arch_spinlock_t) != __PA_LDCW_ALIGNMENT);
+	BUG_ON((unsigned long)&__atomic_hash[0] & (__PA_LDCW_ALIGNMENT-1));
+	BUG_ON((unsigned long)&__atomic_hash[1] & (__PA_LDCW_ALIGNMENT-1));
+#endif
+	BUILD_BUG_ON((1<<L1_CACHE_SHIFT) != L1_CACHE_BYTES);
+
 	pdc_console_init();
 
 #ifdef CONFIG_64BIT
diff --git a/arch/parisc/kernel/syscall.S b/arch/parisc/kernel/syscall.S
index f5f9602..1f12418 100644
--- a/arch/parisc/kernel/syscall.S
+++ b/arch/parisc/kernel/syscall.S
@@ -11,6 +11,7 @@
 #include <asm/unistd.h>
 #include <asm/errno.h>
 #include <asm/page.h>
+#include <asm/cache.h>
 #include <asm/psw.h>
 #include <asm/thread_info.h>
 #include <asm/assembly.h>
@@ -47,18 +48,17 @@ ENTRY(linux_gateway_page)
 	KILL_INSN
 	.endr
 
-	/* ADDRESS 0xb0 to 0xb4, lws uses 1 insns for entry */
+	/* ADDRESS 0xb0 to 0xb8, lws uses two insns for entry */
 	/* Light-weight-syscall entry must always be located at 0xb0 */
 	/* WARNING: Keep this number updated with table size changes */
 #define __NR_lws_entries (2)
 
 lws_entry:
-	/* Unconditional branch to lws_start, located on the 
-	   same gateway page */
-	b,n	lws_start
+	gate	lws_start, %r0		/* increase privilege */
+	depi	3, 31, 2, %r31		/* Ensure we return into user mode. */
 
-	/* Fill from 0xb4 to 0xe0 */
-	.rept 11
+	/* Fill from 0xb8 to 0xe0 */
+	.rept 10
 	KILL_INSN
 	.endr
 
@@ -423,9 +423,6 @@ tracesys_sigexit:
 
 	*********************************************************/
 lws_start:
-	/* Gate and ensure we return to userspace */
-	gate	.+8, %r0
-	depi	3, 31, 2, %r31	/* Ensure we return to userspace */
 
 #ifdef CONFIG_64BIT
 	/* FIXME: If we are a 64-bit kernel just
@@ -473,7 +470,7 @@ lws_exit:
 	/* now reset the lowest bit of sp if it was set */
 	xor	%r30,%r1,%r30
 #endif
-	be,n	0(%sr3, %r31)
+	be,n	0(%sr7, %r31)
 
 
 	
@@ -530,18 +527,17 @@ lws_compare_and_swap32:
 
 lws_compare_and_swap:
 #ifdef CONFIG_SMP
-	/* Load start of lock table */
-	ldil	L%lws_lock_start, %r20
-	ldo	R%lws_lock_start(%r20), %r28
+	/* Calculate lock table entry via ATOMIC_HASH(%r26) */
+	ldil	L%__atomic_user_hash, %r20
+	ldo	R%__atomic_user_hash(%r20), %r28
 
-	/* Extract four bits from r26 and hash lock (Bits 4-7) */
-	extru  %r26, 27, 4, %r20
+#ifdef CONFIG_64BIT
+	extrd,u %r26, 63-L1_CACHE_SHIFT, ASM_ATOMIC_HASH_SIZE_SHIFT, %r20
+#else
+	extru	%r26, 31-L1_CACHE_SHIFT, ASM_ATOMIC_HASH_SIZE_SHIFT, %r20
+#endif
+	shladd,l %r20, ASM_ATOMIC_HASH_ENTRY_SHIFT, %r28, %r20
 
-	/* Find lock to use, the hash is either one of 0 to
-	   15, multiplied by 16 (keep it 16-byte aligned)
-	   and add to the lock table offset. */
-	shlw	%r20, 4, %r20
-	add	%r20, %r28, %r20
 
 # if ENABLE_LWS_DEBUG
 	/*	
@@ -672,31 +668,6 @@ ENTRY(sys_call_table64)
 END(sys_call_table64)
 #endif
 
-#ifdef CONFIG_SMP
-	/*
-		All light-weight-syscall atomic operations 
-		will use this set of locks 
-
-		NOTE: The lws_lock_start symbol must be
-		at least 16-byte aligned for safe use
-		with ldcw.
-	*/
-	.section .data
-	.align	PAGE_SIZE
-ENTRY(lws_lock_start)
-	/* lws locks */
-	.rept 16
-	/* Keep locks aligned at 16-bytes */
-	.word 1
-	.word 0 
-	.word 0
-	.word 0
-	.endr
-END(lws_lock_start)
-	.previous
-#endif
-/* CONFIG_SMP for lws_lock_start */
-
 .end
 
 
diff --git a/arch/parisc/lib/bitops.c b/arch/parisc/lib/bitops.c
index 353963d..bae6a86 100644
--- a/arch/parisc/lib/bitops.c
+++ b/arch/parisc/lib/bitops.c
@@ -15,6 +15,9 @@
 arch_spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] __lock_aligned = {
 	[0 ... (ATOMIC_HASH_SIZE-1)]  = __ARCH_SPIN_LOCK_UNLOCKED
 };
+arch_spinlock_t __atomic_user_hash[ATOMIC_HASH_SIZE] __lock_aligned = {
+	[0 ... (ATOMIC_HASH_SIZE-1)]  = __ARCH_SPIN_LOCK_UNLOCKED
+};
 #endif
 
 #ifdef CONFIG_64BIT
diff --git a/kernel/fork.c b/kernel/fork.c
index f88bd98..108b1ed 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -608,7 +608,10 @@ void mm_release(struct task_struct *tsk, struct mm_struct *mm)
 			 * We don't check the error code - if userspace has
 			 * not set up a proper pointer then tough luck.
 			 */
+			unsigned long flags;
+			_atomic_spin_lock_irqsave_user(tsk->clear_child_tid, flags);
 			put_user(0, tsk->clear_child_tid);
+			_atomic_spin_unlock_irqrestore_user(tsk->clear_child_tid, flags);
 			sys_futex(tsk->clear_child_tid, FUTEX_WAKE,
 					1, NULL, NULL, 0);
 		}
@@ -1432,8 +1435,12 @@ long do_fork(unsigned long clone_flags,
 
 		nr = task_pid_vnr(p);
 
-		if (clone_flags & CLONE_PARENT_SETTID)
+		if (clone_flags & CLONE_PARENT_SETTID) {
+			unsigned long flags;
+			_atomic_spin_lock_irqsave_user(parent_tidptr, flags);
 			put_user(nr, parent_tidptr);
+			_atomic_spin_unlock_irqrestore_user(parent_tidptr, flags);
+		}
 
 		if (clone_flags & CLONE_VFORK) {
 			p->vfork_done = &vfork;

Re: futex wait failure

[Carlos O'Donell]

On Tue, Feb 2, 2010 at 4:16 PM, Helge Deller <deller@gmx.de> wrote:
> Furthermore, the coding for futex_atomic_op_inuser() in
> arch/parisc/include/asm/futex.h seems to miss real functionality.
> I didn't looked closer into this though.

I have a fix for futex_atomic_op_inuser(), but it needs more testing.

Cheers,
Carlos.

Re: futex wait failure

[John David Anglin]

On Wed, 03 Feb 2010, Helge Deller wrote:

> On 02/03/2010 04:44 AM, John David Anglin wrote:
>> On Tue, 02 Feb 2010, Helge Deller wrote:
>>
>>> I wonder if we have some problems with the LWS code path in the kernel
>>> regarding atomic locking with futexes?
>>>
>>> In arch/parisc/kernel/syscall.S we use a lock table called 
>>> lws_lock_start[]
>>> to guard the LWS code against other competing userspace processes.
>>> I wonder if this really enough, esp. since we do implement futex syscalls
>>> (e.g. clone/exit calls uses futex functions to change userspace values
>>> because of CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID).
>>>
>>> Do we maybe need to protect the LWS code path with the same locking table
>>> as the
>>> generic kernel? Atomicity of futexes writing to userspace are not in sync
>>> with the locking of the LWS/lws_lock_start[] code.
>>>
>>> I tried to come up with a patch for that which I attached here, but sadly
>>> it hangs as soon as the init process is started on a 64bit/SMP kernel.
>>> So either my thinking here is stupid, or I do have a stupid coding bug.
>>>
>>> Furthermore, the coding for futex_atomic_op_inuser() in
>>> arch/parisc/include/asm/futex.h seems to miss real functionality.
>>> I didn't looked closer into this though.
>>
>> While locking may be a problem, it is not the main reason the minifail
>> program fails.  The program fails on my c3750 with a 32-bit UP kernel.
>
> Hmm, I can't reproduce it at the moment with a 32bit UP kernel on my
> c3000. The minifail3 test program I currently use (to avoid glibc issues)
> is attached.
>
>> There is no locking in this kernel.  The LWS code relies on the scheduler
>> for atomicity.
>
> yep. This should then work an a UP kernel.
>
>> I tried disabling interrupts around the crucial three instructions but
>> it didn't help.
>
> Ugh.
>
> Anyway, my current patch which compiles and runs fine is attached here as
> well. Maybe you want to try it on your SMP builds? It includes the 
> syscall.S
> changes you sent last time too.
> In this version of the patch I added on own LWS locking hash table for 
> user-space accesses,
> which is used in the LWS code and when some (probably not all) put_user()/
> get_user() calls are made in the futex code.
>
> Feedback still welcome.

I tried the patch below with 2.6.33 on three systems:

rp3440: 64-bit UP and SMP
A500-7X: 64-bit SMP
c3750: 32-bit UP

libc6 is 2.10.2-6.

As usual, I tested by trying to build and check GCC.

The most common problem on the rp3440 SMP build is a segmentation fault
in /bin/sh.  Twice it dropped core running configure near the start of
the build.  Restarting the build, the system managed to complete a full
GCC build, but the gcc and acats testsuites aborted.  Here's the backtrace
for the acats one:

Core was generated by `/bin/bash /home/dave/gnu/gcc/gcc/gcc/testsuite/ada/acats/run_all.sh'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000008 in ?? ()
(gdb) bt
#0  0x00000008 in ?? ()
#1  0x0004ffd0 in stop_pipeline ()
#2  0x0003daf8 in execute_command_internal ()
#3  0x0003e3a8 in execute_command_internal ()
#4  0x0003e74c in execute_command ()
#5  0x0003e364 in execute_command_internal ()
#6  0x0003e74c in execute_command ()
#7  0x0003e364 in execute_command_internal ()
#8  0x0003e74c in execute_command ()
#9  0x0003e0a0 in execute_command_internal ()
#10 0x0003e3a8 in execute_command_internal ()
#11 0x0003e74c in execute_command ()
#12 0x0003e0a0 in execute_command_internal ()
#13 0x0003e74c in execute_command ()
#14 0x00029ac0 in reader_loop ()
#15 0x00029100 in main ()

I ran the UP build for several days without any major problems.  The most
common problem is tests randomly timeout.  I'm not sure whether the tests
actually timeout or not, but everyone that I've looked at shouldn't timeout
based on execution time.

I had pretty much the same experience on the A500-7X although I haven't
seen /bin/sh dump core running configure.

The c3750 completed a full GCC build but there were again problems running
the testsuite.  For example,

Core was generated by `expect -- /usr/share/dejagnu/runtest.exp --tool gcc'.
Program terminated with signal 11, Segmentation fault.
#0  0x409fa258 in ?? () from /usr/lib/libtcl8.5.so.0
(gdb) bt
#0  0x409fa258 in ?? () from /usr/lib/libtcl8.5.so.0
#1  0x402600a0 in start_thread (arg=0x416a4480) at pthread_create.c:302
#2  0x40e25874 in clone ()
    at ../ports/sysdeps/unix/sysv/linux/hppa/nptl/../clone.S:166
#3  0x00000000 in ?? ()

This looks like the minifail clone bug.  On the otherhand, minifail doesn't
seem to be failing.

This is the assembly code:

(gdb) disass 0x409fa248 0x409fa268
Dump of assembler code from 0x409fa248 to 0x409fa268:
0x409fa248:     copy r18,ret0
0x409fa24c:     stw r0,0(ret0)
0x409fa250:     ldo 4(ret0),ret0
0x409fa254:     cmpb,<>,n r7,ret0,0x409fa250
0x409fa258:     stw r0,0(ret0)
0x409fa25c:     copy r7,ret0
0x409fa260:     stw r0,0(ret0)
0x409fa264:     ldo 4(ret0),ret0

This may be the register.  There are several dumps in the log at the same spot.

Mar  7 11:48:18 hiauly6 kernel: do_page_fault() pid=3506 command='expect' type=1
5 address=0x416a3000
Mar  7 11:48:18 hiauly6 kernel: vm_start = 0x416a3000, vm_end = 0x416a4000
Mar  7 11:48:18 hiauly6 kernel: 
Mar  7 11:48:18 hiauly6 kernel:      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
Mar  7 11:48:18 hiauly6 kernel: PSW: 00000000000011101111111100001111 Not tainte
d
Mar  7 11:48:18 hiauly6 kernel: r00-03  000eff0f 40276138 409fa4ff 00000000
Mar  7 11:48:18 hiauly6 kernel: r04-07  40a252f4 40ea5208 0001ccb8 00000000
Mar  7 11:48:18 hiauly6 kernel: r08-11  40a252f4 40ea539c 00000003 40a2990c
Mar  7 11:48:18 hiauly6 kernel: r12-15  40ea521c 40a29904 40ea5214 00000001
Mar  7 11:48:18 hiauly6 kernel: r16-19  00000008 40a232d8 40ea521c 40a252f4
Mar  7 11:48:18 hiauly6 kernel: r20-23  00000001 00000000 402636cc 00000000
Mar  7 11:48:18 hiauly6 kernel: r24-27  fffffff5 ffffffd3 0001c538 000121ac
Mar  7 11:48:18 hiauly6 kernel: r28-31  416a3000 00000000 40ea5440 40263733
Mar  7 11:48:18 hiauly6 kernel: sr00-03  00000026 00000000 00000000 00000026
Mar  7 11:48:18 hiauly6 kernel: sr04-07  00000026 00000026 00000026 00000026
Mar  7 11:48:18 hiauly6 kernel: 
Mar  7 11:48:18 hiauly6 kernel:       VZOUICununcqcqcqcqcqcrmunTDVZOUI
Mar  7 11:48:18 hiauly6 kernel: FPSR: 00001100001110000000000000000000
Mar  7 11:48:18 hiauly6 kernel: FPER1: 00000000
Mar  7 11:48:18 hiauly6 kernel: fr00-03  0c38000000000000 0000000000000000 00000
00000000000 0000000000000000
Mar  7 11:48:18 hiauly6 kernel: fr04-07  0000000000000001 0370000000000000 0000000100000000 bff0000000000000
Mar  7 11:48:18 hiauly6 kernel: fr08-11  000000024f813bc4 0000000000000000 4f813bc04f813bc8 0000800100000003
Mar  7 11:48:18 hiauly6 kernel: fr12-15  000000004facfd40 000000001019db40 4f81169cf0000174 f000017cf0000884
Mar  7 11:48:18 hiauly6 kernel: fr16-19  1044111810590240 1044111800000081 f000000000000000 0000000000000000
Mar  7 11:48:18 hiauly6 kernel: fr20-23  00000002ffffff9c fffff0004f1a4000 0000000000000088 400026c000000000
Mar  7 11:48:18 hiauly6 kernel: fr24-27  01f2603af000017c f000017400000001 105a928c00000000 4fb50230ffffffff
Mar  7 11:48:18 hiauly6 kernel: fr28-31  ffffffff00002b67 105a92881019487c 0000000100000000 4f82820000000800
Mar  7 11:48:18 hiauly6 kernel: 
Mar  7 11:48:18 hiauly6 kernel: IASQ: 00000026 00000026 IAOQ: 409fa25b 409fa253
Mar  7 11:48:18 hiauly6 kernel:  IIR: 0f801280    ISR: 00000026  IOR: 416a3000
Mar  7 11:48:18 hiauly6 kernel:  CPU:        0   CR30: 3c014000 CR31: ffffffff
Mar  7 11:48:18 hiauly6 kernel:  ORIG_R28: 00000080
Mar  7 11:48:18 hiauly6 kernel:  IAOQ[0]: 409fa25b
Mar  7 11:48:18 hiauly6 kernel:  IAOQ[1]: 409fa253
Mar  7 11:48:18 hiauly6 kernel:  RP(r2): 409fa4ff

The address appears valid.  This is a TLB miss exception (15).

> diff --git a/arch/parisc/include/asm/atomic.h b/arch/parisc/include/asm/atomic.h
> index 716634d..18d57c8 100644
> --- a/arch/parisc/include/asm/atomic.h
> +++ b/arch/parisc/include/asm/atomic.h
> @@ -24,29 +24,46 @@
>   * Hash function to index into a different SPINLOCK.
>   * Since "a" is usually an address, use one spinlock per cacheline.
>   */
> -#  define ATOMIC_HASH_SIZE 4
> -#  define ATOMIC_HASH(a) (&(__atomic_hash[ (((unsigned long) (a))/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
> +#  define ATOMIC_HASH_SIZE (4096/L1_CACHE_BYTES)  /* 4 */
> +#  define ATOMIC_HASH(a)      (&(__atomic_hash[ (((unsigned long) (a))/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
> +#  define ATOMIC_USER_HASH(a) (&(__atomic_user_hash[ (((unsigned long) (a))/L1_CACHE_BYTES) & (ATOMIC_HASH_SIZE-1) ]))
>  
>  extern arch_spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] __lock_aligned;
> +extern arch_spinlock_t __atomic_user_hash[ATOMIC_HASH_SIZE] __lock_aligned;
>  
>  /* Can't use raw_spin_lock_irq because of #include problems, so
>   * this is the substitute */
> -#define _atomic_spin_lock_irqsave(l,f) do {	\
> -	arch_spinlock_t *s = ATOMIC_HASH(l);		\
> +#define _atomic_spin_lock_irqsave_template(l,f,hash_func) do {	\
> +	arch_spinlock_t *s = hash_func;		\
>  	local_irq_save(f);			\
>  	arch_spin_lock(s);			\
>  } while(0)
>  
> -#define _atomic_spin_unlock_irqrestore(l,f) do {	\
> -	arch_spinlock_t *s = ATOMIC_HASH(l);			\
> +#define _atomic_spin_unlock_irqrestore_template(l,f,hash_func) do {	\
> +	arch_spinlock_t *s = hash_func;			\
>  	arch_spin_unlock(s);				\
>  	local_irq_restore(f);				\
>  } while(0)
>  
> +/* kernel memory locks */
> +#define _atomic_spin_lock_irqsave(l,f)	\
> +	_atomic_spin_lock_irqsave_template(l,f,ATOMIC_HASH(l))
> +
> +#define _atomic_spin_unlock_irqrestore(l,f)	\
> +	_atomic_spin_unlock_irqrestore_template(l,f,ATOMIC_HASH(l))
> +
> +/* userspace memory locks */
> +#define _atomic_spin_lock_irqsave_user(l,f)	\
> +	_atomic_spin_lock_irqsave_template(l,f,ATOMIC_USER_HASH(l))
> +
> +#define _atomic_spin_unlock_irqrestore_user(l,f)	\
> +	_atomic_spin_unlock_irqrestore_template(l,f,ATOMIC_USER_HASH(l))
>  
>  #else
>  #  define _atomic_spin_lock_irqsave(l,f) do { local_irq_save(f); } while (0)
>  #  define _atomic_spin_unlock_irqrestore(l,f) do { local_irq_restore(f); } while (0)
> +#  define _atomic_spin_lock_irqsave_user(l,f) _atomic_spin_lock_irqsave(l,f)
> +#  define _atomic_spin_unlock_irqrestore_user(l,f) _atomic_spin_lock_irqsave_user(l,f)
>  #endif
>  
>  /* This should get optimized out since it's never called.
> diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h
> index 0c705c3..7bc963e 100644
> --- a/arch/parisc/include/asm/futex.h
> +++ b/arch/parisc/include/asm/futex.h
> @@ -55,6 +55,7 @@ futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
>  {
>  	int err = 0;
>  	int uval;
> +	unsigned long flags;
>  
>  	/* futex.c wants to do a cmpxchg_inatomic on kernel NULL, which is
>  	 * our gateway page, and causes no end of trouble...
> @@ -65,10 +66,15 @@ futex_atomic_cmpxchg_inatomic(int __user *uaddr, int oldval, int newval)
>  	if (!access_ok(VERIFY_WRITE, uaddr, sizeof(int)))
>  		return -EFAULT;
>  
> +	_atomic_spin_lock_irqsave_user(uaddr, flags);
> +
>  	err = get_user(uval, uaddr);
> -	if (err) return -EFAULT;
> -	if (uval == oldval)
> -		err = put_user(newval, uaddr);
> +	if (!err)
> +		if (uval == oldval)
> +			err = put_user(newval, uaddr);
> +
> +	_atomic_spin_unlock_irqrestore_user(uaddr, flags);
> +
>  	if (err) return -EFAULT;
>  	return uval;
>  }
> diff --git a/arch/parisc/include/asm/system.h b/arch/parisc/include/asm/system.h
> index d91357b..4653c77 100644
> --- a/arch/parisc/include/asm/system.h
> +++ b/arch/parisc/include/asm/system.h
> @@ -160,7 +160,7 @@ static inline void set_eiem(unsigned long val)
>     ldcd). */
>  
>  #define __PA_LDCW_ALIGNMENT	4
> -#define __ldcw_align(a) ((volatile unsigned int *)a)
> +#define __ldcw_align(a) (&(a)->slock)
>  #define __LDCW	"ldcw,co"
>  
>  #endif /*!CONFIG_PA20*/
> diff --git a/arch/parisc/kernel/asm-offsets.c b/arch/parisc/kernel/asm-offsets.c
> index ec787b4..50353bd 100644
> --- a/arch/parisc/kernel/asm-offsets.c
> +++ b/arch/parisc/kernel/asm-offsets.c
> @@ -290,5 +290,11 @@ int main(void)
>  	BLANK();
>  	DEFINE(ASM_PDC_RESULT_SIZE, NUM_PDC_RESULT * sizeof(unsigned long));
>  	BLANK();
> +
> +#ifdef CONFIG_SMP
> +	DEFINE(ASM_ATOMIC_HASH_SIZE_SHIFT, __builtin_ffs(ATOMIC_HASH_SIZE)-1);
> +	DEFINE(ASM_ATOMIC_HASH_ENTRY_SHIFT, __builtin_ffs(sizeof(__atomic_hash[0]))-1);
> +#endif
> +
>  	return 0;
>  }
> diff --git a/arch/parisc/kernel/setup.c b/arch/parisc/kernel/setup.c
> index cb71f3d..878f42c 100644
> --- a/arch/parisc/kernel/setup.c
> +++ b/arch/parisc/kernel/setup.c
> @@ -128,6 +131,14 @@ void __init setup_arch(char **cmdline_p)
>  	printk(KERN_INFO "The 32-bit Kernel has started...\n");
>  #endif
>  
> +	/* Consistency check on the size and alignments of our spinlocks */
> +#ifdef CONFIG_SMP
> +	BUILD_BUG_ON(sizeof(arch_spinlock_t) != __PA_LDCW_ALIGNMENT);
> +	BUG_ON((unsigned long)&__atomic_hash[0] & (__PA_LDCW_ALIGNMENT-1));
> +	BUG_ON((unsigned long)&__atomic_hash[1] & (__PA_LDCW_ALIGNMENT-1));
> +#endif
> +	BUILD_BUG_ON((1<<L1_CACHE_SHIFT) != L1_CACHE_BYTES);
> +
>  	pdc_console_init();
>  
>  #ifdef CONFIG_64BIT
> diff --git a/arch/parisc/kernel/syscall.S b/arch/parisc/kernel/syscall.S
> index f5f9602..1f12418 100644
> --- a/arch/parisc/kernel/syscall.S
> +++ b/arch/parisc/kernel/syscall.S
> @@ -11,6 +11,7 @@
>  #include <asm/unistd.h>
>  #include <asm/errno.h>
>  #include <asm/page.h>
> +#include <asm/cache.h>
>  #include <asm/psw.h>
>  #include <asm/thread_info.h>
>  #include <asm/assembly.h>
> @@ -47,18 +48,17 @@ ENTRY(linux_gateway_page)
>  	KILL_INSN
>  	.endr
>  
> -	/* ADDRESS 0xb0 to 0xb4, lws uses 1 insns for entry */
> +	/* ADDRESS 0xb0 to 0xb8, lws uses two insns for entry */
>  	/* Light-weight-syscall entry must always be located at 0xb0 */
>  	/* WARNING: Keep this number updated with table size changes */
>  #define __NR_lws_entries (2)
>  
>  lws_entry:
> -	/* Unconditional branch to lws_start, located on the 
> -	   same gateway page */
> -	b,n	lws_start
> +	gate	lws_start, %r0		/* increase privilege */
> +	depi	3, 31, 2, %r31		/* Ensure we return into user mode. */
>  
> -	/* Fill from 0xb4 to 0xe0 */
> -	.rept 11
> +	/* Fill from 0xb8 to 0xe0 */
> +	.rept 10
>  	KILL_INSN
>  	.endr
>  
> @@ -423,9 +423,6 @@ tracesys_sigexit:
>  
>  	*********************************************************/
>  lws_start:
> -	/* Gate and ensure we return to userspace */
> -	gate	.+8, %r0
> -	depi	3, 31, 2, %r31	/* Ensure we return to userspace */
>  
>  #ifdef CONFIG_64BIT
>  	/* FIXME: If we are a 64-bit kernel just
> @@ -473,7 +470,7 @@ lws_exit:
>  	/* now reset the lowest bit of sp if it was set */
>  	xor	%r30,%r1,%r30
>  #endif
> -	be,n	0(%sr3, %r31)
> +	be,n	0(%sr7, %r31)
>  
>  
>  	
> @@ -530,18 +527,17 @@ lws_compare_and_swap32:
>  
>  lws_compare_and_swap:
>  #ifdef CONFIG_SMP
> -	/* Load start of lock table */
> -	ldil	L%lws_lock_start, %r20
> -	ldo	R%lws_lock_start(%r20), %r28
> +	/* Calculate lock table entry via ATOMIC_HASH(%r26) */
> +	ldil	L%__atomic_user_hash, %r20
> +	ldo	R%__atomic_user_hash(%r20), %r28
>  
> -	/* Extract four bits from r26 and hash lock (Bits 4-7) */
> -	extru  %r26, 27, 4, %r20
> +#ifdef CONFIG_64BIT
> +	extrd,u %r26, 63-L1_CACHE_SHIFT, ASM_ATOMIC_HASH_SIZE_SHIFT, %r20
> +#else
> +	extru	%r26, 31-L1_CACHE_SHIFT, ASM_ATOMIC_HASH_SIZE_SHIFT, %r20
> +#endif
> +	shladd,l %r20, ASM_ATOMIC_HASH_ENTRY_SHIFT, %r28, %r20
>  
> -	/* Find lock to use, the hash is either one of 0 to
> -	   15, multiplied by 16 (keep it 16-byte aligned)
> -	   and add to the lock table offset. */
> -	shlw	%r20, 4, %r20
> -	add	%r20, %r28, %r20
>  
>  # if ENABLE_LWS_DEBUG
>  	/*	
> @@ -672,31 +668,6 @@ ENTRY(sys_call_table64)
>  END(sys_call_table64)
>  #endif
>  
> -#ifdef CONFIG_SMP
> -	/*
> -		All light-weight-syscall atomic operations 
> -		will use this set of locks 
> -
> -		NOTE: The lws_lock_start symbol must be
> -		at least 16-byte aligned for safe use
> -		with ldcw.
> -	*/
> -	.section .data
> -	.align	PAGE_SIZE
> -ENTRY(lws_lock_start)
> -	/* lws locks */
> -	.rept 16
> -	/* Keep locks aligned at 16-bytes */
> -	.word 1
> -	.word 0 
> -	.word 0
> -	.word 0
> -	.endr
> -END(lws_lock_start)
> -	.previous
> -#endif
> -/* CONFIG_SMP for lws_lock_start */
> -
>  .end
>  
>  
> diff --git a/arch/parisc/lib/bitops.c b/arch/parisc/lib/bitops.c
> index 353963d..bae6a86 100644
> --- a/arch/parisc/lib/bitops.c
> +++ b/arch/parisc/lib/bitops.c
> @@ -15,6 +15,9 @@
>  arch_spinlock_t __atomic_hash[ATOMIC_HASH_SIZE] __lock_aligned = {
>  	[0 ... (ATOMIC_HASH_SIZE-1)]  = __ARCH_SPIN_LOCK_UNLOCKED
>  };
> +arch_spinlock_t __atomic_user_hash[ATOMIC_HASH_SIZE] __lock_aligned = {
> +	[0 ... (ATOMIC_HASH_SIZE-1)]  = __ARCH_SPIN_LOCK_UNLOCKED
> +};
>  #endif
>  
>  #ifdef CONFIG_64BIT
> diff --git a/kernel/fork.c b/kernel/fork.c
> index f88bd98..108b1ed 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -608,7 +608,10 @@ void mm_release(struct task_struct *tsk, struct mm_struct *mm)
>  			 * We don't check the error code - if userspace has
>  			 * not set up a proper pointer then tough luck.
>  			 */
> +			unsigned long flags;
> +			_atomic_spin_lock_irqsave_user(tsk->clear_child_tid, flags);
>  			put_user(0, tsk->clear_child_tid);
> +			_atomic_spin_unlock_irqrestore_user(tsk->clear_child_tid, flags);
>  			sys_futex(tsk->clear_child_tid, FUTEX_WAKE,
>  					1, NULL, NULL, 0);
>  		}
> @@ -1432,8 +1435,12 @@ long do_fork(unsigned long clone_flags,
>  
>  		nr = task_pid_vnr(p);
>  
> -		if (clone_flags & CLONE_PARENT_SETTID)
> +		if (clone_flags & CLONE_PARENT_SETTID) {
> +			unsigned long flags;
> +			_atomic_spin_lock_irqsave_user(parent_tidptr, flags);
>  			put_user(nr, parent_tidptr);
> +			_atomic_spin_unlock_irqrestore_user(parent_tidptr, flags);
> +		}
>  
>  		if (clone_flags & CLONE_VFORK) {
>  			p->vfork_done = &vfork;


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

Re: futex wait failure

[John David Anglin]

> The c3750 completed a full GCC build but there were again problems running
> the testsuite.  For example,
> 
> Core was generated by `expect -- /usr/share/dejagnu/runtest.exp --tool gcc'.
> Program terminated with signal 11, Segmentation fault.
> #0  0x409fa258 in ?? () from /usr/lib/libtcl8.5.so.0
> (gdb) bt
> #0  0x409fa258 in ?? () from /usr/lib/libtcl8.5.so.0
> #1  0x402600a0 in start_thread (arg=0x416a4480) at pthread_create.c:302
> #2  0x40e25874 in clone ()
>     at ../ports/sysdeps/unix/sysv/linux/hppa/nptl/../clone.S:166
> #3  0x00000000 in ?? ()
> 
> This looks like the minifail clone bug.  On the otherhand, minifail doesn't
> seem to be failing.

I reverted Helge's patch and still get the same fault, so it didn't
introduce the problem.

Prior to 2.6.33, I was running 2.6.31.12 with essentially the same config.
The libc6 update to 2.10.2-6 changed things on the c3750.  Prior to the
update, expect would hang several times running the acats testsuite.  After
the update, this was fixed.  However, the above problem was introduced,
or became more frequent.

I have the feeling that Helge's patch helps (possible resolves) the
minifail bug.

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

Re: futex wait failure

[John David Anglin]

On Sun, 07 Mar 2010, John David Anglin wrote:

> I have the feeling that Helge's patch helps (possible resolves) the
> minifail bug.

With further testing, I find that the patch doesn't resolve the minifail
fails on my c3750.

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

Re: futex wait failure

[Kyle McMartin]

On Wed, Mar 10, 2010 at 10:20:49PM -0500, John David Anglin wrote:
> > I have the feeling that Helge's patch helps (possible resolves) the
> > minifail bug.
> 
> With further testing, I find that the patch doesn't resolve the minifail
> fails on my c3750.
> 

Bummer. :(

Re: futex wait failure

[John David Anglin]

On Thu, 11 Mar 2010, Kyle McMartin wrote:

> On Wed, Mar 10, 2010 at 10:20:49PM -0500, John David Anglin wrote:
> > > I have the feeling that Helge's patch helps (possible resolves) the
> > > minifail bug.
> > 
> > With further testing, I find that the patch doesn't resolve the minifail
> > fails on my c3750.
> > 
> 
> Bummer. :(

Yes.

I am 95% certain that the bug has to do with the clone implementation
and scheduling.  I have attached another version of the minifail test.
The loops after the fork and pthread_create calls are to isolate these
syscalls.  Typically, I see something like:

Core was generated by `./minifail9s'.
Program terminated with signal 11, Segmentation fault.
#0  0x00000000 in ?? ()
(gdb) info thread
  2 Thread 11537  pure_test () at minifail9.cpp:51
* 1 Thread 11538  0x00000000 in ?? ()

Thread 2 is in the pure_test loop after the fork call.

The cause of the failure is not at all obvious to me but I am a
bit concerned about the sys_clone implementation.  Is it possible
that the struct pt_regs gets clobbered?

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

Re: futex wait failure

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

On Thu, 11 Mar 2010, John David Anglin wrote:

> I am 95% certain that the bug has to do with the clone implementation
> and scheduling.  I have attached another version of the minifail test.
> The loops after the fork and pthread_create calls are to isolate these
> syscalls.  Typically, I see something like:

Attached.

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

[-- Attachment #2: minifail9.cpp --]
[-- Type: text/plain, Size: 1352 bytes --]

#include <pthread.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

/*
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203

  clone(child_stack=0x4088d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x4108c4e8, tls=0x4108c900, child_tidptr=0x4108c4e8) = 14819
[pid 14819] set_robust_list(0x4108c4f0, 0xc) = 0
[pid 14818] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 14820

 g++  minifail.cpp -o minifail -O0 -pthread -g

 i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail; done;

 */

static volatile int run = 1;

void* thread_run(void* arg) {
	static long status;
	int i;
        
	run = 1;
	pthread_yield();
	for (i = 10000000; i; i--)
	   continue;
	write(1,"Thread OK.\n",11);
	return (void *)&status;
}

int pure_test() {
	int i;
	pthread_t thread;
	pthread_create(&thread, NULL, thread_run, NULL);

	while (!run)
	  pthread_yield();
	switch (fork()) {
		case -1:
			perror("fork() failed");
		case 0:
			write(1,"Child OK.\n",10);
			_exit(0);
		default:
			break;
		
	}
	pthread_yield();
	for (i = 20000000; i; i--)
	  continue;
	write(1,"Fork done\n",10);
	pthread_join(thread, NULL);
	return 0;
}

int main(int argc, char** argv) {
	return pure_test();
}

Re: futex wait failure

[John David Anglin]

On Thu, 11 Mar 2010, John David Anglin wrote:

> I am 95% certain that the bug has to do with the clone implementation
> and scheduling.  I have attached another version of the minifail test.
> The loops after the fork and pthread_create calls are to isolate these
> syscalls.  Typically, I see something like:

Here's another idea.  In entry.S, there are some tricky tests to determine
whether to do signals and reschedule.  Based on testing, I'm not sure
that cr30 is always valid (e.g., external interrupt at boot) when we get to
intr_check_resched and intr_check_sig.

The other issue is r16.  I'm thinking we may need to reload r16 as the
context may change if we schedule, etc.  If this checking is broken, it
would break the LWS assumptions.

Thoughts?

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

Re: futex wait failure

[John David Anglin]

On Fri, 12 Mar 2010, John David Anglin wrote:

> The other issue is r16.  I'm thinking we may need to reload r16 as the
> context may change if we schedule, etc.  If this checking is broken, it
> would break the LWS assumptions.

This theory is shotdown.  The patch below possibly helps a bit but it
doesn't resolve the minifail bug.  The intention of the last couple of
hunks is to return to the right place if cr30 changes as a result of
scheduling.

With more debugging, it seems that this is a clone mmap copy issue.
Normally, the forked child doesn't see any non-zero data in the
stack region allocated by pthread_create.  However, if it does, 
the thread invariably dies and the stack region is corrupt after
the fork.

I guess I said this before ;(

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

diff --git a/arch/parisc/kernel/entry.S b/arch/parisc/kernel/entry.S
index 3a44f7f..820d6ca 100644
--- a/arch/parisc/kernel/entry.S
+++ b/arch/parisc/kernel/entry.S
@@ -758,6 +758,10 @@ ENTRY(__kernel_thread)
 
 	STREG	%r22, PT_GR22(%r1)	/* save r22 (arg5) */
 	copy	%r0, %r22		/* user_tid */
+	copy	%r0, %r21		/* child_tid */
+#else
+	stw	%r0, -52(%r30)	     	/* user_tid */
+	stw	%r0, -56(%r30)	     	/* child_tid */
 #endif
 	STREG	%r26, PT_GR26(%r1)  /* Store function & argument for child */
 	STREG	%r25, PT_GR25(%r1)
@@ -765,7 +769,7 @@ ENTRY(__kernel_thread)
 	ldo	CLONE_VM(%r26), %r26   /* Force CLONE_VM since only init_mm */
 	or	%r26, %r24, %r26      /* will have kernel mappings.	 */
 	ldi	1, %r25			/* stack_start, signals kernel thread */
-	stw	%r0, -52(%r30)	     	/* user_tid */
+	ldi	0, %r23			/* child_stack_size */
 #ifdef CONFIG_64BIT
 	ldo	-16(%r30),%r29		/* Reference param save area */
 #endif
@@ -972,7 +976,10 @@ intr_check_sig:
 	BL	do_notify_resume,%r2
 	copy	%r16, %r26			/* struct pt_regs *regs */
 
-	b,n	intr_check_sig
+	mfctl   %cr30,%r16		/* Reload */
+	LDREG	TI_TASK(%r16), %r16	/* thread_info -> task_struct */
+	b	intr_check_sig
+	ldo	TASK_REGS(%r16),%r16
 
 intr_restore:
 	copy            %r16,%r29
@@ -1026,14 +1033,12 @@ intr_do_resched:
 	ldo	-16(%r30),%r29		/* Reference param save area */
 #endif
 
-	ldil	L%intr_check_sig, %r2
-#ifndef CONFIG_64BIT
-	b	schedule
-#else
-	load32	schedule, %r20
-	bv	%r0(%r20)
-#endif
-	ldo	R%intr_check_sig(%r2), %r2
+	BL	schedule,%r2
+	nop
+	mfctl   %cr30,%r16		/* Reload */
+	LDREG	TI_TASK(%r16), %r16	/* thread_info -> task_struct */
+	b	intr_check_sig
+	ldo	TASK_REGS(%r16),%r16
 
 	/* preempt the current task on returning to kernel
 	 * mode from an interrupt, iff need_resched is set,

Re: futex wait failure

[Carlos O'Donell]

On Sun, Mar 14, 2010 at 9:10 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> On Fri, 12 Mar 2010, John David Anglin wrote:
>
>> The other issue is r16. =A0I'm thinking we may need to reload r16 as=
 the
>> context may change if we schedule, etc. =A0If this checking is broke=
n, it
>> would break the LWS assumptions.
>
> This theory is shotdown. =A0The patch below possibly helps a bit but =
it
> doesn't resolve the minifail bug. =A0The intention of the last couple=
 of
> hunks is to return to the right place if cr30 changes as a result of
> scheduling.

Thanks for testing this out.

> With more debugging, it seems that this is a clone mmap copy issue.
> Normally, the forked child doesn't see any non-zero data in the
> stack region allocated by pthread_create. =A0However, if it does,
> the thread invariably dies and the stack region is corrupt after
> the fork.
>
> I guess I said this before ;(

After some of my own testing I think this is all MMU related, but I
can't prove it yet. I'm pouring through as much kernel code as I can
right now to determine what is going wrong at the time of the clone,
and I see at least one bug that I'm investigating regarding return
addresses.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]

On Tue, 16 Mar 2010, Carlos O'Donell wrote:

> After some of my own testing I think this is all MMU related, but I
> can't prove it yet. I'm pouring through as much kernel code as I can
> right now to determine what is going wrong at the time of the clone,
> and I see at least one bug that I'm investigating regarding return
> addresses.

I've attached another version of the minifail test program.  In
this one, the parent and thread both monitor the location 0x4000001c
in the stack region allocated to the thread.  If a problem is
detected, they drop core with an illegal instruction.  If the
child of the fork sees a nonzero value in the above location
when the fork call returns, it sleeps for ten seconds.

When corruption occurs and core is dropped on my c3750 (UP 32-bit
kernel), both the parent and thread have undergone many iterations
of their respective monitor loops.  The forked child always reports
seeing a nonzero value at the stack location.  The before value
in the core dump was zero (i.e., thread_run had not started).

I added an illegal instruction abort to the child.  In this case,
the thread_run loop counter was 48085 when the page was copied and
the before value was zero.

One thought that has crossed my mind is that the memory pages allocated
for the stack region used by the thread are somehow getting interchanged
between parent and child by the fork operation.  This happens fairly
late as both the parent and thread are executing post fork at the time
this happens.  Possibly, this is part of the bug.

I have looked at entry.S and pacache.S quite a bit and it's not obvious
how this could happen, although I must admit to not fully understanding
the tmp alias code.  I tend to think the bug is in the core mm code.

I see a few cleanups to entry.S.  We didn't kill the misnamed macros
(DEP, DEPI and EXTR) for example.  But I don't think these are the problem.

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

[-- Attachment #2: minifail12.cpp --]
[-- Type: text/plain, Size: 1817 bytes --]

#include <pthread.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>

/*
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561203

  clone(child_stack=0x4088d040, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x4108c4e8, tls=0x4108c900, child_tidptr=0x4108c4e8) = 14819
[pid 14819] set_robust_list(0x4108c4f0, 0xc) = 0
[pid 14818] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002028) = 14820

 g++  minifail.cpp -o minifail -O0 -pthread -g

 i=0; while true; do i=$(($i+1)); echo Run $i; ./minifail; done;

 */

int before = -1;

void* thread_run(void* arg) {
	static long status;
	int i;
        
	for (i = 1000000; i; i--)
	  if (*(volatile int *)0x4000001c != 0x407ff340)
	    asm ("iitlbp %r0,(%sr0,%r0)");
	return (void *)&status;
}

int pure_test() {
	int i, stat, x;
	int seen = 0;
	pthread_t thread;
	pthread_create(&thread, NULL, thread_run, NULL);

	before = *(volatile int *)0x4000001c;
	switch (fork()) {
		case -1:
			perror("fork() failed");
		case 0:
			/* x is non-zero iff start thread has saved
			     `args' onto stack in r26 slot.  */
			x = *(volatile int *)0x4000001c;
			if (x == 0x407ff340)
			  {
				sleep (10);
			  }
			printf ("c 0x%x\n", x);
			fflush (stdout);
			return 0;
		default:
			break;
		
	}
	for (i = 1000000; i; i--)
	  {
	    if (!seen && *(volatile int *)0x4000001c == 0x407ff340)
	      seen = i;
	    if (seen && *(volatile int *)0x4000001c != 0x407ff340)
	      asm ("iitlbp %r0,(%sr0,%r0)");
	  }
	printf ("p 0x%x\n", *(int *)0x4000001c);
	if (pthread_join(thread, NULL))
	  perror ("join");
	return 0;
}

int main(int argc, char** argv) {
	return pure_test();
}

Re: futex wait failure

[Carlos O'Donell]

On Sun, Mar 21, 2010 at 2:19 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> I added an illegal instruction abort to the child. =A0In this case,
> the thread_run loop counter was 48085 when the page was copied and
> the before value was zero.
>
> One thought that has crossed my mind is that the memory pages allocat=
ed
> for the stack region used by the thread are somehow getting interchan=
ged
> between parent and child by the fork operation. =A0This happens fairl=
y
> late as both the parent and thread are executing post fork at the tim=
e
> this happens. =A0Possibly, this is part of the bug.
>
> I have looked at entry.S and pacache.S quite a bit and it's not obvio=
us
> how this could happen, although I must admit to not fully understandi=
ng
> the tmp alias code. =A0I tend to think the bug is in the core mm code=
=2E
>
> I see a few cleanups to entry.S. =A0We didn't kill the misnamed macro=
s
> (DEP, DEPI and EXTR) for example. =A0But I don't think these are the =
problem.

Dave,

Thank you for another test case. I agree, I also think the bug is in
the core mm code, which I am also trying to review and understand. I
haven't been able to make much progress in this area though. I'll keep
you updated when I spot something I think is wrong.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[Carlos O'Donell]

On Sun, Mar 21, 2010 at 2:19 PM, John David Anglin
<dave@hiauly1.hia.nrc.ca> wrote:
> One thought that has crossed my mind is that the memory pages allocat=
ed
> for the stack region used by the thread are somehow getting interchan=
ged
> between parent and child by the fork operation. =A0This happens fairl=
y
> late as both the parent and thread are executing post fork at the tim=
e
> this happens. =A0Possibly, this is part of the bug.
>
> I have looked at entry.S and pacache.S quite a bit and it's not obvio=
us
> how this could happen, although I must admit to not fully understandi=
ng
> the tmp alias code. =A0I tend to think the bug is in the core mm code=
=2E
>
> I see a few cleanups to entry.S. =A0We didn't kill the misnamed macro=
s
> (DEP, DEPI and EXTR) for example. =A0But I don't think these are the =
problem.

I can't get minifail2 to fail, how are you choosing which stack
address to watch for corruption?

Are you looking at the child's new stack created by mmap?

Are you looking at the parent's stack?

I found one bug in the hppa vfork() function call, which in the case
of error, would fail to propagate the error correctly. Fixing that and
will check it in. It doesn't account for the vfork/execve problems
though, since in this case vfork completes but execve crashes.

I also have some patches for asm-offsets.c, and entry.S to comment
some of the code better. I'll send those to Kyle after cleanup.

Cheers,
Carlos.
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc"=
 in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: futex wait failure

[John David Anglin]

> I can't get minifail2 to fail, how are you choosing which stack
> address to watch for corruption?

The stack allocated by pthread_create is always placed at 0x40000000
in my runs.  The location that the last version which I sent monitors
is 0x4000001c.  This is the location where thread_run saves %r26
shortly after entry.

I'm compiling without optimization as indicated in the comment.  Usually,
I also link with -static since gdb is somewhat broken when debugging
shared libraries.  If the compile is optimized, then thread_run may
not save much on the stack and it may be harder to get it to fail.

The problem is timing dependent.  I'm a bit surprised that you can't
duplicate the problem as Helge could.  When I run the test loop, it
fails about one in thirty on my c3750.  I have a 250 Hz tick rate in
my config.  The fail rate is somewhat dependent on system load.

I added the monitor loops to try and pin down when the corruption occurs
but the test should fail if the thread's stack region gets corrupted
while thread_run executes.

Have you made any changes to libc which would affect the synchonization
of parent and child?  I think the problem might be fixed if the parent
and thread were prevented from executing until the fork is complete.
I still think the kernel is interchanging the pages used by the parent
and child for the mmap'd stack region.

> Are you looking at the child's new stack created by mmap?

We are looking at the area allocated by mmap in the call to pthread_create.
This is always where the corruption occurs in the subsequent fork call.

This area is used as the stack for the thread created by pthread_create.
When the problem occurs, it's the thread that generates the fault, never
the original parent.

> Are you looking at the parent's stack?

No.  However, the parent can see changes to the stack area used by the
thread created by the pthread_create call.  As I understand the situtation,
the child of the fork call should see a snapshot of this area as it was
at the time of the fork call.  fork is nominally supposed to be "atomic"
(see Open Group man page).

In both the parent and forked child, the first three words starting at
0x40000000 are always nonzero and correct.  That's why I think the pages
are getting interchanged (I also played with adding extra cache flushes
in pacache.S but that didn't change things).

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