[PATCH] add Altivec/VMX state to coredumps

[PATCH] add Altivec/VMX state to coredumps

[Mark Nelson]

Update dump_task_altivec() (that has so far never been put to use)
so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
and VRSAVE) in the same format as the ptrace get_vrregs() and add
the appropriate glue typedefs and #defines to
include/asm-powerpc/elf.h for it to work.

Signed-off-by: Mark Nelson <markn@au1.ibm.com>
---
 arch/powerpc/kernel/process.c |   28 +++++++++++++++++++++++++---
 include/asm-powerpc/elf.h     |    7 +++++++
 2 files changed, 32 insertions(+), 3 deletions(-)

Index: linux/arch/powerpc/kernel/process.c
===================================================================
--- linux.orig/arch/powerpc/kernel/process.c
+++ linux/arch/powerpc/kernel/process.c
@@ -149,10 +149,32 @@ void flush_altivec_to_thread(struct task
 	}
 }
 
-int dump_task_altivec(struct pt_regs *regs, elf_vrregset_t *vrregs)
+int dump_task_altivec(struct task_struct *tsk, elf_vrregset_t *vrregs)
 {
-	flush_altivec_to_thread(current);
-	memcpy(vrregs, &current->thread.vr[0], sizeof(*vrregs));
+	/* ELF_NVRREG includes the VSCR and VRSAVE which we need to save
+	 * separately, see below */
+	const int nregs = ELF_NVRREG - 2;
+	elf_vrreg_t *reg;
+	u32 *dest;
+
+	if (tsk == current)
+		flush_altivec_to_thread(tsk);
+
+	reg = (elf_vrreg_t *)vrregs;
+
+	/* copy the 32 vr registers */
+	memcpy(reg, &tsk->thread.vr[0], nregs * sizeof(*reg));
+	reg += nregs;
+
+	/* copy the vscr */
+	memcpy(reg, &tsk->thread.vscr, sizeof(*reg));
+	reg++;
+
+	/* vrsave is stored in the high 32bit slot of the final 128bits */
+	memset(reg, 0, sizeof(*reg));
+	dest = (u32 *)reg;
+	*dest = tsk->thread.vrsave;
+
 	return 1;
 }
 #endif /* CONFIG_ALTIVEC */
Index: linux/include/asm-powerpc/elf.h
===================================================================
--- linux.orig/include/asm-powerpc/elf.h
+++ linux/include/asm-powerpc/elf.h
@@ -212,6 +212,13 @@ static inline int dump_task_regs(struct 
 extern int dump_task_fpu(struct task_struct *, elf_fpregset_t *); 
 #define ELF_CORE_COPY_FPREGS(tsk, elf_fpregs) dump_task_fpu(tsk, elf_fpregs)
 
+typedef elf_vrregset_t elf_fpxregset_t;
+
+#ifdef CONFIG_ALTIVEC
+extern int dump_task_altivec(struct task_struct *, elf_vrregset_t *vrregs);
+#define ELF_CORE_COPY_XFPREGS(tsk, regs) dump_task_altivec(tsk, regs)
+#endif
+
 #endif /* __KERNEL__ */
 
 /* ELF_HWCAP yields a mask that user programs can use to figure out what

Re: [PATCH] add Altivec/VMX state to coredumps

[Kumar Gala]

On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:

> Update dump_task_altivec() (that has so far never been put to use)
> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
> and VRSAVE) in the same format as the ptrace get_vrregs() and add
> the appropriate glue typedefs and #defines to
> include/asm-powerpc/elf.h for it to work.

Is there some way to tell if the core dump has altivec registers  
state in it?

I'm wondering how we distinguish a core dump w/altivec state vs one  
with SPE state.

- k

Re: [PATCH] add Altivec/VMX state to coredumps

[Matt Sealey]

Kumar Gala wrote:
> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
> 
>> Update dump_task_altivec() (that has so far never been put to use)
>> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
>> and VRSAVE) in the same format as the ptrace get_vrregs() and add
>> the appropriate glue typedefs and #defines to
>> include/asm-powerpc/elf.h for it to work.
> 
> Is there some way to tell if the core dump has altivec registers  
> state in it?
> 
> I'm wondering how we distinguish a core dump w/altivec state vs one  
> with SPE state.

Sheer number of registers saved?

Why not put the PVR in core dumps that'd make it all easier..

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: [PATCH] add Altivec/VMX state to coredumps

[Benjamin Herrenschmidt]

On Tue, 2007-09-25 at 19:00 +0100, Matt Sealey wrote:
> Kumar Gala wrote:
> > On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
> > 
> >> Update dump_task_altivec() (that has so far never been put to use)
> >> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
> >> and VRSAVE) in the same format as the ptrace get_vrregs() and add
> >> the appropriate glue typedefs and #defines to
> >> include/asm-powerpc/elf.h for it to work.
> > 
> > Is there some way to tell if the core dump has altivec registers  
> > state in it?
> > 
> > I'm wondering how we distinguish a core dump w/altivec state vs one  
> > with SPE state.
> 
> Sheer number of registers saved?
> 
> Why not put the PVR in core dumps that'd make it all easier..

PVR wouldn't be very useful...  What if you have altivec disabled ? Also
that would mean your gdb has to know about all new processors...

Ben.

Re: [PATCH] add Altivec/VMX state to coredumps

[Mark Nelson]

Kumar Gala wrote:
> 
> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
> 
>> Update dump_task_altivec() (that has so far never been put to use)
>> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
>> and VRSAVE) in the same format as the ptrace get_vrregs() and add
>> the appropriate glue typedefs and #defines to
>> include/asm-powerpc/elf.h for it to work.
> 
> Is there some way to tell if the core dump has altivec registers state
> in it?
> 
> I'm wondering how we distinguish a core dump w/altivec state vs one with
> SPE state.
> 
> - k
> 
> 

If the core dump has the Altivec registers saved in there it will have a
note called LINUX as shown below:

$ readelf -n core

Notes at offset 0x000002b4 with length 0x000005c8:
  Owner         Data size       Description
  CORE          0x0000010c      NT_PRSTATUS (prstatus structure)
  CORE          0x00000080      NT_PRPSINFO (prpsinfo structure)
  CORE          0x000000b0      NT_AUXV (auxiliary vector)
  CORE          0x00000108      NT_FPREGSET (floating point registers)
  LINUX         0x00000220      NT_PRXFPREG (user_xfpregs structure)

This mirrors what occurs with the SSE registers on i386 core dumps in
order to keep things as similar as possible.

I can't find any place where dump_spe() is called at the moment, but I
suppose if it were to be hooked up in the future it could cause confusion.
The Altivec register state in the core file is much larger than what
would be dumped by the current dump_spe(), but I'm not sure if that
matters...

There's a patch for GDB that currently reads the contents of these vector
registers from the core file, but it's being held until this patch has
been commented on and/or approved of, so if it comes to it the note name
could be changed to ALTIVEC (or something similar).


Thanks!
Mark.

Re: [PATCH] add Altivec/VMX state to coredumps

[Kumar Gala]

On Sep 25, 2007, at 8:22 PM, Mark Nelson wrote:

> Kumar Gala wrote:
>>
>> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
>>
>>> Update dump_task_altivec() (that has so far never been put to use)
>>> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
>>> and VRSAVE) in the same format as the ptrace get_vrregs() and add
>>> the appropriate glue typedefs and #defines to
>>> include/asm-powerpc/elf.h for it to work.
>>
>> Is there some way to tell if the core dump has altivec registers  
>> state
>> in it?
>>
>> I'm wondering how we distinguish a core dump w/altivec state vs  
>> one with
>> SPE state.
>>
>> - k
>>
>>
>
> If the core dump has the Altivec registers saved in there it will  
> have a
> note called LINUX as shown below:
>
> $ readelf -n core
>
> Notes at offset 0x000002b4 with length 0x000005c8:
>   Owner         Data size       Description
>   CORE          0x0000010c      NT_PRSTATUS (prstatus structure)
>   CORE          0x00000080      NT_PRPSINFO (prpsinfo structure)
>   CORE          0x000000b0      NT_AUXV (auxiliary vector)
>   CORE          0x00000108      NT_FPREGSET (floating point registers)
>   LINUX         0x00000220      NT_PRXFPREG (user_xfpregs structure)
>
> This mirrors what occurs with the SSE registers on i386 core dumps in
> order to keep things as similar as possible.
>
> I can't find any place where dump_spe() is called at the moment, but I
> suppose if it were to be hooked up in the future it could cause  
> confusion.
> The Altivec register state in the core file is much larger than what
> would be dumped by the current dump_spe(), but I'm not sure if that
> matters...
>
> There's a patch for GDB that currently reads the contents of these  
> vector
> registers from the core file, but it's being held until this patch has
> been commented on and/or approved of, so if it comes to it the note  
> name
> could be changed to ALTIVEC (or something similar).

I think we should NOT overload NT_PRXFPREG and add proper note types  
NT_ALTIVEC & NT_SPE for those register sets.

Who on the GDB side would we need to coordinate such a change with?

- k

Re: [PATCH] add Altivec/VMX state to coredumps

[Mark Nelson]

Kumar Gala wrote:
> 
> On Sep 25, 2007, at 8:22 PM, Mark Nelson wrote:
> 
>> Kumar Gala wrote:
>>>
>>> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
>>>
>>>> Update dump_task_altivec() (that has so far never been put to use)
>>>> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
>>>> and VRSAVE) in the same format as the ptrace get_vrregs() and add
>>>> the appropriate glue typedefs and #defines to
>>>> include/asm-powerpc/elf.h for it to work.
>>>
>>> Is there some way to tell if the core dump has altivec registers state
>>> in it?
>>>
>>> I'm wondering how we distinguish a core dump w/altivec state vs one with
>>> SPE state.
>>>
>>> - k
>>>
>>>
>>
>> If the core dump has the Altivec registers saved in there it will have a
>> note called LINUX as shown below:
>>
>> $ readelf -n core
>>
>> Notes at offset 0x000002b4 with length 0x000005c8:
>>   Owner         Data size       Description
>>   CORE          0x0000010c      NT_PRSTATUS (prstatus structure)
>>   CORE          0x00000080      NT_PRPSINFO (prpsinfo structure)
>>   CORE          0x000000b0      NT_AUXV (auxiliary vector)
>>   CORE          0x00000108      NT_FPREGSET (floating point registers)
>>   LINUX         0x00000220      NT_PRXFPREG (user_xfpregs structure)
>>
>> This mirrors what occurs with the SSE registers on i386 core dumps in
>> order to keep things as similar as possible.
>>
>> I can't find any place where dump_spe() is called at the moment, but I
>> suppose if it were to be hooked up in the future it could cause
>> confusion.
>> The Altivec register state in the core file is much larger than what
>> would be dumped by the current dump_spe(), but I'm not sure if that
>> matters...
>>
>> There's a patch for GDB that currently reads the contents of these vector
>> registers from the core file, but it's being held until this patch has
>> been commented on and/or approved of, so if it comes to it the note name
>> could be changed to ALTIVEC (or something similar).
> 
> I think we should NOT overload NT_PRXFPREG and add proper note types
> NT_ALTIVEC & NT_SPE for those register sets.
> 
> Who on the GDB side would we need to coordinate such a change with?
> 
> - k
> 

You're probably right :)

What cores have SPE at the moment? Also, perhaps more importantly, are there any plans to have Altivec and SPE in the same core?

I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on the GDB side of this.


Thanks!

Mark.

Re: [PATCH] add Altivec/VMX state to coredumps

[Kumar Gala]

On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:

> Kumar Gala wrote:
>>
>> On Sep 25, 2007, at 8:22 PM, Mark Nelson wrote:
>>
>>> Kumar Gala wrote:
>>>>
>>>> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
>>>>
>>>>> Update dump_task_altivec() (that has so far never been put to use)
>>>>> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
>>>>> and VRSAVE) in the same format as the ptrace get_vrregs() and add
>>>>> the appropriate glue typedefs and #defines to
>>>>> include/asm-powerpc/elf.h for it to work.
>>>>
>>>> Is there some way to tell if the core dump has altivec registers  
>>>> state
>>>> in it?
>>>>
>>>> I'm wondering how we distinguish a core dump w/altivec state vs  
>>>> one with
>>>> SPE state.
>>>>
>>>> - k
>>>>
>>>>
>>>
>>> If the core dump has the Altivec registers saved in there it will  
>>> have a
>>> note called LINUX as shown below:
>>>
>>> $ readelf -n core
>>>
>>> Notes at offset 0x000002b4 with length 0x000005c8:
>>>   Owner         Data size       Description
>>>   CORE          0x0000010c      NT_PRSTATUS (prstatus structure)
>>>   CORE          0x00000080      NT_PRPSINFO (prpsinfo structure)
>>>   CORE          0x000000b0      NT_AUXV (auxiliary vector)
>>>   CORE          0x00000108      NT_FPREGSET (floating point  
>>> registers)
>>>   LINUX         0x00000220      NT_PRXFPREG (user_xfpregs structure)
>>>
>>> This mirrors what occurs with the SSE registers on i386 core  
>>> dumps in
>>> order to keep things as similar as possible.
>>>
>>> I can't find any place where dump_spe() is called at the moment,  
>>> but I
>>> suppose if it were to be hooked up in the future it could cause
>>> confusion.
>>> The Altivec register state in the core file is much larger than what
>>> would be dumped by the current dump_spe(), but I'm not sure if that
>>> matters...
>>>
>>> There's a patch for GDB that currently reads the contents of  
>>> these vector
>>> registers from the core file, but it's being held until this  
>>> patch has
>>> been commented on and/or approved of, so if it comes to it the  
>>> note name
>>> could be changed to ALTIVEC (or something similar).
>>
>> I think we should NOT overload NT_PRXFPREG and add proper note types
>> NT_ALTIVEC & NT_SPE for those register sets.
>>
>> Who on the GDB side would we need to coordinate such a change with?
>>
>> - k
>>
>
> You're probably right :)
>
> What cores have SPE at the moment? Also, perhaps more importantly,  
> are there any plans to have Altivec and SPE in the same core?

The e500 cores's from Freescale.

No, they are pretty much mutually exclusive.

> I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on  
> the GDB side of this.

 From comments it looks like the expectation is that the combination  
of note type and name which is expected to be unique.

I'm wondering if we should handle this via  
elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().   
Does GDB care about the order it sees the various sections in?

- k

Re: [PATCH] add Altivec/VMX state to coredumps

[Geert Uytterhoeven]

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

On Wed, 26 Sep 2007, Kumar Gala wrote:
> On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:
> > What cores have SPE at the moment? Also, perhaps more importantly,  
> > are there any plans to have Altivec and SPE in the same core?
> 
> The e500 cores's from Freescale.
> 
> No, they are pretty much mutually exclusive.

Bummer, only now do I realize this thread is not about the Synergistic
Processing Elements but about the Signal Processing Extension...

With kind regards,
 
Geert Uytterhoeven
Software Architect

Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
 
Phone:    +32 (0)2 700 8453	
Fax:      +32 (0)2 700 8622	
E-mail:   Geert.Uytterhoeven@sonycom.com	
Internet: http://www.sony-europe.com/
 	
Sony Network and Software Technology Center Europe	
A division of Sony Service Centre (Europe) N.V.	
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium	
VAT BE 0413.825.160 · RPR Brussels	
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619

Re: [PATCH] add Altivec/VMX state to coredumps

[Matt Sealey]

Benjamin Herrenschmidt wrote:
> On Tue, 2007-09-25 at 19:00 +0100, Matt Sealey wrote:
>> Kumar Gala wrote:
>>> I'm wondering how we distinguish a core dump w/altivec state vs one  
>>> with SPE state.
>> Sheer number of registers saved?
>>
>> Why not put the PVR in core dumps that'd make it all easier..
> 
> PVR wouldn't be very useful...  What if you have altivec disabled ? Also
> that would mean your gdb has to know about all new processors...

Is that such a big deal? :D

Hypothetically it would be impossible to determine if you were running
on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
given the data saved. Is that a misfeature of GDB that we even have to
worry about this, or some noble plus point of a unified ISA? You decide :)

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: [PATCH] add Altivec/VMX state to coredumps

[Segher Boessenkool]

>>> Why not put the PVR in core dumps that'd make it all easier..
>>
>> PVR wouldn't be very useful...  What if you have altivec disabled ? 
>> Also
>> that would mean your gdb has to know about all new processors...
>
> Is that such a big deal? :D
>
> Hypothetically it would be impossible to determine if you were running
> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
> given the data saved.

And that is exactly as should be: a core dump represents the execution
state of a user program, it has nothing to do with the machine it was
generated on; it even is possible to restart a core dump generated on
e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE)
that the latter processor / execution environment doesn't provide.

> Is that a misfeature of GDB that we even have to
> worry about this, or some noble plus point of a unified ISA? You 
> decide :)

We don't have to worry about it :-)


Segher

Re: [PATCH] add Altivec/VMX state to coredumps

[Kumar Gala]

On Sep 26, 2007, at 8:21 AM, Segher Boessenkool wrote:

>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>
>>> PVR wouldn't be very useful...  What if you have altivec disabled ?
>>> Also
>>> that would mean your gdb has to know about all new processors...
>>
>> Is that such a big deal? :D
>>
>> Hypothetically it would be impossible to determine if you were  
>> running
>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>> given the data saved.
>
> And that is exactly as should be: a core dump represents the execution
> state of a user program, it has nothing to do with the machine it was
> generated on; it even is possible to restart a core dump generated on
> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g.,  
> SPE)
> that the latter processor / execution environment doesn't provide.
>
>> Is that a misfeature of GDB that we even have to
>> worry about this, or some noble plus point of a unified ISA? You
>> decide :)
>
> We don't have to worry about it :-)

We should worry about it.  If one misinterprets the core file you  
will get unexpected behavior.  I see no reason not to do this  
properly and mark the sections such that its clear if its AltiVec or  
SPE state, rather than overloading the x86 XFPU type.

- k

Re: [PATCH] add Altivec/VMX state to coredumps

[Segher Boessenkool]

>>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>>
>>>> PVR wouldn't be very useful...  What if you have altivec disabled ?
>>>> Also
>>>> that would mean your gdb has to know about all new processors...
>>>
>>> Is that such a big deal? :D
>>>
>>> Hypothetically it would be impossible to determine if you were 
>>> running
>>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>>> given the data saved.
>>
>> And that is exactly as should be: a core dump represents the execution
>> state of a user program, it has nothing to do with the machine it was
>> generated on; it even is possible to restart a core dump generated on
>> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., 
>> SPE)
>> that the latter processor / execution environment doesn't provide.
>>
>>> Is that a misfeature of GDB that we even have to
>>> worry about this, or some noble plus point of a unified ISA? You
>>> decide :)
>>
>> We don't have to worry about it :-)
>
> We should worry about it.  If one misinterprets the core file you will 
> get unexpected behavior.

I read this as "worry about the PVR".

> I see no reason not to do this properly and mark the sections such 
> that its clear if its AltiVec or SPE state, rather than overloading 
> the x86 XFPU type.

Yes, certainly, I thought we all agreed on that automatically :-)


Segher

Re: [PATCH] add Altivec/VMX state to coredumps

[Matt Sealey]

Segher Boessenkool wrote:
>>>> Why not put the PVR in core dumps that'd make it all easier..
>>>
>>> PVR wouldn't be very useful...  What if you have altivec disabled ? Also
>>> that would mean your gdb has to know about all new processors...
>>
>> Is that such a big deal? :D
>>
>> Hypothetically it would be impossible to determine if you were running
>> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE,
>> given the data saved.
> 
> And that is exactly as should be: a core dump represents the execution
> state of a user program, it has nothing to do with the machine it was
> generated on; it even is possible to restart a core dump generated on
> e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., SPE)
> that the latter processor / execution environment doesn't provide.

A hypothetical question for you then..

What happens if you get a core dump for a G4 app which dynamically detects
AltiVec presence (from PVR or /proc) then crashes before AltiVec is enabled
in the kernel for that task (i.e. before any vector exception) and you run
it on your G3 and it magically carries on (maybe a race condition or so)
and causes a vector exception later?

Isn't that kind of useless? Wouldn't it?

-- 
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations

Re: [PATCH] add Altivec/VMX state to coredumps

[Michael Ellerman]

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

On Wed, 2007-09-26 at 00:37 -0500, Kumar Gala wrote:
> On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:
> 
> > Kumar Gala wrote:
> >>
> >> On Sep 25, 2007, at 8:22 PM, Mark Nelson wrote:
> >>
> >>> Kumar Gala wrote:
> >>>>
> >>>> On Sep 24, 2007, at 11:03 PM, Mark Nelson wrote:
> >>>>
> >>>>> Update dump_task_altivec() (that has so far never been put to use)
> >>>>> so that it dumps the Altivec/VMX registers (VR[0] - VR[31], VSCR
> >>>>> and VRSAVE) in the same format as the ptrace get_vrregs() and add
> >>>>> the appropriate glue typedefs and #defines to
> >>>>> include/asm-powerpc/elf.h for it to work.
> >>>>
> >>>> Is there some way to tell if the core dump has altivec registers  
> >>>> state
> >>>> in it?
> >>>>
> >>>> I'm wondering how we distinguish a core dump w/altivec state vs  
> >>>> one with
> >>>> SPE state.
> >>>>
> >>>> - k
> >>>>
> >>>>
> >>>
> >>> If the core dump has the Altivec registers saved in there it will  
> >>> have a
> >>> note called LINUX as shown below:
> >>>
> >>> $ readelf -n core
> >>>
> >>> Notes at offset 0x000002b4 with length 0x000005c8:
> >>>   Owner         Data size       Description
> >>>   CORE          0x0000010c      NT_PRSTATUS (prstatus structure)
> >>>   CORE          0x00000080      NT_PRPSINFO (prpsinfo structure)
> >>>   CORE          0x000000b0      NT_AUXV (auxiliary vector)
> >>>   CORE          0x00000108      NT_FPREGSET (floating point  
> >>> registers)
> >>>   LINUX         0x00000220      NT_PRXFPREG (user_xfpregs structure)
> >>>
> >>> This mirrors what occurs with the SSE registers on i386 core  
> >>> dumps in
> >>> order to keep things as similar as possible.
> >>>
> >>> I can't find any place where dump_spe() is called at the moment,  
> >>> but I
> >>> suppose if it were to be hooked up in the future it could cause
> >>> confusion.
> >>> The Altivec register state in the core file is much larger than what
> >>> would be dumped by the current dump_spe(), but I'm not sure if that
> >>> matters...
> >>>
> >>> There's a patch for GDB that currently reads the contents of  
> >>> these vector
> >>> registers from the core file, but it's being held until this  
> >>> patch has
> >>> been commented on and/or approved of, so if it comes to it the  
> >>> note name
> >>> could be changed to ALTIVEC (or something similar).
> >>
> >> I think we should NOT overload NT_PRXFPREG and add proper note types
> >> NT_ALTIVEC & NT_SPE for those register sets.
> >>
> >> Who on the GDB side would we need to coordinate such a change with?
> >>
> >> - k
> >>
> >
> > You're probably right :)
> >
> > What cores have SPE at the moment? Also, perhaps more importantly,  
> > are there any plans to have Altivec and SPE in the same core?
> 
> The e500 cores's from Freescale.
> 
> No, they are pretty much mutually exclusive.
> 
> > I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on  
> > the GDB side of this.
> 
>  From comments it looks like the expectation is that the combination  
> of note type and name which is expected to be unique.
> 
> I'm wondering if we should handle this via  
> elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().   
> Does GDB care about the order it sees the various sections in?

I don't think those callbacks will work in this case, they're only
called for the primary thread that's doing the coredump, not for each
thread. Perhaps there's a way to adapt it though.

I think the easiest solution for now is just to make the note type a
#define and create a new value for Altivec.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] add Altivec/VMX state to coredumps

[Michael Ellerman]

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

On Wed, 2007-09-26 at 09:42 +0200, Geert Uytterhoeven wrote:
> On Wed, 26 Sep 2007, Kumar Gala wrote:
> > On Sep 25, 2007, at 11:56 PM, Mark Nelson wrote:
> > > What cores have SPE at the moment? Also, perhaps more importantly,  
> > > are there any plans to have Altivec and SPE in the same core?
> > 
> > The e500 cores's from Freescale.
> > 
> > No, they are pretty much mutually exclusive.
> 
> Bummer, only now do I realize this thread is not about the Synergistic
> Processing Elements but about the Signal Processing Extension...

Yeah, it's a bit of a downer. Luckily most of the Cell kernel code uses
SPU rather than SPE.

Happily it looks like SPU will become ambiguous if Niagara II support
lands in the kernel:
http://realworldtech.com/page.cfm?ArticleID=RWT090406012516&p=2

sigh :)

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [PATCH] add Altivec/VMX state to coredumps

[Kumar Gala]

>>> You're probably right :)
>>>
>>> What cores have SPE at the moment? Also, perhaps more importantly,
>>> are there any plans to have Altivec and SPE in the same core?
>>
>> The e500 cores's from Freescale.
>>
>> No, they are pretty much mutually exclusive.
>>
>>> I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on
>>> the GDB side of this.
>>
>>  From comments it looks like the expectation is that the combination
>> of note type and name which is expected to be unique.
>>
>> I'm wondering if we should handle this via
>> elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().
>> Does GDB care about the order it sees the various sections in?
>
> I don't think those callbacks will work in this case, they're only
> called for the primary thread that's doing the coredump, not for each
> thread. Perhaps there's a way to adapt it though.
>
> I think the easiest solution for now is just to make the note type a
> #define and create a new value for Altivec.

Oh, well.  It shouldn't be too difficult to abstract vector handler  
similar to how we do GPRs today to the core dump code.

- k

Re: [PATCH] add Altivec/VMX state to coredumps

[Michael Ellerman]

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

On Thu, 2007-09-27 at 05:10 -0500, Kumar Gala wrote:
> >>> You're probably right :)
> >>>
> >>> What cores have SPE at the moment? Also, perhaps more importantly,
> >>> are there any plans to have Altivec and SPE in the same core?
> >>
> >> The e500 cores's from Freescale.
> >>
> >> No, they are pretty much mutually exclusive.
> >>
> >>> I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on
> >>> the GDB side of this.
> >>
> >>  From comments it looks like the expectation is that the combination
> >> of note type and name which is expected to be unique.
> >>
> >> I'm wondering if we should handle this via
> >> elf_coredump_extra_notes_size() & elf_coredump_extra_notes_write().
> >> Does GDB care about the order it sees the various sections in?
> >
> > I don't think those callbacks will work in this case, they're only
> > called for the primary thread that's doing the coredump, not for each
> > thread. Perhaps there's a way to adapt it though.
> >
> > I think the easiest solution for now is just to make the note type a
> > #define and create a new value for Altivec.
> 
> Oh, well.  It shouldn't be too difficult to abstract vector handler  
> similar to how we do GPRs today to the core dump code.

I'm not sure I follow, you mean elf_core_copy_regs() ?

If so, that's basically what we've done, the problem is that as with
elf_core_copy_regs(), although the content is abstracted and overridden
by arch code, the note type is not. But making the vector note type
configurable seems easy enough.

eg:

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 4482a06..7c8a145 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, struct pt_regs *regs,
 #ifdef ELF_CORE_COPY_XFPREGS
        if (elf_core_copy_task_xfpregs(current, xfpu))
                fill_note(notes + numnote++,
-                         "LINUX", NT_PRXFPREG, sizeof(*xfpu), xfpu);
+                         "LINUX", ELF_CORE_XFPREGS_TYPE, sizeof(*xfpu), xfpu);
 #endif 
   
        fs = get_fs();


cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]