On 26.01.2007 [10:19:54 -0800], Dave Hansen wrote:
> On Thu, 2007-01-25 at 21:16 -0800, Nishanth Aravamudan wrote:
> > On 25.01.2007 [19:35:15 -0800], Dave Hansen wrote:
> > > On Thu, 2007-01-25 at 15:24 -0600, Adam Litke wrote:
> > > > Hmm. On x86, sometimes gcc will optimize out the alloca() call. This
> > > > patch fixes it up nicely. Please apply.
> > > >
> > > > Signed-off-by: Adam Litke <[EMAIL PROTECTED]>
> > > >
> > > > diff --git a/tests/stack_grow_into_huge.c b/tests/stack_grow_into_huge.c
> > > > index fc8a030..7112428 100644
> > > > --- a/tests/stack_grow_into_huge.c
> > > > +++ b/tests/stack_grow_into_huge.c
> > > > @@ -49,6 +49,7 @@ void do_child()
> > > > {
> > > > while (1) {
> > > > alloca(16*1024*1024);
> > > > + sleep(0); /* Defeat the gcc optimizer */
> > > > }
> > > > }
> > >
> > > Aren't barriers the generally accepted (kernel-style) way of doing
> > > this?
> > >
> > > #define barrier() __asm__ __volatile__("": : :"memory")
> >
> > Yes, but this isn't the kernel. Alternatively, we could probably just
> > not optimize this one testcase, if it's really gcc causing the problem.
>
> Oh, I was just saying that the kernel has a pretty good way of doing
> it. And, if you use the kernel way, your application will break only
> as often as the kernel in this regard. I can see a future compiler
> optimizing away a sleep(0), but I can't see one optimizing away a
> kernel-style barrier.
I see what you're saying now. You're right that it's a bit fragile to
rely on an extra function call to cause the alloca() loop to be
optimized out, but we've so far avoided too much assembly in the source.
If Adam thinks this is worth changing, I'll leave it up to him.
> > > Can you do it in alloca() itself?
> >
> > Well, for __GNUC__, we get:
> >
> > # define alloca(size) __builtin_alloca (size)
> >
> > And even for non-__GNUC__, the function is inlined.
> >
> > So you want us to modify a GCC builtin, or a glibc, function for a
> > simple testcase?
>
> Heh. I've never used alloca(), I thought it was a libhuge thing. Why
> don't you just distribute a custom version of glibc with libhuge?
> That should be pretty easy.
Easy indeed. Especially considering how loud Ulrich was at OLS last
year, from what I hear. I, to be honest, had never used alloca() before
either, but it's quite handy for this bug.
Thanks,
Nish
--
Nishanth Aravamudan <[EMAIL PROTECTED]>
IBM Linux Technology Center
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
