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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
