[PATCH] add Altivec/VMX state to coredumps
michael at ellerman.id.au
Fri Sep 28 09:54:34 EST 2007
On Thu, 2007-09-27 at 05:10 -0500, Kumar Gala wrote:
> >>> 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.
> 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.
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 4482a06..7c8a145 100644
@@ -1624,7 +1624,7 @@ static int elf_core_dump(long signr, struct pt_regs *regs,
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);
fs = get_fs();
OzLabs, IBM Australia Development Lab
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
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the Linuxppc-dev