PPC64 core-file GP register formats/order

PPC64 core-file GP register formats/order

[Phil Muldoon]

I'm not sure what to do, but I cannot find the expectations of register 
order in a core file for PPC64. On other architectures the order is 
defined in:

struct user_regs_struct
{..structure defined here...}

in /usr/include/asm/user.h

in x86, and on x86_64:

asm-i386/    asm-x86_64/

Depending on how that box is configured.

The only contents of user.h on a PPC64 box in Toronto contains:

#ifndef _ASM_POWERPC_USER_H
#define _ASM_POWERPC_USER_H
#endif  /* _ASM_POWERPC_USER_H */

I tried to backward engineer the order with gcore and kernel on ppc64, 
but both of those either do not write notes, or eu-readelf cannot 
understand them as the output is:

Note segment of 2060 bytes at offset 0x2b4:
  Owner          Data size  Type
  CORE                 268  PRSTATUS
  CORE                 128  PRPSINFO

That is basically no note data at all (or that can be understood).

Using the order as defined in struct user_regs_struct, I now 
successfully dump prstatus with general register data on each thread in 
the core file notes. PPC64 is being blocked by this. Hopefully I am just 
not looking in the correct places, and this can be easily solved.

Any ideas?

Regards

Phil

Re: PPC64 core-file GP register formats/order

[Yong Zheng]

On Sun, 2006-10-22 at 20:38 -0500, Phil Muldoon wrote: 
> I'm not sure what to do, but I cannot find the expectations of register 
> order in a core file for PPC64. On other architectures the order is 
> defined in:
> 
> struct user_regs_struct
> {..structure defined here...}
> 
> in /usr/include/asm/user.h
> 
> in x86, and on x86_64:
> 
> asm-i386/    asm-x86_64/
> 
> Depending on how that box is configured.
> 
> The only contents of user.h on a PPC64 box in Toronto contains:
> 
> #ifndef _ASM_POWERPC_USER_H
> #define _ASM_POWERPC_USER_H
> #endif  /* _ASM_POWERPC_USER_H */
> 


IMO, the PRSTATUS data struct is defined by the struct elf_prstatus in
<linux/elfcore.h>, right?(I think it's right, you know kernel dumps core
file according <linux/elfcore.h>, so we should take the same struct as
kernel does). Then the attribute "elf_gregset_t pr_reg" is referred in
the struct elf_prstatus.

On x86/x86_64, the "elf_gregset_t pr_reg" is defined by the struct
"struct user_regs_struct" in <asm-i386/user.h> or <asm-x86_64/user.h>.
We should dump out the registers according to the "struct
user_regs_struct". This is ok, you must have done this. :-)

Unfortunately in the <asm-ppc64/user.h> on PPC64, no one struct like
"struct user_regs_struct" is defined. So this will bring us some
troubles when dumping. 

Let go back to read the <linux/elfcore.h>. On PPC/PPC64, the struct
"elf_gregset_t" is defined as one unsigned long array with the size of
48 in <asm-ppc64/elf.h> or <asm-ppc/elf.h>. And about each member in the
array is defined in <asm-ppc/ptrace.h> or <asm-ppc64/ptrace.h>, for
example, the array[0] is the NO.0 general purpose register(i.e. gpr0). I
think we should take this order to dump out the attribute "elf_gregset_t
pr_reg" of PRSTATUS.

Now the question becomes how to get the above 48 registers' value on
PPC64. (I'm not sure how you get the similar value on X86/X86_64. We
guess you get them by getRegisterBankBuffers() in ISA.java. :-)). If you
get them by getRegisterBankBuffers() in ISA.java, it will more easier
for us to get the same registerBankBuffer on PPC64.So, if the code works
well on X86/X86_64, please check them in. And we will do some
modifications for PPC64.


> I tried to backward engineer the order with gcore and kernel on ppc64, 
> but both of those either do not write notes, or eu-readelf cannot 
> understand them as the output is:
> 
> Note segment of 2060 bytes at offset 0x2b4:
>   Owner          Data size  Type
>   CORE                 268  PRSTATUS
>   CORE                 128  PRPSINFO
> 
> That is basically no note data at all (or that can be understood).
> 

I do one test for kernel' core dump file on PPC64. THe tool "en-readelf" cannot 
recogonize the PRSTATUS's detailed information, it just shows some general info like the above.
I think this may be the bug in en-readelf on PPC64.

Best regards
Yong Zheng

Re: PPC64 core-file GP register formats/order

[Phil Muldoon]

Yon Zheng wrote:
> On Sun, 2006-10-22 at 20:38 -0500, Phil Muldoon wrote: 
>   
>> I'm not sure what to do, but I cannot find the expectations of register 
>> order in a core file for PPC64. On other architectures the order is 
>> defined in:
>>
>> struct user_regs_struct
>> {..structure defined here...}
>>
>> in /usr/include/asm/user.h
>>
>> in x86, and on x86_64:
>>
>> asm-i386/    asm-x86_64/
>>
>> Depending on how that box is configured.
>>
>> The only contents of user.h on a PPC64 box in Toronto contains:
>>
>> #ifndef _ASM_POWERPC_USER_H
>> #define _ASM_POWERPC_USER_H
>> #endif  /* _ASM_POWERPC_USER_H */
>>
>>     
>
>
> IMO, the PRSTATUS data struct is defined by the struct elf_prstatus in
> <linux/elfcore.h>, right?(I think it's right, you know kernel dumps core
> file according <linux/elfcore.h>, so we should take the same struct as
> kernel does). Then the attribute "elf_gregset_t pr_reg" is referred in
> the struct elf_prstatus.
>   

That is how it is done at the moemt ;).
> On x86/x86_64, the "elf_gregset_t pr_reg" is defined by the struct
> "struct user_regs_struct" in <asm-i386/user.h> or <asm-x86_64/user.h>.
> We should dump out the registers according to the "struct
> user_regs_struct". This is ok, you must have done this. :-)
>
>   
Yep.
> Unfortunately in the <asm-ppc64/user.h> on PPC64, no one struct like
> "struct user_regs_struct" is defined. So this will bring us some
> troubles when dumping. 
>
>   

:(
> Let go back to read the <linux/elfcore.h>. On PPC/PPC64, the struct
> "elf_gregset_t" is defined as one unsigned long array with the size of
> 48 in <asm-ppc64/elf.h> or <asm-ppc/elf.h>. And about each member in the
> array is defined in <asm-ppc/ptrace.h> or <asm-ppc64/ptrace.h>, for
> example, the array[0] is the NO.0 general purpose register(i.e. gpr0). I
> think we should take this order to dump out the attribute "elf_gregset_t
> pr_reg" of PRSTATUS.
>
> Now the question becomes how to get the above 48 registers' value on
> PPC64. (I'm not sure how you get the similar value on X86/X86_64. We
> guess you get them by getRegisterBankBuffers() in ISA.java. :-)). If you
> get them by getRegisterBankBuffers() in ISA.java, it will more easier
> for us to get the same registerBankBuffer on PPC64.So, if the code works
> well on X86/X86_64, please check them in. And we will do some
> modifications for PPC64.
>   

I look at the struct in user.h and look for the order there, then I 
simply call the registerByName on the register order defined there. So 
on i386 the registers needed in order are:

ebx, ecx, edx, {...}

These are not the actual order reported by the register Iterator. But 
that does not matter as long as I know the order, as I can call 
getRegisterByName to mix the order up as much as needed. So all is 
needed is the register order to dump to core, and then I will define a 
map -> getRegisterByName() that will dump the order correctly.

Regards

Phil
>
>   
>> I tried to backward engineer the order with gcore and kernel on ppc64, 
>> but both of those either do not write notes, or eu-readelf cannot 
>> understand them as the output is:
>>
>> Note segment of 2060 bytes at offset 0x2b4:
>>   Owner          Data size  Type
>>   CORE                 268  PRSTATUS
>>   CORE                 128  PRPSINFO
>>
>> That is basically no note data at all (or that can be understood).
>>
>>     
>
> I do one test for kernel' core dump file on PPC64. THe tool "en-readelf" cannot 
> recogonize the PRSTATUS's detailed information, it just shows some general info like the above.
> I think this may be the bug in en-readelf on PPC64.
>
> Best regards
> Yong Zheng
>
>   

Re: PPC64 core-file GP register formats/order

[Roland McGrath]

> I'm not sure what to do, but I cannot find the expectations of register 
> order in a core file for PPC64. On other architectures the order is 
> defined in:
> 
> struct user_regs_struct

Ha!  Your optimism is quaint, dear fellow.  That might be true on as many
as three or four architectures.  But that amount of consistency was only
there to fool you into a false sense of security.

eu-readelf only has a tiny bit of core note format printing support,
in fact only for i386 and x86_64.

I'm not really sure what to tell you as the general answer to find this
info.  I read the kernel source, but it's not so consistently written
across different architectures that you can necessarily answer the question
with the kernel source unless you are very familiar with reading it.

For all the architectures you probably care about, it so happens I've
already bothered to know, at least for one moment in the recent past.
The core file note formats are the basis for the machine-specific
"regset" format layouts in the utrace kernel interfaces.  I've had to
recapitulate those layouts when writing format compatibility code in
the userland test harness intended for developing modules based on
utrace (the "ntrace" tarball in http://redhat.com/~roland/utrace/).

For powerpc the elf_gregset_t format (sys/procfs.h) matches
this kernel data structure (asm-powerpc/ptrace.h):

struct pt_regs {
	unsigned long gpr[32];
	unsigned long nip;
	unsigned long msr;
	unsigned long orig_gpr3;	/* Used for restarting system calls */
	unsigned long ctr;
	unsigned long link;
	unsigned long xer;
	unsigned long ccr;
#ifdef __powerpc64__
	unsigned long softe;		/* Soft enabled/disabled */
#else
	unsigned long mq;		/* 601 only (not used at present) */
					/* Used on APUS to hold IPL value. */
#endif
	unsigned long trap;		/* Reason for being here */
	/* N.B. for critical exceptions on 4xx, the dar and dsisr
	   fields are overloaded to hold srr0 and srr1. */
	unsigned long dar;		/* Fault registers */
	unsigned long dsisr;		/* on 4xx/Book-E used for ESR */
	unsigned long result;		/* Result of a system call */
};

Re: PPC64 core-file GP register formats/order

[Wu Zhou]

Roland McGrath wrote:
>> I'm not sure what to do, but I cannot find the expectations of register 
>> order in a core file for PPC64. On other architectures the order is 
>> defined in:
>>
>> struct user_regs_struct
> 
> Ha!  Your optimism is quaint, dear fellow.  That might be true on as many
> as three or four architectures.  But that amount of consistency was only
> there to fool you into a false sense of security.

I guess gregset_t, which is defined in /usr/include/sys/ucontext.h as below, is the general answer.

  /* Type for general register.  */
typedef long int greg_t;

/* Number of general registers.  */
#define NGREG   23

/* Container for all general registers.  */
typedef greg_t gregset_t[NGREG];

On x86 and x86_64, an array to define the number of each register is followed:

#ifdef __USE_GNU
/* Number of each register in the `gregset_t' array.  */
enum
{
   REG_R8 = 0,
# define REG_R8         REG_R8
   REG_R9,
# define REG_R9         REG_R9
   REG_R10,
# define REG_R10        REG_R10
   REG_R11,
# define REG_R11        REG_R11
......

But on ppc64, there is no such an array in /usr/include/sys/ucontext.h.

> eu-readelf only has a tiny bit of core note format printing support,
> in fact only for i386 and x86_64.
> 
> I'm not really sure what to tell you as the general answer to find this
> info.  I read the kernel source, but it's not so consistently written
> across different architectures that you can necessarily answer the question
> with the kernel source unless you are very familiar with reading it.
> 
> For all the architectures you probably care about, it so happens I've
> already bothered to know, at least for one moment in the recent past.
> The core file note formats are the basis for the machine-specific
> "regset" format layouts in the utrace kernel interfaces.  I've had to
> recapitulate those layouts when writing format compatibility code in
> the userland test harness intended for developing modules based on
> utrace (the "ntrace" tarball in http://redhat.com/~roland/utrace/).
> 
> For powerpc the elf_gregset_t format (sys/procfs.h) matches
> this kernel data structure (asm-powerpc/ptrace.h):
> 
> struct pt_regs {
> 	unsigned long gpr[32];
> 	unsigned long nip;
> 	unsigned long msr;
> 	unsigned long orig_gpr3;	/* Used for restarting system calls */
> 	unsigned long ctr;
> 	unsigned long link;
> 	unsigned long xer;
> 	unsigned long ccr;
> #ifdef __powerpc64__
> 	unsigned long softe;		/* Soft enabled/disabled */
> #else
> 	unsigned long mq;		/* 601 only (not used at present) */
> 					/* Used on APUS to hold IPL value. */
> #endif
> 	unsigned long trap;		/* Reason for being here */
> 	/* N.B. for critical exceptions on 4xx, the dar and dsisr
> 	   fields are overloaded to hold srr0 and srr1. */
> 	unsigned long dar;		/* Fault registers */
> 	unsigned long dsisr;		/* on 4xx/Book-E used for ESR */
> 	unsigned long result;		/* Result of a system call */
> };
> 

Same-named struct also exist in the system header file: /usr/include/asm-ppc64/ptrace.h, but there 
are two structures: one for 32-bit program, the other for 64-bit program:

#define PPC_REG unsigned long
struct pt_regs {
         PPC_REG gpr[32];
         PPC_REG nip;
         PPC_REG msr;
         PPC_REG orig_gpr3;      /* Used for restarting system calls */
         PPC_REG ctr;
         PPC_REG link;
         PPC_REG xer;
         PPC_REG ccr;
         PPC_REG softe;          /* Soft enabled/disabled */
         PPC_REG trap;           /* Reason for being here */
         PPC_REG dar;            /* Fault registers */
         PPC_REG dsisr;
         PPC_REG result;         /* Result of a system call */
};

#define PPC_REG_32 unsigned int
struct pt_regs32 {
         PPC_REG_32 gpr[32];
         PPC_REG_32 nip;
         PPC_REG_32 msr;
         PPC_REG_32 orig_gpr3;   /* Used for restarting system calls */
         PPC_REG_32 ctr;
         PPC_REG_32 link;
         PPC_REG_32 xer;
         PPC_REG_32 ccr;
         PPC_REG_32 mq;          /* 601 only (not used at present) */
                                 /* Used on APUS to hold IPL value. */
         PPC_REG_32 trap;                /* Reason for being here */
         PPC_REG_32 dar;         /* Fault registers */
         PPC_REG_32 dsisr;
         PPC_REG_32 result;      /* Result of a system call */
};

It looks the same as the kernel strucuture.

Though, there is one problem confusing me all the time: why asm-powerpc replace asm-ppc64 in the kernel?

Regards
- Wu Zhou

Re: PPC64 core-file GP register formats/order

[Roland McGrath]

> I guess gregset_t, which is defined in /usr/include/sys/ucontext.h as below, is the general answer.

No, do not assume that is the same as elf_gregset_t on all platforms.

> Though, there is one problem confusing me all the time: why asm-powerpc
> replace asm-ppc64 in the kernel?

Newer kernels unify the former asm-ppc32 and asm-ppc64 into asm-powerpc.

Compiling failed for ElfPrstatus.cxx file on x86-64.

[Yong Zheng]

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

Phil,

The compiling based on the cvs-head(10-23) fails for the
frysk/lib/elf/cni/ElfPrstatus.cxx on X86_64. The compiler cannot find
the "u64" and "u32" type definition, which are introduced from
<asm/elf.h>.

I give one small patch, but I think it's not a good fix. :-)

Best regards
Yong Zheng

[-- Attachment #2: frysk-fcore-header.1023.patch --]
[-- Type: text/x-patch, Size: 681 bytes --]

Index: frysk-imports/lib/elf/cni/ElfPrstatus.cxx
===================================================================
RCS file: /cvs/frysk/frysk-imports/lib/elf/cni/ElfPrstatus.cxx,v
retrieving revision 1.1
diff -u -r1.1 ElfPrstatus.cxx
--- frysk-imports/lib/elf/cni/ElfPrstatus.cxx	23 Oct 2006 00:20:58 -0000	1.1
+++ frysk-imports/lib/elf/cni/ElfPrstatus.cxx	23 Oct 2006 12:01:14 -0000
@@ -43,9 +43,16 @@
 #include <stdio.h>
 #include <stdint.h>
 
+#include <asm/types.h>
+#ifdef __x86_64__
+typedef __u64 u64;
+typedef __u32 u32;
+#endif
+
 #include "lib/elf/ElfPrstatus.h"
 #include "asm/elf.h"
 
+
 using namespace std;
 using namespace java::lang;
 using namespace java::util;

Re: Compiling failed for ElfPrstatus.cxx file on x86-64.

[Phil Muldoon]

This is very strange as I did a test build on frysk64.hsv.redhat.com 
before I committed.

However I'll add your patch, just to make sure for now, it will compile.

Regards

Phil

Yong Zheng wrote:
> Phil,
>
> The compiling based on the cvs-head(10-23) fails for the
> frysk/lib/elf/cni/ElfPrstatus.cxx on X86_64. The compiler cannot find
> the "u64" and "u32" type definition, which are introduced from
> <asm/elf.h>.
>
> I give one small patch, but I think it's not a good fix. :-)
>
> Best regards
> Yong Zheng
>   
> ------------------------------------------------------------------------
>
> Index: frysk-imports/lib/elf/cni/ElfPrstatus.cxx
> ===================================================================
> RCS file: /cvs/frysk/frysk-imports/lib/elf/cni/ElfPrstatus.cxx,v
> retrieving revision 1.1
> diff -u -r1.1 ElfPrstatus.cxx
> --- frysk-imports/lib/elf/cni/ElfPrstatus.cxx	23 Oct 2006 00:20:58 -0000	1.1
> +++ frysk-imports/lib/elf/cni/ElfPrstatus.cxx	23 Oct 2006 12:01:14 -0000
> @@ -43,9 +43,16 @@
>  #include <stdio.h>
>  #include <stdint.h>
>  
> +#include <asm/types.h>
> +#ifdef __x86_64__
> +typedef __u64 u64;
> +typedef __u32 u32;
> +#endif
> +
>  #include "lib/elf/ElfPrstatus.h"
>  #include "asm/elf.h"
>  
> +
>  using namespace std;
>  using namespace java::lang;
>  using namespace java::util;
>   

Re: PPC64 core-file GP register formats/order

[Phil Muldoon]

Roland McGrath wrote:
>> I'm not sure what to do, but I cannot find the expectations of register 
>> order in a core file for PPC64. On other architectures the order is 
>> defined in:
>>
>> struct user_regs_struct
>>     
>
> Ha!  Your optimism is quaint, dear fellow.  That might be true on as many
> as three or four architectures.  But that amount of consistency was only
> there to fool you into a false sense of security.
>
> eu-readelf only has a tiny bit of core note format printing support,
> in fact only for i386 and x86_64.
>
> I'm not really sure what to tell you as the general answer to find this
> info.  I read the kernel source, but it's not so consistently written
> across different architectures that you can necessarily answer the question
> with the kernel source unless you are very familiar with reading it.
>   
Ah well optimism is good until proven otherwise ;) I did grok the kernel 
code but as you mention, my experience was what happens on arch foo 
might happen in a different place (and time) on arch bar.
> For all the architectures you probably care about, it so happens I've
> already bothered to know, at least for one moment in the recent past.
> The core file note formats are the basis for the machine-specific
> "regset" format layouts in the utrace kernel interfaces.  I've had to
> recapitulate those layouts when writing format compatibility code in
> the userland test harness intended for developing modules based on
> utrace (the "ntrace" tarball in http://redhat.com/~roland/utrace/).
>
>   

As it turns out Yong put the ppc register format in last night, so all 
is good. Thanks for the utrace tarball link though, that will be very 
useful in days to come

Regards

Phil