[Cbe-oss-dev] [PATCH 1/1] Fix another user-visible SPU coredump bug

[Michael Ellerman]

On Mon, 2007-08-13 at 09:34 -0400, John DelSignore wrote:
> Hi Michael,
> 
> Thanks much for pro-actively fixing this problem. I had noticed this
> myself, but I have not gotten to the point in porting our debugger
> where it matters, so I hadn't reported it yet.

Hi John,

No worries on that front. I'm glad you noticed it though, I hate coding
in a vacuum, it's good to have someone actually using this stuff :)

> Two things:
> 
> 1) In order to provide compatibility with old broken core files and
> the new working core files, I'd like to know how the various fields
> were/are justified in the note. For example, for lslr a nominally
> 4-byte register was placed in 11 bytes and will now be placed in 8
> bytes. Which 4 bytes of the 11 or 8 byte note hold the value? lslr is
> easy to figure out by inspection of the bits because lslr is normally
> 0x3ffff, but some of the other fields it's harder to figure out where
> the value lives. Is there some rule I can use to figure out where the
> value lives in the note, possibly as a function of the note's data
> length?

Yep, understood. Regardless of the register size, all the values are
handled inside the kernel as u64 (ie. 8 bytes). For a 16 bit register
that means you'll end up with the high 6 bytes empty, ie. zero. And when
it's written to the core file you'll get all 8 bytes, but with 6 zero
bytes first.

If you look at the patch, the old code was allocating too much space for
lslr, decr, decr_status, and object-id. So in old core files these will
all occupy the first 8 bytes of the field size in the core file. The
remaining bytes will be zeroes.

The old code was not allocating enough space for signal(1|2)_type, it
only said 2 bytes when they're actually 8. So in old core files you're
only getting the two high bytes, which is no good to you.

I should add, the values are always 4-byte aligned, so you might get
some leading zeroes. I take it that's part of the ELF spec though so you
should be used to that.

It's kind of an implementation detail that we're exporting those values
as u64s, so we might change that one day - but if so we'd obviously
update the elf note sizes accordingly, so it should be a nop.

> 2) A while back there was a discussion about the absence of npc in the
> core file, and the final consensus was that the npc should be written
> to the core file. It was suggested that I generate a patch to include
> npc in a core file and submit it. But, I'm not familiar enough with
> the kernel to make such a change, and I was hoping that someone else,
> possibly you, could make that change. Is this something you'd be
> willing to do?

OK, I found the discussion in the archives. Sounds like it's fairly
uncontroversial, and it's a pretty easy patch so I'll put it on my TODO
list.

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/cbe-oss-dev/attachments/20070816/f36188ca/attachment.pgp>