[PATCH] add Altivec/VMX state to coredumps

Kumar Gala galak at kernel.crashing.org
Wed Sep 26 13:56:58 EST 2007


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



More information about the Linuxppc-dev mailing list