add Altivec/VMX state to coredumps

PATCH In review Mark Nelson 7 participants 18 messages Sep 25, 2007 – Sep 27, 2007

Subsystems (3)

VFS PowerPC exec and binfmt

lore

Share & tools

lore

Mark Nelson

author

2007-09-25 04:05 UTC #0 lore raw

PATCH 1/1 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 <[email protected]>

---
 arch/powerpc/kernel/process.c |   28 +++++++++++++++++++++++++---
 include/asm-powerpc/elf.h     |    7 +++++++
 2 files changed, 32 insertions(+), 3 deletions(-)

arch/powerpc/kernel/process.c +25 -3

Index: 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 */

include/asm-powerpc/elf.h +7 -0

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

Kumar Gala

2007-09-25 12:39 UTC #1 lore raw

Quoted 5 lines · 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.

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

Matt Sealey

2007-09-25 17:58 UTC #2 lore raw

Quoted 11 lines · Kumar Gala

Quoted 5 lines · 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.
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..

Signature · 2 lines

Matt Sealey <[email protected]>
Genesi, Manager, Developer Relations

Benjamin Herrenschmidt

2007-09-25 22:20 UTC #3 lore raw

Quoted 12 lines · Matt Sealey

Quoted 11 lines · Kumar Gala
Quoted 5 lines · 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.
Is there some way to tell if the core dump has altivec registers state in it?

Quoted 6 lines

Quoted 2 lines
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.

Mark Nelson

author

2007-09-26 01:25 UTC #9 lore raw

In reply to Kumar Gala

Quoted 9 lines · Kumar Gala

Quoted 5 lines · 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.

Quoted 9 lines

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.

Kumar Gala

2007-09-26 03:57 UTC #10 lore raw

Quoted 42 lines · Mark Nelson

Quoted 9 lines · Kumar Gala
Quoted 5 lines · 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.
Quoted 9 lines
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...

Quoted 4 lines

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

Mark Nelson

author

2007-09-26 04:59 UTC #11 lore raw

Quoted 51 lines · Kumar Gala

Quoted 43 lines · Mark Nelson
Quoted 9 lines · Kumar Gala
Quoted 5 lines · 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.
Quoted 9 lines
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...
Quoted 4 lines
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).

Quoted 7 lines

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.

Kumar Gala

2007-09-26 05:39 UTC #12 lore raw

Quoted 56 lines · Mark Nelson

Quoted 55 lines · Kumar Gala
Quoted 44 lines · Mark Nelson
Quoted 9 lines · Kumar Gala
Quoted 5 lines · 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.
Quoted 9 lines
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...
Quoted 4 lines
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.

Quoted 8 lines

Quoted 4 lines
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 1 line

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

Geert Uytterhoeven

2007-09-26 07:43 UTC #13 lore raw

Quoted 7 lines · Kumar Gala

Quoted 2 lines · Mark Nelson
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:   [email protected]	
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

Matt Sealey

2007-09-26 11:03 UTC #4 lore raw

In reply to Benjamin Herrenschmidt

Quoted 9 lines · Benjamin Herrenschmidt

Quoted 5 lines · Matt Sealey
Quoted 1 line · Kumar Gala
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 :)

Signature · 2 lines

Matt Sealey <[email protected]>
Genesi, Manager, Developer Relations

Segher Boessenkool

2007-09-26 13:21 UTC #5 lore raw

Quoted 10 lines

Quoted 4 lines
Quoted 1 line
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 2 lines

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

Kumar Gala

2007-09-26 13:32 UTC #6 lore raw

Quoted 18 lines · Segher Boessenkool

Quoted 11 lines
Quoted 5 lines
Quoted 1 line
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 5 lines

Quoted 3 lines
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

Segher Boessenkool

2007-09-26 13:38 UTC #7 lore raw

Quoted 18 lines

Quoted 18 lines
Quoted 11 lines
Quoted 5 lines
Quoted 1 line
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 7 lines

Quoted 5 lines
Quoted 3 lines
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".

Quoted 1 line

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

Matt Sealey

2007-09-26 13:58 UTC #8 lore raw

In reply to Segher Boessenkool

Quoted 11 lines · Segher Boessenkool

Quoted 10 lines
Quoted 4 lines
Quoted 1 line
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.

Quoted 5 lines

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?

Signature · 2 lines

Matt Sealey <[email protected]>
Genesi, Manager, Developer Relations

Michael Ellerman

2007-09-27 02:48 UTC #15 lore raw

In reply to Kumar Gala

Quoted 83 lines · Kumar Gala

Quoted 66 lines · Mark Nelson
Quoted 65 lines · Kumar Gala
Quoted 49 lines · Mark Nelson
Quoted 13 lines · Kumar Gala
Quoted 5 lines · 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.
Is there some way to tell if the core dump has altivec registers state
in it?
Quoted 7 lines
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...
Quoted 7 lines
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?
Quoted 7 lines
Quoted 2 lines
- 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 2 lines
I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on the GDB side of this.

Quoted 6 lines

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

Signature · 8 lines

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

Michael Ellerman

2007-09-27 02:53 UTC #14 lore raw

In reply to Geert Uytterhoeven

Quoted 11 lines · Geert Uytterhoeven

Quoted 7 lines · Kumar Gala
Quoted 2 lines · Mark Nelson
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 :)

Signature · 8 lines

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

Kumar Gala

2007-09-27 10:12 UTC #16 lore raw

In reply to Michael Ellerman

Quoted 19 lines

Quoted 12 lines
Quoted 4 lines
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 2 lines
I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on the GDB side of this.
Quoted 6 lines
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?

Quoted 6 lines

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

Michael Ellerman

2007-09-27 23:54 UTC #17 lore raw

Quoted 23 lines · Kumar Gala

Quoted 23 lines
Quoted 12 lines
Quoted 4 lines
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 2 lines
I've been working with Carlos Eduardo Seo (Cc'ed on this mail) on the GDB side of this.
Quoted 6 lines
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.

Quoted 5 lines

Quoted 2 lines
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:

fs/binfmt_elf.c +1 -1

index 4482a06..7c8a145 100644
@@ -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

Signature · 8 lines

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