[PATCH] add Altivec/VMX state to coredumps

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 <redacted>
---
 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

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

Kumar Gala wrote:

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

quoted

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 [off-list ref]
Genesi, Manager, Developer Relations

On Tue, 2007-09-25 at 19:00 +0100, Matt Sealey wrote:

Kumar Gala wrote:

quoted

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

quoted

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.

Kumar Gala wrote:

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

quoted

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.

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

Kumar Gala wrote:

quoted

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

quoted

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

Kumar Gala wrote:

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

quoted

Kumar Gala wrote:

quoted

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

quoted

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.

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

Kumar Gala wrote:

quoted

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

quoted

Kumar Gala wrote:

quoted

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

quoted

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

On Wed, 26 Sep 2007, Kumar Gala wrote:

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

quoted

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

Benjamin Herrenschmidt wrote:

On Tue, 2007-09-25 at 19:00 +0100, Matt Sealey wrote:

quoted

Kumar Gala wrote:

quoted

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 [off-list ref]
Genesi, Manager, Developer Relations

quoted

quoted

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

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

quoted

quoted

quoted

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.

quoted

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

quoted

quoted

quoted

quoted

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.

quoted

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

Segher Boessenkool wrote:

quoted

quoted

quoted

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 [off-list ref]
Genesi, Manager, Developer Relations

On Wed, 2007-09-26 at 00:37 -0500, Kumar Gala wrote:

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

quoted

Kumar Gala wrote:

quoted

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

quoted

Kumar Gala wrote:

quoted

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

quoted

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.

quoted

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

On Wed, 2007-09-26 at 09:42 +0200, Geert Uytterhoeven wrote:

On Wed, 26 Sep 2007, Kumar Gala wrote:

quoted

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

quoted

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

quoted

quoted

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.

quoted

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

On Thu, 2007-09-27 at 05:10 -0500, Kumar Gala wrote:

quoted

quoted

quoted

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.

quoted

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