Re: Help tracking down libpth problem on ia64?

[Richard Harke <rharke@earthlink.net>]

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
> > >>>>> <rharke@earthlink.net> 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 >>>>>
> >   >>
> >   >> <rharke@earthlink.net> 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