On Monday 19 January 2004 03:05 pm, Jamin W. Collins wrote: > On Thu, Jan 15, 2004 at 07:14:45PM -0800, David Mosberger wrote: > > >>>>> On Thu, 15 Jan 2004 19:35:19 -0800, Richard Harke > > >>>>> <[EMAIL PROTECTED]> said: > > > > Richard> On Thursday 15 January 2004 05:06 pm, David Mosberger > > > > Richard> wrote: > > >> >>>>> On Thu, 15 Jan 2004 17:58:27 -0800, Richard Harke >>>>> > > >> > > >> <[EMAIL PROTECTED]> said: > > > > Richard> Then if the user goes off the end of the stack, there is a > > Richard> page fault and the system has the possiblity to extend the > > Richard> stack. On the ia64, this hardly seems feasible. > > > > >> Just initialize ar.bsp==sp. The stacks will then grow > > >> "outwards". You'll need two guard areas, but that's the extent > > >> of it. > > > > Richard> But then why was the current scheme chosen for linix-ia64? > > > > ia64 linux doesn't enforce a particular policy. You can do in > > user-level whatever you like. The main thread of a new process gets > > setup such that the stacks grow towards each other because it fits > > well with RLIMIT_STACK and because it allows the available stack space > > to be shared between register backing store and memory stack. It is > > often the case that programs that are register backing store intensive > > are less memory-stack intensive and vice versa. > > So, what would the proper fix for the libpth problem on ia64 be?
I believe the diff file I sent represents a proper fix. The discussion above is about what could be done but it is not what libpth does. libpth does not create a "guard segment" for the thread stacks on any architecture. libpth does attempt to detect stack overrun on thread switch and the change I made for ia64 is consistent with that. Richard
