|
From: Julian S. <js...@ac...> - 2006-08-30 13:10:38
|
Running memcheck on SuSE 10.1 on ppc32 I got a bunch of complaints about writes below the stack pointer in lrint() in /lib/power4/libm-2.4.so. A bit of disassembly makes the problem clear: 0002c570 <lrintl@GLIBC_2.1>: 2c570: fd a0 08 1c fctiw f13,f1 2c574: d9 a1 ff f8 stfd f13,-8(r1) 2c578: 60 00 00 00 nop 2c57c: 60 00 00 00 nop 2c580: 60 00 00 00 nop 2c584: 80 61 ff fc lwz r3,-4(r1) 2c588: 4e 80 00 20 blr 2c58c: 00 00 00 00 .long 0x0 That's surely not right, is it? ppc64-linux does allow access to the 288 bytes below r1, but not ppc32-linux, right? Or do I misunderstand the ppc32-linux ELF ABI ? J |
|
From: Paul M. <pa...@sa...> - 2006-08-30 21:51:39
|
Julian Seward writes: > Running memcheck on SuSE 10.1 on ppc32 I got a bunch of complaints > about writes below the stack pointer in lrint() in /lib/power4/libm-2.4.so. > A bit of disassembly makes the problem clear: > > 0002c570 <lrintl@GLIBC_2.1>: > 2c570: fd a0 08 1c fctiw f13,f1 > 2c574: d9 a1 ff f8 stfd f13,-8(r1) > 2c578: 60 00 00 00 nop > 2c57c: 60 00 00 00 nop > 2c580: 60 00 00 00 nop > 2c584: 80 61 ff fc lwz r3,-4(r1) > 2c588: 4e 80 00 20 blr > 2c58c: 00 00 00 00 .long 0x0 > > That's surely not right, is it? ppc64-linux does allow access > to the 288 bytes below r1, but not ppc32-linux, right? Or do > I misunderstand the ppc32-linux ELF ABI ? You are correct, this code is incorrect (though it will actually work on Linux). Paul. |
|
From: Julian S. <js...@ac...> - 2006-08-30 22:46:57
|
On Wednesday 30 August 2006 22:51, Paul Mackerras wrote:
> Julian Seward writes:
> > Running memcheck on SuSE 10.1 on ppc32 I got a bunch of complaints
> > about writes below the stack pointer in lrint() in
> > /lib/power4/libm-2.4.so. A bit of disassembly makes the problem clear:
> >
> > 0002c570 <lrintl@GLIBC_2.1>:
> > 2c570: fd a0 08 1c fctiw f13,f1
> > 2c574: d9 a1 ff f8 stfd f13,-8(r1)
> > 2c578: 60 00 00 00 nop
> > 2c57c: 60 00 00 00 nop
> > 2c580: 60 00 00 00 nop
> > 2c584: 80 61 ff fc lwz r3,-4(r1)
> > 2c588: 4e 80 00 20 blr
> > 2c58c: 00 00 00 00 .long 0x0
> >
> > That's surely not right, is it? ppc64-linux does allow access
> > to the 288 bytes below r1, but not ppc32-linux, right? Or do
> > I misunderstand the ppc32-linux ELF ABI ?
>
> You are correct, this code is incorrect (though it will actually
> work on Linux).
Thanks. A clarification: when you say will-actually-work, do you mean
that
(a) it does not conform to the ABI, but will always give the right
outcome, regardless of what the what the program is doing, or
(b) it will mostly appear to work, but very occasionally will get
trashed by, or will itself trash, any signal frame(s) constructed
while the function is active
?
My understanding is (b).
J
|
|
From: Paul M. <pa...@sa...> - 2006-08-31 00:03:29
|
Julian Seward writes: > Thanks. A clarification: when you say will-actually-work, do you mean > that > > (a) it does not conform to the ABI, but will always give the right > outcome, regardless of what the what the program is doing, or > > (b) it will mostly appear to work, but very occasionally will get > trashed by, or will itself trash, any signal frame(s) constructed > while the function is active > > ? > > My understanding is (b). No, it's (a), because the kernel leaves the 224 bytes immediately below the current stack pointer untouched when creating a signal frame. We did that a long time ago because we thought we might one day want to run XCOFF programs using some sort of emulation. The kernel also allows programs to access a short distance below the current stack pointer, and will extend the stack mapping if necessary. Paul. |
|
From: Julian S. <js...@ac...> - 2006-08-31 01:24:12
|
> No, it's (a), because the kernel leaves the 224 bytes immediately > below the current stack pointer untouched when creating a signal > frame. We did that a long time ago because we thought we might one > day want to run XCOFF programs using some sort of emulation. The > kernel also allows programs to access a short distance below the > current stack pointer, and will extend the stack mapping if necessary. Uh, ok. I'll file a glibc bug report nevertheless. J |