Roman Bogorodskiy wrote: > 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. I've got a reply that implies that it's expected behavior for -O0. Unfortunately, once it's replaced with -O1 or higher optimization levels, it triggers the function inlining problem that prevents proper mocking. Frankly, these all make using clang for libvirt development quite onerous and I'm not sure if it makes sense trying to fix it rather than using gcc. Roman Bogorodskiy
Attachment:
pgpw5p5Ql5NFo.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list