[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