Hi,
On Wed, 15 Nov 2006, David Mosberger-Tang wrote:
> As described on page 66, the .mem.offset is unrelated to unwind info
> (it's just a hint to the assembler so it doesn't issue false warnings).
> Starting on page 35, the manual describes the unwind directives. As
> described there, "save.g 0x1" gets translated into a gr_mem unwind
> descriptor.
Thanks for the references, I'm still trying to wrap my head around them
:-)
> Looking at that manual, ".save.g 0x1" basically means that register r4
> gets spilled/saved during the function's prologue. The save-location is
> implicit
Because how the spill area layout is defined? I now indeed see that bit 0
of format P6 (used for the gr_mem descriptor) corresponds to r4. Okay, so
that seems okay. But then I wonder why the spill of r1 is not somehow
marked with .save.g (or any other unwind directive). That also isn't done
for the other prologues so I assume it's okay, but I'm nevertheless
wondering (perhaps it's implicitely saved?). I.e. the whole prologue of
the doit function (until the last GR save) looks like so:
.prologue 2, 119
alloc r16 = ar.pfs, 8, 80, 8, 0
adds r17 = -368, r12
adds r18 = -360, r12
.vframe r119
mov r119 = r12
adds r12 = -592, r12
mov r19 = ar.unat
;;
.savepsp ar.unat, 368
st8 [r17] = r19, 16
.savepsp ar.pfs, 360
st8 [r18] = r16, 16
;;
.mem.offset 352, 0
st8.spill [r17] = r1, 16
.save.g 0x1
.mem.offset 344, 0
st8.spill [r18] = r4, 16
;;
.save.g 0x2
.mem.offset 336, 0
st8.spill [r17] = r5, 16
.save.g 0x4
.mem.offset 328, 0
st8.spill [r18] = r6, 16
;;
.save.g 0x8
.mem.offset 320, 0
st8.spill [r17] = r7, 16
mov r20 = b0
;;
.savepsp rp, 312
st8 [r18] = r20, 24
This seems to be okay to me so far, at least assuming that the initial
offsets for r17/18 are correct, i.e. that the start of that spill area is
indeed supposed to be at r12 - 368 (or actually r12-368+16, or? because
ar.unat and ar.pfs are stored first). I've read that the high end of it
is required to be 16byte aligned. Overall in that prologue there are
8 GRs saved to [r17/r18] and 20 FRs which makes it 8*8+20*16 = 384 bytes.
I've also read that the spill area overlaps 16 bytes with the callers
scratch area, so that would indeed make it need 368 additional bytes
for the spill area. I.e. from what I could gather after looking at the
Intel docs for two hours the prologue above seems to be correct. Could
change tomorrow of course after I read some more :-)
> and it appears like there is some disagreement here between
> libunwind and GCC as to what that location should be (I know there used
> to be problems in this area, though I thought they had been resolved).
> Actually, an off-by-8 error sounds a bit like it might be
> 16-byte-alignment related.
>
> Could you perhaps attach the complete assembly output to the test-case?
I've attached it to the bugreport.
> Also, what version of libunwind are you using?
The latest released (AFAIK) version: 0.98.5 .
Ciao,
Michael.
_______________________________________________
Libunwind-devel mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/libunwind-devel
