[libvirt] [PATCH] maint: increase stack frame size limit

[Roman Bogorodskiy]

  Roman Bogorodskiy wrote:

>   Eric Blake wrote:
> 
> > On 05/08/2015 12:23 AM, Roman Bogorodskiy wrote:
> > >   Roman Bogorodskiy wrote:
> > > 
> > >>   Roman Bogorodskiy wrote:
> > >>
> > >>> Currently the stack frame size limit is set to 4096 and it started to
> > >>> cause an error like this:
> > >>>
> > >>> virshtest.c:253:1: error: stack frame size of 5512 bytes in function
> > >>> 'mymain' [-Werror,-Wframe-larger-than=]
> > >>> mymain(void)
> > >>> ^
> > >>> 1 error generated.
> > >>>
> > >>> Increase it to 6144.
> > >>
> > >> Worth to mention that it's started to show up after updating to clang
> > >> 3.6.
> > > 
> > > Any comments on this?
> > 
> > Have you reported a possible clang regression bug to the clang folks?
> > Or is the new clang version the first one to support what was originally
> > only gcc's -Wframe-larger-than?  At any rate, why does clang require a
> > larger stack than gcc?  It sounds like in addition to fixing the
> > virshtest.c file to quit stack-allocating such a large amount of space,
> > that you should also be letting the clang compiler folks know about
> > their weakness.
> 
> I wasn't absolutely sure that it is a clang problem. However, I did a
> check now on the same libvirt revision and on the same system with
> different clang versions and figured out that things work fine with:
> 
> clang version 3.4.2 (tags/RELEASE_34/dot2-final)
> 
> but start breaking on:
> 
> clang version 3.5.2 (tags/RELEASE_352/final)
> 
> So it indeed makes sense to ask clang developers what's going on; will
> do that.
> 
> I'll also try to figure out how to rewrite virshtest.c to quite
> stack-allocation.
> 
> Thanks for the feedback!

I've been playing with virshtest and then figured out that there are
other tests using the similar scheme (sockettest for example, and many
others). I came to a conclusion that rewriting tests doesn't worth an
effort, at least at this point.

In the meantime, I've posted a question on the clang mailing list:

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2015-May/042890.html

Hopefully it'll help to understand why clang behaves this way.

Roman Bogorodskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150509/461f714e/attachment-0001.sig>