[PATCH] add Altivec/VMX state to coredumps

[Michael Ellerman]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070927/71a44759/attachment.pgp>