This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ____longjmp_chk for ARM


On Sun, 2009-05-17 at 23:38 +0000, Joseph S. Myers wrote:
> On Mon, 18 May 2009, Andreas Schwab wrote:
> 
> > "Joseph S. Myers" <joseph@codesourcery.com> writes:
> > 
> > > +#define CHECK_SP(reg)				\
> > > +	cmp	sp, reg;				\
> > > +	ble	.Lok;				\
> > > +	CALL_FAIL				\
> > > +.Lok:
> > 
> > This is a signed compare, isn't it?  Shouldn't that rather be an
> > unsigned compare?
> 
> If the stack or any object crosses the 0x80000000 or 0x00000000 boundaries 
> such that the difference matters, I'd expect much more breakage.

What sort of breakage were you thinking of?  Crossing the 0x00000000
boundary is fairly unlikely to happen in practice but there's no
particular reason why crossing the 0x80000000 boundary either can't
happen (nothing in either the kernel or libc takes special measures to
avoid mapping things near there) or would be inherently unworkable.  

Aside from accidental usage of signed arithmetic on addresses, as here,
I can't think of anything much that would be likely to cause a problem.

p.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]