Changes to PPC Linux required for GCC 3.1

Changes to PPC Linux required for GCC 3.1

[Corey Minyard]

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

I've been working on getting Linux PPC running on GCC 3.1, and I'm
sending it from my Mac whose operating system was just compiled with a
current GCC 3.1 tree (Hurray!)

I've had to patch the kernel a little, there were a few violations and
some problems with interactions with optimizations.  I had to do the
following:

* In include/asm-ppc/prom.h, the calculations for the relocations were
offseting a large constant with a string.  This results in bogus
optimizations in GCC, and a comment in GCC seems to say that you
shouldn't do this.  I've fixed it by calling a function to do the
calculation.  I've posted something on the GCC newsgroup about this,
too, we'll see what they say.

* In drivers/video/aty/atyfb_base.c, there were some "const __init"
declarations, which are not allowed.

* In include/linux/sunrpc/clnt.h, I removed a bogus function declaration
which was messing up inlining.

The patch is attached, but you will need some GCC patches that are still
not in the tree to actually compile it with 3.1.

-Corey


[-- Attachment #2: gcc3-1.patch --]
[-- Type: text/plain, Size: 6432 bytes --]

--- arch/ppc/kernel/prom.c.old	Mon Dec  3 20:46:42 2001
+++ arch/ppc/kernel/prom.c	Mon Dec  3 20:30:21 2001
@@ -1993,3 +1993,9 @@
 	for (;;)
 		prom_exit();
 }
+
+unsigned long
+prom_add_offset(unsigned long x, long offset)
+{
+    return x + offset;
+}
--- drivers/video/aty/atyfb_base.c.old	Wed Nov 28 15:17:25 2001
+++ drivers/video/aty/atyfb_base.c	Wed Nov 28 15:32:08 2001
@@ -251,7 +251,7 @@
 static int default_mclk __initdata = 0;

 #ifndef MODULE
-static const char *mode_option __initdata = NULL;
+static char *mode_option __initdata = NULL;
 #endif

 #ifdef CONFIG_PPC
@@ -271,33 +271,33 @@
 static unsigned long phys_guiregbase[FB_MAX] __initdata = { 0, };
 #endif

-static const char m64n_gx[] __initdata = "mach64GX (ATI888GX00)";
-static const char m64n_cx[] __initdata = "mach64CX (ATI888CX00)";
-static const char m64n_ct[] __initdata = "mach64CT (ATI264CT)";
-static const char m64n_et[] __initdata = "mach64ET (ATI264ET)";
-static const char m64n_vta3[] __initdata = "mach64VTA3 (ATI264VT)";
-static const char m64n_vta4[] __initdata = "mach64VTA4 (ATI264VT)";
-static const char m64n_vtb[] __initdata = "mach64VTB (ATI264VTB)";
-static const char m64n_vt4[] __initdata = "mach64VT4 (ATI264VT4)";
-static const char m64n_gt[] __initdata = "3D RAGE (GT)";
-static const char m64n_gtb[] __initdata = "3D RAGE II+ (GTB)";
-static const char m64n_iic_p[] __initdata = "3D RAGE IIC (PCI)";
-static const char m64n_iic_a[] __initdata = "3D RAGE IIC (AGP)";
-static const char m64n_lt[] __initdata = "3D RAGE LT";
-static const char m64n_ltg[] __initdata = "3D RAGE LT-G";
-static const char m64n_gtc_ba[] __initdata = "3D RAGE PRO (BGA, AGP)";
-static const char m64n_gtc_ba1[] __initdata = "3D RAGE PRO (BGA, AGP, 1x only)";
-static const char m64n_gtc_bp[] __initdata = "3D RAGE PRO (BGA, PCI)";
-static const char m64n_gtc_pp[] __initdata = "3D RAGE PRO (PQFP, PCI)";
-static const char m64n_gtc_ppl[] __initdata = "3D RAGE PRO (PQFP, PCI, limited 3D)";
-static const char m64n_xl[] __initdata = "3D RAGE (XL)";
-static const char m64n_ltp_a[] __initdata = "3D RAGE LT PRO (AGP)";
-static const char m64n_ltp_p[] __initdata = "3D RAGE LT PRO (PCI)";
-static const char m64n_mob_p[] __initdata = "3D RAGE Mobility (PCI)";
-static const char m64n_mob_a[] __initdata = "3D RAGE Mobility (AGP)";
+static char m64n_gx[] __initdata = "mach64GX (ATI888GX00)";
+static char m64n_cx[] __initdata = "mach64CX (ATI888CX00)";
+static char m64n_ct[] __initdata = "mach64CT (ATI264CT)";
+static char m64n_et[] __initdata = "mach64ET (ATI264ET)";
+static char m64n_vta3[] __initdata = "mach64VTA3 (ATI264VT)";
+static char m64n_vta4[] __initdata = "mach64VTA4 (ATI264VT)";
+static char m64n_vtb[] __initdata = "mach64VTB (ATI264VTB)";
+static char m64n_vt4[] __initdata = "mach64VT4 (ATI264VT4)";
+static char m64n_gt[] __initdata = "3D RAGE (GT)";
+static char m64n_gtb[] __initdata = "3D RAGE II+ (GTB)";
+static char m64n_iic_p[] __initdata = "3D RAGE IIC (PCI)";
+static char m64n_iic_a[] __initdata = "3D RAGE IIC (AGP)";
+static char m64n_lt[] __initdata = "3D RAGE LT";
+static char m64n_ltg[] __initdata = "3D RAGE LT-G";
+static char m64n_gtc_ba[] __initdata = "3D RAGE PRO (BGA, AGP)";
+static char m64n_gtc_ba1[] __initdata = "3D RAGE PRO (BGA, AGP, 1x only)";
+static char m64n_gtc_bp[] __initdata = "3D RAGE PRO (BGA, PCI)";
+static char m64n_gtc_pp[] __initdata = "3D RAGE PRO (PQFP, PCI)";
+static char m64n_gtc_ppl[] __initdata = "3D RAGE PRO (PQFP, PCI, limited 3D)";
+static char m64n_xl[] __initdata = "3D RAGE (XL)";
+static char m64n_ltp_a[] __initdata = "3D RAGE LT PRO (AGP)";
+static char m64n_ltp_p[] __initdata = "3D RAGE LT PRO (PCI)";
+static char m64n_mob_p[] __initdata = "3D RAGE Mobility (PCI)";
+static char m64n_mob_a[] __initdata = "3D RAGE Mobility (AGP)";


-static const struct {
+static struct {
     u16 pci_id, chip_type;
     u8 rev_mask, rev_val;
     const char *name;
@@ -357,24 +357,24 @@
 #endif /* CONFIG_FB_ATY_CT */
 };

-static const char ram_dram[] __initdata = "DRAM";
-static const char ram_vram[] __initdata = "VRAM";
-static const char ram_edo[] __initdata = "EDO";
-static const char ram_sdram[] __initdata = "SDRAM";
-static const char ram_sgram[] __initdata = "SGRAM";
-static const char ram_wram[] __initdata = "WRAM";
-static const char ram_off[] __initdata = "OFF";
-static const char ram_resv[] __initdata = "RESV";
+static char ram_dram[] __initdata = "DRAM";
+static char ram_vram[] __initdata = "VRAM";
+static char ram_edo[] __initdata = "EDO";
+static char ram_sdram[] __initdata = "SDRAM";
+static char ram_sgram[] __initdata = "SGRAM";
+static char ram_wram[] __initdata = "WRAM";
+static char ram_off[] __initdata = "OFF";
+static char ram_resv[] __initdata = "RESV";

 #ifdef CONFIG_FB_ATY_GX
-static const char *aty_gx_ram[8] __initdata = {
+static char *aty_gx_ram[8] __initdata = {
     ram_dram, ram_vram, ram_vram, ram_dram,
     ram_dram, ram_vram, ram_vram, ram_resv
 };
 #endif /* CONFIG_FB_ATY_GX */

 #ifdef CONFIG_FB_ATY_CT
-static const char *aty_ct_ram[8] __initdata = {
+static char *aty_ct_ram[8] __initdata = {
     ram_off, ram_dram, ram_edo, ram_edo,
     ram_sdram, ram_sgram, ram_wram, ram_resv
 };
--- include/asm-ppc/prom.h.old	Mon Dec  3 20:22:11 2001
+++ include/asm-ppc/prom.h	Mon Dec  3 20:30:38 2001
@@ -104,9 +104,16 @@
  */
 extern unsigned long reloc_offset(void);

-#define PTRRELOC(x)	((typeof(x))((unsigned long)(x) + offset))
-#define PTRUNRELOC(x)	((typeof(x))((unsigned long)(x) - offset))
-#define RELOC(x)	(*PTRRELOC(&(x)))
+/* If you index into a constant string beyond the range of the string,
+   as the RELOC functions do, GCC thinks you are a loser and does wierd
+   calculations.  This function avoids that, it must be called to do the
+   addition for the pointer relocation. */
+extern unsigned long prom_add_offset(unsigned long x, long offset)
+    __attribute__ ((noinline));
+
+#define PTRRELOC(x)   ((typeof(x))prom_add_offset((unsigned long)(x), +offset))
+#define PTRUNRELOC(x) ((typeof(x))prom_add_offset((unsigned long)(x), -offset))
+#define RELOC(x)      (*PTRRELOC(&(x)))

 #endif /* _PPC_PROM_H */
 #endif /* __KERNEL__ */
--- include/linux/sunrpc/clnt.h.old	Mon Dec  3 21:05:34 2001
+++ include/linux/sunrpc/clnt.h	Mon Dec  3 21:05:44 2001
@@ -136,7 +136,6 @@
 	xprt_set_timeout(&clnt->cl_timeout, retr, incr);
 }

-extern void rpciod_tcp_dispatcher(void);
 extern void rpciod_wake_up(void);

 /*

Re: Changes to PPC Linux required for GCC 3.1

[David Edelsohn]

	What GCC patches do you need to build PowerPC Linux?

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Corey Minyard]

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

David Edelsohn wrote:

>	What GCC patches do you need to build PowerPC Linux?
>
>David
>
I believe the following patch is all that is left, I've gotten
everything else into the 3.1 stream.  I'm working with the GCC
maintainers to get this one in.

-Corey


[-- Attachment #2: gcc-ppc-3.1.diff --]
[-- Type: text/plain, Size: 3416 bytes --]

Index: recog.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/recog.c,v
retrieving revision 1.133
diff -u -r1.133 recog.c
--- recog.c	2001/11/02 10:52:08	1.133
+++ recog.c	2001/12/04 16:33:26
@@ -512,7 +512,8 @@
          separated from this function.  */
       if (GET_CODE (XEXP (x, 1)) == CONST_INT)
 	validate_change (object, loc,
-			 plus_constant (XEXP (x, 0), INTVAL (XEXP (x, 1))), 1);
+			 simplify_gen_binary
+			 (PLUS, GET_MODE (x), XEXP (x, 0), XEXP (x, 1)), 1);
       break;
     case MINUS:
       if (GET_CODE (XEXP (x, 1)) == CONST_INT
Index: simplify-rtx.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/simplify-rtx.c,v
retrieving revision 1.86
diff -u -r1.86 simplify-rtx.c
--- simplify-rtx.c	2001/11/14 13:51:10	1.86
+++ simplify-rtx.c	2001/12/04 16:33:27
@@ -95,6 +95,7 @@
 #define HWI_SIGN_EXTEND(low) \
  ((((HOST_WIDE_INT) low) < 0) ? ((HOST_WIDE_INT) -1) : ((HOST_WIDE_INT) 0))

+rtx neg_const_int PARAMS ((enum machine_mode, rtx));
 static int simplify_plus_minus_op_data_cmp PARAMS ((const void *,
 						    const void *));
 static rtx simplify_plus_minus		PARAMS ((enum rtx_code,
@@ -107,6 +108,17 @@
 static void simplify_binary_is2orm1	PARAMS ((PTR));

 \f
+/* Negate a CONST_INT rtx, truncating (because a conversion from a
+   maximally negative number can overflow). */
+rtx
+neg_const_int (mode, i)
+     enum machine_mode mode;
+     rtx i;
+{
+  return GEN_INT (trunc_int_for_mode (- INTVAL (i), mode));
+}
+
+\f
 /* Make a binary operation by properly ordering the operands and
    seeing if the expression folds.  */

@@ -136,10 +148,9 @@
       && GET_MODE (op0) != VOIDmode
       && (code == PLUS || code == MINUS))
     {
-      HOST_WIDE_INT value = INTVAL (op1);
       if (code == MINUS)
-	value = -value;
-      return plus_constant (op0, value);
+	op1 = neg_const_int (mode, op1);
+      return plus_constant (op0, INTVAL (op1));
     }
   else
     return gen_rtx_fmt_ee (code, mode, op0, op1);
@@ -1276,7 +1287,9 @@

 	  /* Don't let a relocatable value get a negative coeff.  */
 	  if (GET_CODE (op1) == CONST_INT && GET_MODE (op0) != VOIDmode)
-	    return plus_constant (op0, - INTVAL (op1));
+	    return simplify_gen_binary (PLUS, mode,
+					op0,
+					neg_const_int (mode, op1));

 	  /* (x - (x & y)) -> (x & ~y) */
 	  if (GET_CODE (op1) == AND)
@@ -1787,7 +1800,7 @@
 	    case CONST_INT:
 	      if (this_neg)
 		{
-		  ops[i].op = GEN_INT (- INTVAL (this_op));
+		  ops[i].op = neg_const_int (mode, this_op);
 		  ops[i].neg = 0;
 		  changed = 1;
 		}
@@ -1848,7 +1861,7 @@
 		    if (GET_CODE (tem) == NEG)
 		      tem = XEXP (tem, 0), lneg = !lneg;
 		    if (GET_CODE (tem) == CONST_INT && lneg)
-		      tem = GEN_INT (- INTVAL (tem)), lneg = 0;
+		      tem = neg_const_int (mode, tem), lneg = 0;

 		    ops[i].op = tem;
 		    ops[i].neg = lneg;
@@ -1881,10 +1894,10 @@
       && GET_CODE (ops[n_ops - 1].op) == CONST_INT
       && CONSTANT_P (ops[n_ops - 2].op))
     {
-      HOST_WIDE_INT value = INTVAL (ops[n_ops - 1].op);
+      rtx value = ops[n_ops - 1].op;
       if (ops[n_ops - 1].neg ^ ops[n_ops - 2].neg)
-	value = -value;
-      ops[n_ops - 2].op = plus_constant (ops[n_ops - 2].op, value);
+	value = neg_const_int (mode, value);
+      ops[n_ops - 2].op = plus_constant (ops[n_ops - 2].op, INTVAL (value));
       n_ops--;
     }

Re: Changes to PPC Linux required for GCC 3.1

[Franz Sirl]

At 17:13 04.12.2001, Corey Minyard wrote:
>I've been working on getting Linux PPC running on GCC 3.1, and I'm
>sending it from my Mac whose operating system was just compiled with a
>current GCC 3.1 tree (Hurray!)
>
>I've had to patch the kernel a little, there were a few violations and
>some problems with interactions with optimizations.  I had to do the
>following:
>
>* In include/asm-ppc/prom.h, the calculations for the relocations were
>offseting a large constant with a string.  This results in bogus
>optimizations in GCC, and a comment in GCC seems to say that you
>shouldn't do this.  I've fixed it by calling a function to do the
>calculation.  I've posted something on the GCC newsgroup about this,
>too, we'll see what they say.

I've done

-#define RELOC(x)       (*PTRRELOC(&(x)))
+#define RELOC(x)       (*({ typeof(x) * __ptr  = PTRRELOC(&(x)); __asm__
("" : "=r" (__ptr) : "0" (__ptr)); __ptr;}))

a while ago in
<http://source.mvista.com/pipermail/linuxppc-commit/2001-September/000729.html>,
seems nobody applied it so far.

>* In drivers/video/aty/atyfb_base.c, there were some "const __init"
>declarations, which are not allowed.

Ah, I see, I only saw this problem in aty128fb. I'll add the fix to the
linuxconsole CVS for 2.5.x.

>* In include/linux/sunrpc/clnt.h, I removed a bogus function declaration
>which was messing up inlining.

I guess this is 3.1 specific? I don't remember problems with 3.0.x.

What about the FAT filesystem? Is gcc-3.1 now able to correctly optimize
the 64bit signed divide by const into a ASHIFT+fixup?

Franz.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Corey Minyard]

Franz Sirl wrote:

>
> I've done
>
> -#define RELOC(x)       (*PTRRELOC(&(x)))
> +#define RELOC(x)       (*({ typeof(x) * __ptr  = PTRRELOC(&(x));
> __asm__ ("" : "=r" (__ptr) : "0" (__ptr)); __ptr;}))
>
> a while ago in
> <http://source.mvista.com/pipermail/linuxppc-commit/2001-September/000729.html>,
> seems nobody applied it so far.

Ok.  It needs to be propped.

>
>
>> * In drivers/video/aty/atyfb_base.c, there were some "const __init"
>> declarations, which are not allowed.
>
>
> Ah, I see, I only saw this problem in aty128fb. I'll add the fix to
> the linuxconsole CVS for 2.5.x.

What about 2.4?  I'm sure people will want to compile 2.4 with gcc 3.x.

>
>
>> * In include/linux/sunrpc/clnt.h, I removed a bogus function declaration
>> which was messing up inlining.
>
>
> I guess this is 3.1 specific? I don't remember problems with 3.0.x.

Probably.  I've seen some other problems with GCC being fairly picky
about declarations, and I think it's fairly new.  But the declaration
both wrong and unnecessary.

>
>
> What about the FAT filesystem? Is gcc-3.1 now able to correctly
> optimize the 64bit signed divide by const into a ASHIFT+fixup?

Nope.  I was going to ask about that one.  Do you have a GCC PR on this?

-Corey


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Tom Rini]

On Wed, Dec 05, 2001 at 10:18:26AM -0600, Corey Minyard wrote:
>
> Franz Sirl wrote:
>
> >
> >I've done
> >
> >-#define RELOC(x)       (*PTRRELOC(&(x)))
> >+#define RELOC(x)       (*({ typeof(x) * __ptr  = PTRRELOC(&(x));
> >__asm__ ("" : "=r" (__ptr) : "0" (__ptr)); __ptr;}))
> >
> >a while ago in
> ><http://source.mvista.com/pipermail/linuxppc-commit/2001-September/000729.html>,
> >seems nobody applied it so far.
>
> Ok.  It needs to be propped.

I think the reason this wasn't applied is that Paul said something about
thiws being horriyingly ugly.  Corey, can you post a patch that changes
RELOC(x) into a function and nothing else? :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Benjamin Herrenschmidt]

>
>I think the reason this wasn't applied is that Paul said something about
>thiws being horriyingly ugly.  Corey, can you post a patch that changes
>RELOC(x) into a function and nothing else? :)

I prefer this beeing resolved at compile time. The reason Paul didn't want
it at first is because he didn't want a workaround for a pre-release gcc
bug. Since this is becoming a "feature", it makes sense to get the
workaround. Paulus will confirm or not what I'm saying though...

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Tom Rini]

On Wed, Dec 05, 2001 at 06:50:38PM +0100, Benjamin Herrenschmidt wrote:

> >I think the reason this wasn't applied is that Paul said something about
> >thiws being horriyingly ugly.  Corey, can you post a patch that changes
> >RELOC(x) into a function and nothing else? :)
>
> I prefer this beeing resolved at compile time. The reason Paul didn't want
> it at first is because he didn't want a workaround for a pre-release gcc
> bug. Since this is becoming a "feature", it makes sense to get the
> workaround. Paulus will confirm or not what I'm saying though...

This was actually being hit by a 3.0.x release at the time I think (and
we worked around it another way).  I'd prefer a clean function over an
ugly macro any day :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Franz Sirl]

On Wednesday 05 December 2001 20:45, Tom Rini wrote:
> On Wed, Dec 05, 2001 at 06:50:38PM +0100, Benjamin Herrenschmidt wrote:
> > >I think the reason this wasn't applied is that Paul said something about
> > >thiws being horriyingly ugly.  Corey, can you post a patch that changes
> > >RELOC(x) into a function and nothing else? :)
> >
> > I prefer this beeing resolved at compile time. The reason Paul didn't
> > want it at first is because he didn't want a workaround for a pre-release
> > gcc bug. Since this is becoming a "feature", it makes sense to get the
> > workaround. Paulus will confirm or not what I'm saying though...
>
> This was actually being hit by a 3.0.x release at the time I think (and
> we worked around it another way).  I'd prefer a clean function over an
> ugly macro any day :)

I don't understand how my patch makes the RELOC hack uglier than it is
already by itself ;-). The few affected files should really be reworked to be
compiled with something like -fPIC -mrelocateable (maybe with -msdata and
setup r12 accordingly).

Franz.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Gabriel Paubert]

On Wed, 5 Dec 2001, Franz Sirl wrote:

>
> On Wednesday 05 December 2001 20:45, Tom Rini wrote:
> > On Wed, Dec 05, 2001 at 06:50:38PM +0100, Benjamin Herrenschmidt wrote:
> > > >I think the reason this wasn't applied is that Paul said something about
> > > >thiws being horriyingly ugly.  Corey, can you post a patch that changes
> > > >RELOC(x) into a function and nothing else? :)
> > >
> > > I prefer this beeing resolved at compile time. The reason Paul didn't
> > > want it at first is because he didn't want a workaround for a pre-release
> > > gcc bug. Since this is becoming a "feature", it makes sense to get the
> > > workaround. Paulus will confirm or not what I'm saying though...
> >
> > This was actually being hit by a 3.0.x release at the time I think (and
> > we worked around it another way).  I'd prefer a clean function over an
> > ugly macro any day :)
>
> I don't understand how my patch makes the RELOC hack uglier than it is
> already by itself ;-). The few affected files should really be reworked to be
> compiled with something like -fPIC -mrelocateable (maybe with -msdata and
> setup r12 accordingly).

I agree, RELOC should die. Actually my bootloader for PreP machines is
compiled with -mrelocatable (that's sufficient). The only trick is that I
sacrificed a register (r13) to hold a pointer to a structure which
contains the few most heavily used variables.

Actually I'm almost certain that -msdata and similar options are
incompatible with -mrelocatable, or at least were 3 years ago. Not many
things have changes in this area in GCC since then AFAICT. That's why I
had to resort to this trick (easily hidden in macros if you want to) to
limit code growth, but you should realize that I'm an absolute fanatic of
minimal code size. Actually code size is not that important in a loader
that is thrown away early (OTOH current PPC kernels are so incredibly
bloated that it's not even funny).

Nevertheless, I found it very nice to have a system which does not have
any hardwired address (except for exception vectors).  It only needs a few
big enough contiguous chunks of memory.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

AltiVec register ptrace support

[Kumar Gala]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1216 bytes --]

I have two different patches to the ptrace mechanism to add support
for AltiVec registers.

linux-2.4.8-altivec-ptrace.patch:  Adds support similar to existing
mechanisms to get/set registers via PEEK/POKE calls extending the FPU
model.

linux-2.4.16-altivec-ptrace.patch: Adds support for new ptrace commands
that match sparc/x86 PTRACE_{GET,SET}*REGS.  These dump the full register
state in a single call.

Personally, I would like to see the PTRACE_{GET,SET}*REGS method adopted
for 2.4.x.  RedHat is trying to push out some GDB changes for AltiVec that
require closure on this matter.

I would then be willing to add support for getting/setting the
full GPR+ register state, and FPR+ register state for 2.5.x (will keeping
the existing support in place for GPRs+, and FPRs).  I would like to see
the PPC ptrace follow more what x86 and sparc are doing.  I would also
like to collect together the FPR state and VR state into new structs in
the thread state.  This would be similar to how x86 handles FPR and FPX.

There are some other aspects to this problem that should be fixed in
2.5.x.  However, before starting into that I would like to get closure on
the AltiVec ptrace support for 2.4.x.

thanks

- kumar


[-- Attachment #2: Type: TEXT/PLAIN, Size: 3319 bytes --]

diff -urN linux-2.4.16/arch/ppc/kernel/ptrace.c linux-2.4.16-avecptrace/arch/ppc/kernel/ptrace.c
--- linux-2.4.16/arch/ppc/kernel/ptrace.c	Mon Nov 26 07:29:17 2001
+++ linux-2.4.16-avecptrace/arch/ppc/kernel/ptrace.c	Fri Dec  7 14:37:20 2001
@@ -71,6 +71,64 @@
 	return -EIO;
 }
 
+#ifdef CONFIG_ALTIVEC
+/*
+ * Get contents of AltiVec register state in task TASK
+ */
+static inline int get_vrregs(unsigned long *data, struct task_struct *task)
+{
+	int i, j;
+
+        /* copy AltiVec registers VR[0] .. VR[31] */
+	for (i = 0;  i < 32;  i++)
+        {
+           for (j = 0; j < 4; j++, data++) 
+           {
+	      __put_user(task->thread.vr[i].u[j], data);
+           }
+        }
+
+        /* copy VSCR */
+        for (i = 0; i < 4; i++, data++) 
+        {
+	   __put_user(task->thread.vscr.u[i], data);
+        }
+
+        /* copy VRSAVE */
+        __put_user(task->thread.vrsave, data);
+
+	return (0);
+}
+
+/*
+ * Write contents of AltiVec register state into task TASK.
+ */
+static inline int set_vrregs(struct task_struct *task, unsigned long* data)
+{
+	int i, j;
+
+        /* copy AltiVec registers VR[0] .. VR[31] */
+	for (i = 0;  i < 32;  i++)
+        {
+           for (j = 0; j < 4; j++, data++) 
+           {
+	      __get_user(task->thread.vr[i].u[j], data);
+           }
+        }
+
+        /* copy VSCR */
+        for (i = 0; i < 4; i++, data++) 
+        {
+	   __get_user(task->thread.vscr.u[i], data);
+        }
+
+        /* copy VRSAVE */
+        __get_user(task->thread.vrsave, data);
+
+	return (0);
+}
+#endif
+
 static inline void
 set_single_step(struct task_struct *task)
 {
@@ -258,7 +316,35 @@
 	case PTRACE_DETACH:
 		ret = ptrace_detach(child, data);
 		break;
+#ifdef CONFIG_ALTIVEC
+	case PTRACE_GETVRREGS: { /* Get the child altivec register state. */
+		if (!access_ok(VERIFY_WRITE, (unsigned long*)data,
+			       (sizeof(__vector128) * 33 + sizeof(unsigned long)))) {
+			ret = -EIO;
+			break;
+		}
+                if (child->thread.regs->msr & MSR_VEC) {
+                   giveup_altivec(child);
+                }
+		ret = get_vrregs((unsigned long*)data, child);
+		break;
+	}
 
+	case PTRACE_SETVRREGS: { /* Set the child altivec register state. */
+		if (!access_ok(VERIFY_READ, (unsigned long*)data,
+			       (sizeof(__vector128) * 33 + sizeof(unsigned long)))) {
+			ret = -EIO;
+			break;
+		}
+		/* this is to clear the MSR_VEC bit to force a reload of register
+		 * state from memory */
+                if (child->thread.regs->msr & MSR_VEC) {
+                   giveup_altivec(child);
+                }
+		ret = set_vrregs(child, (unsigned long*)data);
+		break;
+	}
+#endif
 	default:
 		ret = -EIO;
 		break;
diff -urN linux-2.4.16/include/asm-ppc/ptrace.h linux-2.4.16-avecptrace/include/asm-ppc/ptrace.h
--- linux-2.4.16/include/asm-ppc/ptrace.h	Mon May 21 17:02:06 2001
+++ linux-2.4.16-avecptrace/include/asm-ppc/ptrace.h	Fri Dec  7 14:37:40 2001
@@ -103,5 +103,9 @@
 #define PT_FPR31 (PT_FPR0 + 2*31)
 #define PT_FPSCR (PT_FPR0 + 2*32 + 1)
 
+/* Arbitrarily choose the same ptrace numbers as used by the Sparc code. */
+#define PTRACE_GETVRREGS          18
+#define PTRACE_SETVRREGS          19
+
 #endif
 

[-- Attachment #3: Type: TEXT/PLAIN, Size: 1989 bytes --]

--- linux-2.4.8/arch/ppc/kernel/ptrace.c	Mon Jul 30 15:17:30 2001
+++ linux-2.4.8-ptrace/arch/ppc/kernel/ptrace.c	Wed Oct 24 14:26:55 2001
@@ -158,12 +158,23 @@
 		ret = -EIO;
 		/* convert to index and check */
 		index = (unsigned long) addr >> 2;
+#ifdef CONFIG_ALTIVEC
+		if ((addr & 3) || index > PT_VRSAVE)
+			break;
+#else
 		if ((addr & 3) || index > PT_FPSCR)
 			break;
+#endif
 
 		if (index < PT_FPR0) {
 			tmp = get_reg(child, (int) index);
 		} else {
+#ifdef CONFIG_ALTIVEC
+			if (index >= PT_VR0 && index <= PT_VRSAVE) {
+				if (child->thread.regs->msr & MSR_VEC)
+					giveup_altivec(child);
+			} else
+#endif
 			if (child->thread.regs != NULL
 			    && child->thread.regs->msr & MSR_FP)
 				giveup_fpu(child);
@@ -190,7 +201,11 @@
 		ret = -EIO;
 		/* convert to index and check */
 		index = (unsigned long) addr >> 2;
+#ifdef CONFIG_ALTIVEC
+		if ((addr & 3) || index > PT_VRSAVE)
+#else
 		if ((addr & 3) || index > PT_FPSCR)
+#endif
 			break;
 
 		if (index == PT_ORIG_R3)
@@ -198,6 +213,12 @@
 		if (index < PT_FPR0) {
 			ret = put_reg(child, index, data);
 		} else {
+#ifdef CONFIG_ALTIVEC
+			if (index >= PT_VR0 && index <= PT_VRSAVE) {
+				if (child->thread.regs->msr & MSR_VEC)
+					giveup_altivec(child);
+			}
+#endif
 			if (child->thread.regs != NULL
 			    && child->thread.regs->msr & MSR_FP)
 				giveup_fpu(child);
--- linux-2.4.8/include/asm-ppc/ptrace.h	Mon Jul 30 12:41:17 2001
+++ linux-2.4.8-ptrace/include/asm-ppc/ptrace.h	Wed Oct 24 14:27:20 2001
@@ -103,5 +103,12 @@
 #define PT_FPR31 (PT_FPR0 + 2*31)
 #define PT_FPSCR (PT_FPR0 + 2*32 + 1)
 
+/* old end of PTRACE_PEEKUSR range */
+
+#define PT_VR0  (PT_FPSCR + 1)         /* this has value of 114, just beyond the fpscr. */
+#define PT_VR31 (PT_VR0 + 4*31)
+#define PT_VSCR (PT_VR0 + 4*32)                /* this has value of 248 */
+#define PT_VRSAVE (PT_VR0 + 4*33)      /* this has value of 252 */
+
 #endif
 

Re: AltiVec register ptrace support

[Kevin Buettner]

On Dec 7,  2:57pm, Kumar Gala wrote:

> I have two different patches to the ptrace mechanism to add support
> for AltiVec registers.
>
> linux-2.4.8-altivec-ptrace.patch:  Adds support similar to existing
> mechanisms to get/set registers via PEEK/POKE calls extending the FPU
> model.
>
> linux-2.4.16-altivec-ptrace.patch: Adds support for new ptrace commands
> that match sparc/x86 PTRACE_{GET,SET}*REGS.  These dump the full register
> state in a single call.
>
> Personally, I would like to see the PTRACE_{GET,SET}*REGS method adopted
> for 2.4.x.  RedHat is trying to push out some GDB changes for AltiVec that
> require closure on this matter.

I would like to better understand your reasons for preferring
PTRACE_{GET,SET}*REGS.  Is it just because that's what x86 does
or do you think that this mechanism improves GDB's performance?

My personal opinion is that GETREGS/SETREGS does not greatly enhance
performance.  Try running strace on gdb debugging itself on x86 and on
PPC and compare the number of PTRACE_PEEKUSR calls on PPC vs.
PTRACE_????  calls on x86.  (The ????  is printed because strace
doesn't know about the various PTRACE_{GET,SET}*REGS calls.) When I
tried it just a moment ago using gdb to debug itself and running to a
breakpoint set on main(), I saw _more_ PTRACE_???? calls on x86 than
PEEKUSR/POKUSR calls on PPC.  Now, I admit that my testing wasn't very
exhaustive, but even if the number of PEEKUSR/POKEUSR calls were
higher, I think you'd find that calls to PEEKTEXT (for prologue
analysis) would dominate.  I.e, the majority of the ptrace() traffic
is due to reading memory, not reading registers.

Furthermore, I think that introducing GETREGS/SETREGS will make
ppc-linux-nat.c (in the GDB sources) more complicated.  We'll need
compile time tests to check for the presence of GETREGS/SETREGS and
use these mechanisms if they exist.  If they don't, this code will
have to fall back to using the old PEEKUSR/POKEUSR mechanism.  Also,
it may be necessary to have runtime tests which attempt to use
GETREGS/SETREGS and fall back to using PEEKUSR/POKEUSR.  In order to
see just how messy it can get, take a look at i386-linux-nat.c.

For the reasons stated above, I prefer your PEEKUSR/POKEUSR patch.

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: AltiVec register ptrace support

[Daniel Jacobowitz]

On Fri, Dec 07, 2001 at 03:23:02PM -0700, Kevin Buettner wrote:
> On Dec 7,  2:57pm, Kumar Gala wrote:
>
> > I have two different patches to the ptrace mechanism to add support
> > for AltiVec registers.
> >
> > linux-2.4.8-altivec-ptrace.patch:  Adds support similar to existing
> > mechanisms to get/set registers via PEEK/POKE calls extending the FPU
> > model.
> >
> > linux-2.4.16-altivec-ptrace.patch: Adds support for new ptrace commands
> > that match sparc/x86 PTRACE_{GET,SET}*REGS.  These dump the full register
> > state in a single call.
> >
> > Personally, I would like to see the PTRACE_{GET,SET}*REGS method adopted
> > for 2.4.x.  RedHat is trying to push out some GDB changes for AltiVec that
> > require closure on this matter.
>
> I would like to better understand your reasons for preferring
> PTRACE_{GET,SET}*REGS.  Is it just because that's what x86 does
> or do you think that this mechanism improves GDB's performance?

I think that it improves performance and that it is generally cleaner.

> My personal opinion is that GETREGS/SETREGS does not greatly enhance
> performance.  Try running strace on gdb debugging itself on x86 and on
> PPC and compare the number of PTRACE_PEEKUSR calls on PPC vs.
> PTRACE_????  calls on x86.  (The ????  is printed because strace
> doesn't know about the various PTRACE_{GET,SET}*REGS calls.) When I
> tried it just a moment ago using gdb to debug itself and running to a
> breakpoint set on main(), I saw _more_ PTRACE_???? calls on x86 than
> PEEKUSR/POKUSR calls on PPC.  Now, I admit that my testing wasn't very
> exhaustive, but even if the number of PEEKUSR/POKEUSR calls were
> higher, I think you'd find that calls to PEEKTEXT (for prologue
> analysis) would dominate.  I.e, the majority of the ptrace() traffic
> is due to reading memory, not reading registers.

You get more because there are three sets, and we gratuitously fetch
all registers instead of just the needed type of register.  I'd bet a
lot that a third of the 18 ????'s I see are for SSE registers and a
third for FP registers.  That would bring it down to 6 vs the 16 on PPC
using PEEKUSER.

Also, while I think _GETREGS is better than PEEKUSER, we're talking
here specifically about VRREGS.  It's four ptrace calls per vector
register, since ptrace() can only transfer a word at a time (so far at
least; I'm contemplating proposing a change to that).  And when you
want one vector register the odds are very good that one wants to get
another.

Also, while single stepping there ought to be no PEEKTEXT calls, only
PEEKUSER, and at least two of them on PPC (in fact we do a lot of
gratuitous poking around in the text segment).

> Furthermore, I think that introducing GETREGS/SETREGS will make
> ppc-linux-nat.c (in the GDB sources) more complicated.  We'll need
> compile time tests to check for the presence of GETREGS/SETREGS and
> use these mechanisms if they exist.  If they don't, this code will
> have to fall back to using the old PEEKUSR/POKEUSR mechanism.  Also,
> it may be necessary to have runtime tests which attempt to use
> GETREGS/SETREGS and fall back to using PEEKUSR/POKEUSR.  In order to
> see just how messy it can get, take a look at i386-linux-nat.c.

This part is definitely true.

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: AltiVec register ptrace support

[Kumar Gala]

Is there any reason that we can not spport both methods.  There are
applications in which having the ability to get all the registers is a
single syscall is a major performance improvement.

_ kumar

On Fri, 7 Dec 2001, Daniel Jacobowitz wrote:

>
> On Fri, Dec 07, 2001 at 03:23:02PM -0700, Kevin Buettner wrote:
> > On Dec 7,  2:57pm, Kumar Gala wrote:
> >
> > > I have two different patches to the ptrace mechanism to add support
> > > for AltiVec registers.
> > >
> > > linux-2.4.8-altivec-ptrace.patch:  Adds support similar to existing
> > > mechanisms to get/set registers via PEEK/POKE calls extending the FPU
> > > model.
> > >
> > > linux-2.4.16-altivec-ptrace.patch: Adds support for new ptrace commands
> > > that match sparc/x86 PTRACE_{GET,SET}*REGS.  These dump the full register
> > > state in a single call.
> > >
> > > Personally, I would like to see the PTRACE_{GET,SET}*REGS method adopted
> > > for 2.4.x.  RedHat is trying to push out some GDB changes for AltiVec that
> > > require closure on this matter.
> >
> > I would like to better understand your reasons for preferring
> > PTRACE_{GET,SET}*REGS.  Is it just because that's what x86 does
> > or do you think that this mechanism improves GDB's performance?
>
> I think that it improves performance and that it is generally cleaner.
>
> > My personal opinion is that GETREGS/SETREGS does not greatly enhance
> > performance.  Try running strace on gdb debugging itself on x86 and on
> > PPC and compare the number of PTRACE_PEEKUSR calls on PPC vs.
> > PTRACE_????  calls on x86.  (The ????  is printed because strace
> > doesn't know about the various PTRACE_{GET,SET}*REGS calls.) When I
> > tried it just a moment ago using gdb to debug itself and running to a
> > breakpoint set on main(), I saw _more_ PTRACE_???? calls on x86 than
> > PEEKUSR/POKUSR calls on PPC.  Now, I admit that my testing wasn't very
> > exhaustive, but even if the number of PEEKUSR/POKEUSR calls were
> > higher, I think you'd find that calls to PEEKTEXT (for prologue
> > analysis) would dominate.  I.e, the majority of the ptrace() traffic
> > is due to reading memory, not reading registers.
>
> You get more because there are three sets, and we gratuitously fetch
> all registers instead of just the needed type of register.  I'd bet a
> lot that a third of the 18 ????'s I see are for SSE registers and a
> third for FP registers.  That would bring it down to 6 vs the 16 on PPC
> using PEEKUSER.
>
> Also, while I think _GETREGS is better than PEEKUSER, we're talking
> here specifically about VRREGS.  It's four ptrace calls per vector
> register, since ptrace() can only transfer a word at a time (so far at
> least; I'm contemplating proposing a change to that).  And when you
> want one vector register the odds are very good that one wants to get
> another.
>
> Also, while single stepping there ought to be no PEEKTEXT calls, only
> PEEKUSER, and at least two of them on PPC (in fact we do a lot of
> gratuitous poking around in the text segment).
>
> > Furthermore, I think that introducing GETREGS/SETREGS will make
> > ppc-linux-nat.c (in the GDB sources) more complicated.  We'll need
> > compile time tests to check for the presence of GETREGS/SETREGS and
> > use these mechanisms if they exist.  If they don't, this code will
> > have to fall back to using the old PEEKUSR/POKEUSR mechanism.  Also,
> > it may be necessary to have runtime tests which attempt to use
> > GETREGS/SETREGS and fall back to using PEEKUSR/POKEUSR.  In order to
> > see just how messy it can get, take a look at i386-linux-nat.c.
>
> This part is definitely true.
>
> --
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer
>
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: AltiVec register ptrace support

[Jason R Thorpe]

On Fri, Dec 14, 2001 at 12:52:33PM -0600, Kumar Gala wrote:

 > Is there any reason that we can not spport both methods.  There are
 > applications in which having the ability to get all the registers is a
 > single syscall is a major performance improvement.

I'll chime in...

Other systems that support ptrace(2) don't have PEEK/POKE/READ_U/WRITE_U
methods.

I'm currently working on AltiVec for NetBSD/powerpc, and ptrace(2) interface
for AltiVec is going to look like:

	PT_GETALTIVECREGS
	PT_SETALTIVECREGS

...both of which using the following structure as an argument:

	struct vreg {
		uint32_t vreg[32][4];	/* vector register contents */
		register_t vscr;	/* vector status and control reg */
		register_t vrsave;	/* SPR 238 */
	};

This is consistent with how e.g. SSE/SSE2 registers are handled on
NetBSD/i386 (PT_GETXMMREGS/PT_SETXMMREGS).

--
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: AltiVec register ptrace support

[Andrew Cagney]

> Is there any reason that we can not spport both methods.  There are
> applications in which having the ability to get all the registers is a
> single syscall is a major performance improvement.

2/c worth.

Yes.

The Linux/PPC kernel supports PEEK/POKE for fetching registers.  The
proposed Kernel interface _consistently_ extends that interface using
the exact same mechanims to obtain the altivec regiters.  All the
required changes for this have been posted and have been demonstrated to
work.

Separate to that, it has been _proposed_ that the PPC ptrace() interface
be changed so that get/set reg for all register classes be added
(incomplete patch posted).  Isn't this separate to the problem at hand?

enjoy,
Andrew


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: AltiVec register ptrace support

[Kumar Gala]

> The Linux/PPC kernel supports PEEK/POKE for fetching registers.  The
> proposed Kernel interface _consistently_ extends that interface using
> the exact same mechanims to obtain the altivec regiters.  All the
> required changes for this have been posted and have been demonstrated to
> work.
>
> Separate to that, it has been _proposed_ that the PPC ptrace() interface
> be changed so that get/set reg for all register classes be added
> (incomplete patch posted).  Isn't this separate to the problem at hand?

I think you are correct they are separate issues.  I posted both methods
so we could decide in which direction we wanted to go with the ptrace
interface.  I would like to see the single word at a time interface that
currectly exists be patched to support AltiVec so we can get debugger
support working.  I would like this done to the 2.4.x tree.

- kumar


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: AltiVec register ptrace support

[Paul Mackerras]

Andrew Cagney writes:

> The Linux/PPC kernel supports PEEK/POKE for fetching registers.  The
> proposed Kernel interface _consistently_ extends that interface using
> the exact same mechanims to obtain the altivec regiters.  All the
> required changes for this have been posted and have been demonstrated to
> work.
>
> Separate to that, it has been _proposed_ that the PPC ptrace() interface
> be changed so that get/set reg for all register classes be added
> (incomplete patch posted).  Isn't this separate to the problem at hand?

If we are going to add a get/set reg interface for the altivec vector
registers, I would rather not extend the peek/poke interface to do
that as well.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: AltiVec register ptrace support

[Kumar Gala]

Paul,

Can you please make a decision regarding which version (or both) of the
AltiVec ptrace support should go into the kernel.

The two patches are available here:

http://lists.linuxppc.org/linuxppc-dev/200112/msg00107.html

The change is holding up altivec support for gdb.

Thanks

- kumar

On Mon, 17 Dec 2001, Paul Mackerras wrote:

> Andrew Cagney writes:
>
> > The Linux/PPC kernel supports PEEK/POKE for fetching registers.  The
> > proposed Kernel interface _consistently_ extends that interface using
> > the exact same mechanims to obtain the altivec regiters.  All the
> > required changes for this have been posted and have been demonstrated to
> > work.
> >
> > Separate to that, it has been _proposed_ that the PPC ptrace() interface
> > be changed so that get/set reg for all register classes be added
> > (incomplete patch posted).  Isn't this separate to the problem at hand?
>
> If we are going to add a get/set reg interface for the altivec vector
> registers, I would rather not extend the peek/poke interface to do
> that as well.
>
> Paul.
>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Paul Mackerras]

Benjamin Herrenschmidt writes:
> >
> >I think the reason this wasn't applied is that Paul said something about
> >thiws being horriyingly ugly.  Corey, can you post a patch that changes
> >RELOC(x) into a function and nothing else? :)
>
> I prefer this beeing resolved at compile time. The reason Paul didn't want
> it at first is because he didn't want a workaround for a pre-release gcc
> bug. Since this is becoming a "feature", it makes sense to get the
> workaround. Paulus will confirm or not what I'm saying though...

Actually, I'm annoyed that gcc thinks it can do something different
from what I have written.  If I wanted it to call memcpy instead of
strcpy, I would have written memcpy.  If I put in a call to strcpy, I
want the compiler to generate a "bl strcpy" instruction (assuming I
haven't declared strcpy to be inline of course).

This is the kernel, where we don't have a standard libc, and I would
much rather gcc didn't assume that it knows the semantics of things
like strcpy().  Does -fno-builtin achieve that effect?

Maybe the thing to do is to side-step the problem by having an extra
entry point for strcpy, called string_copy or something, and call that
instead of strcpy.

Paul.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Daniel Jacobowitz]

On Wed, Dec 05, 2001 at 10:37:28AM -0700, Tom Rini wrote:
>
> On Wed, Dec 05, 2001 at 10:18:26AM -0600, Corey Minyard wrote:
> >
> > Franz Sirl wrote:
> >
> > >
> > >I've done
> > >
> > >-#define RELOC(x)       (*PTRRELOC(&(x)))
> > >+#define RELOC(x)       (*({ typeof(x) * __ptr  = PTRRELOC(&(x));
> > >__asm__ ("" : "=r" (__ptr) : "0" (__ptr)); __ptr;}))
> > >
> > >a while ago in
> > ><http://source.mvista.com/pipermail/linuxppc-commit/2001-September/000729.html>,
> > >seems nobody applied it so far.
> >
> > Ok.  It needs to be propped.
>
> I think the reason this wasn't applied is that Paul said something about
> thiws being horriyingly ugly.  Corey, can you post a patch that changes
> RELOC(x) into a function and nothing else? :)

Has either of you tried to boot a kernel in which RELOC is a function?
If I'm following any of what's going on here, function symbols are
global.  To call the function you would need to use RELOC.

--
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[David Edelsohn]

>>>>> Daniel Jacobowitz writes:

Daniel> Has either of you tried to boot a kernel in which RELOC is a function?
Daniel> If I'm following any of what's going on here, function symbols are
Daniel> global.  To call the function you would need to use RELOC.

	PowerPC branches are relative.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Franz Sirl]

On Wednesday 05 December 2001 21:17, Daniel Jacobowitz wrote:
> On Wed, Dec 05, 2001 at 10:37:28AM -0700, Tom Rini wrote:
> > On Wed, Dec 05, 2001 at 10:18:26AM -0600, Corey Minyard wrote:
> > > Franz Sirl wrote:
> > > >I've done
> > > >
> > > >-#define RELOC(x)       (*PTRRELOC(&(x)))
> > > >+#define RELOC(x)       (*({ typeof(x) * __ptr  = PTRRELOC(&(x));
> > > >__asm__ ("" : "=r" (__ptr) : "0" (__ptr)); __ptr;}))
> > > >
> > > >a while ago in
> > > ><http://source.mvista.com/pipermail/linuxppc-commit/2001-September/000
> > > >729.html>, seems nobody applied it so far.
> > >
> > > Ok.  It needs to be propped.
> >
> > I think the reason this wasn't applied is that Paul said something about
> > thiws being horriyingly ugly.  Corey, can you post a patch that changes
> > RELOC(x) into a function and nothing else? :)
>
> Has either of you tried to boot a kernel in which RELOC is a function?
> If I'm following any of what's going on here, function symbols are
> global.  To call the function you would need to use RELOC.

RELOC is only used to relocate data.

Franz.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Corey Minyard]

Tom Rini wrote:

>
>I think the reason this wasn't applied is that Paul said something about
>thiws being horriyingly ugly.  Corey, can you post a patch that changes
>RELOC(x) into a function and nothing else? :)
>
My original patch has the function.  I prefer the macro, it may be a
little uglier but it removes a dependency between the include file and
the source.  It needs to be commented though, the reason for it's
wierdness is not really clear.

-Corey


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Tom Rini]

On Wed, Dec 05, 2001 at 06:59:14PM -0600, Corey Minyard wrote:
>
> Tom Rini wrote:
>
> >
> >I think the reason this wasn't applied is that Paul said something about
> >thiws being horriyingly ugly.  Corey, can you post a patch that changes
> >RELOC(x) into a function and nothing else? :)
>
> My original patch has the function.

Your patch had other fixes too tho.

> I prefer the macro, it may be a
> little uglier but it removes a dependency between the include file and
> the source.

Er, say what?  The macro is in the include file now...

> It needs to be commented though, the reason for it's
> wierdness is not really clear.

Well, that is somewhat true.  But the early boot stuffs are somewhat
mysterious from time to time anyways :)

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Corey Minyard]

Tom Rini wrote:

>On Wed, Dec 05, 2001 at 06:59:14PM -0600, Corey Minyard wrote:
>
>>Tom Rini wrote:
>>
>>>I think the reason this wasn't applied is that Paul said something about
>>>thiws being horriyingly ugly.  Corey, can you post a patch that changes
>>>RELOC(x) into a function and nothing else? :)
>>>
>>My original patch has the function.
>>
>
>Your patch had other fixes too tho.
>
I can take the patch and delete the files that don't pertain.  I'll wait
until we are sure this is the way the maintianers want to do it, though.

>
>
>>I prefer the macro, it may be a
>>little uglier but it removes a dependency between the include file and
>>the source.
>>
>
>Er, say what?  The macro is in the include file now...
>
I meant the include file and the C file.

-Corey


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Franz Sirl]

On Wednesday 05 December 2001 17:18, Corey Minyard wrote:
> Franz Sirl wrote:
> > Ah, I see, I only saw this problem in aty128fb. I'll add the fix to
> > the linuxconsole CVS for 2.5.x.
>
> What about 2.4?  I'm sure people will want to compile 2.4 with gcc 3.x.

That has to go thru the usual channels.

> >> * In include/linux/sunrpc/clnt.h, I removed a bogus function declaration
> >> which was messing up inlining.
> >
> > I guess this is 3.1 specific? I don't remember problems with 3.0.x.
>
> Probably.  I've seen some other problems with GCC being fairly picky
> about declarations, and I think it's fairly new.  But the declaration
> both wrong and unnecessary.

Ah yes, I browsed this discussion on the lists.

> > What about the FAT filesystem? Is gcc-3.1 now able to correctly
> > optimize the 64bit signed divide by const into a ASHIFT+fixup?
>
> Nope.  I was going to ask about that one.  Do you have a GCC PR on this?

Nope, probably I should add one, cause I don't have time to continue with a
divdi3_32 pattern anytime soon :-(.

Franz.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: Changes to PPC Linux required for GCC 3.1

[Corey Minyard]

Franz Sirl wrote:

>On Wednesday 05 December 2001 17:18, Corey Minyard wrote:
>
>>Franz Sirl wrote:
>>
>>>Ah, I see, I only saw this problem in aty128fb. I'll add the fix to
>>>the linuxconsole CVS for 2.5.x.
>>>
>>What about 2.4?  I'm sure people will want to compile 2.4 with gcc 3.x.
>>
>
>That has to go thru the usual channels.
>
And that is ....?

>
>Nope, probably I should add one, cause I don't have time to continue with a
>divdi3_32 pattern anytime soon :-(.
>
It would be pretty easy to copy it from libgcc2.  You don't want to do
this by hand, it's big and nasty in C, in assembly it would be a
nightmare.  You would have to do some license massaging, though, because
libgcc2.c is GPL with special provisions.  I can look at gcc, but it's
hard to tell how long something like that takes to find.

-Corey


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

who loads argc in elf binary???????

[Alexandre Nikolaev]

Hi!

We are trying montavista kernel .4 on G4. Upon starting of ELF binary,
the r3, which should contain argc, always reads 0 (for any program). r4
is ok.
What could be the problem?
Who is responsible for loading r3?

I would really appreciate if someone can help!

Alex.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: who loads argc in elf binary???????

[Daniel Jacobowitz]

On Tue, Mar 06, 2001 at 11:03:15AM -0500, Alexandre Nikolaev wrote:
>
> Hi!
>
> We are trying montavista kernel .4 on G4. Upon starting of ELF binary,
> the r3, which should contain argc, always reads 0 (for any program). r4
> is ok.
> What could be the problem?
> Who is responsible for loading r3?
>
> I would really appreciate if someone can help!

argc and argv are created by the kernel, based on what is given in
exec().  It has to go through the dynamic loader and any start code
before it gets to main, though.  Are you using any custom crt* code, or
otherwise linking oddly?  If so, look there.

I also seem to recall that the arguments are loaded into registers by
the application, off the stack.  I'm not entirely sure of that, though.

--
Daniel Jacobowitz                           Debian GNU/Linux Developer
Monta Vista Software                              Debian Security Team
                         "I am croutons!"

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: who loads argc in elf binary???????

[David Edelsohn]

	I believe that glibc (including the ld.so dynamic linker) extract
the arguments and place them into registers before calling main().

	For instance, glibc sysdeps/unix/sysv/linux/powerpc/dl-sysdep.c
defines a macro called

DL_FIND_ARG_COMPONENTS(cookie, argc, argv, envp, auxp)

which is used by glibc to extract argc/argv/envp from the auxilliary
argument block.

David

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/