[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH] Do not inline virNumaNodeIsAvailable



  Martin Kletzander wrote:

> On Tue, Mar 10, 2015 at 02:27:44PM +0100, Ján Tomko wrote:
> >On Tue, Mar 10, 2015 at 01:45:38PM +0100, Martin Kletzander wrote:
> >> On Tue, Mar 10, 2015 at 12:24:03PM +0000, Daniel P. Berrange wrote:
> >> >On Tue, Mar 10, 2015 at 01:05:22PM +0100, Ján Tomko wrote:
> >> >> These are the failing qemuxml2argvtest cases:
> >> >> 60) QEMU XML-2-ARGV hugepages-pages
> >> >> ... libvirt:  error : internal error: NUMA node 1 is unavailable
> >> >> 63) QEMU XML-2-ARGV hugepages-shared
> >> >> ... libvirt:  error : internal error: NUMA node 1 is unavailable
> >> >> 324) QEMU XML-2-ARGV numatune-memnode
> >> >> ... libvirt:  error : internal error: NUMA node 1 is unavailable
> >> >> 326) QEMU XML-2-ARGV numatune-memnode-no-memory
> >> >> ... libvirt:  error : internal error: NUMA node 3 is unavailable
> >> >> 329) QEMU XML-2-ARGV numatune-auto-prefer
> >> >> ... libvirt:  error : internal error: NUMA node 1 is unavailable
> >> >>
> >> >> So with 4 fake nodes, the tests could still pass even if the function is
> >> >> not mocked. Try changing the nodeset in #326 to 4 if it fails.
> >> >>
> >>
> >> I tried changing that, it fails.  I tried adjusting the tests to more
> >> nodes, it fails.  After adjusting the mock function again, it works.
> >> So it gets mocked all the time, but I know where the difference is,
> >> probably.  Try building with -O0, it will probably disable the
> >> inlining.  However, if that's the case, I believe it's still clang's
> >> fault since they don't document inlining functions without the
> >> "inline" keyword just because you optimize.
> >>
> >
> >-O0 does disable the inlining, but introduces the stack size warning.
> >
> >> >> >
> >> >> > >> [1] https://gcc.gnu.org/onlinedocs/gcc/Inline.html
> >> >> > >> [2] http://clang.llvm.org/compatibility.html
> >> >> > >>
> >> >> > >> >>---
> >> >> > >> >>This only leaves the mysterious check-protocol failure.
> >> >> > >>
> >> >> > >> That's not that mysterious, it's just that we check the order and
> >> >> > >> clang sorts enums before structs, but gcc doesn't.  Also clang adds
> >> >> > >> "public:" to structs, so it probably treats it as a C++ or C# structs
> >> >> > >> or something?
> >> >> > >>
> >> >> >
> >> >> > By the way if I compile with clang with -std=gnu11 or -std=gnu99, the
> >> >> > "public:" stuff is gone :)
> >> >> >
> >> >>
> >> >> It is mysterious, because it doesn't fail consistently.
> >>
> >> Oh, it does fail all the time for me.
> >
> >Did I mistakenly build with gcc to fix it?
> >
> >>
> >> >> It was working for me after I tried it again after
> >> >> 'git clean -fxd', today it failed again (though I don't remember if I
> >> >> ran autogen again).
> >> >
> >> >How exactly are you running the build with clang ? Are you just doing
> >> >this
> >> >
> >> >  CC=clang ./autogen.sh && make && make check
> >> >
> >> >Or is there more to it than that ?
> >> >
> >
> >./autogen.sh --system --without-driver-modules CC="clang" && make -j5
> >check
> >
> >Now it failed two times in a row, and once without parallel make. I have
> >no idea what I did back then that fixed it.
> >
> 
> I managed to reproduce your issue!  I used -O2, so that's really it.
> I guess that even though clang leaves that code without inlining,
> llvm's internal optimizer just screws that up for us.
> 
> Anyway, we might fix future problems by disabling inlining for
> binaries used for testing, but that would be an overkill when
> building.  On the other hand, adding "noinline" to any (possibly)
> mocked function seems like the other extreme.

Funny that I didn't notice this thread initially and spotted it while
googling how to debug clang's function inlining while debugging the very
same problem described here.

I have:

$ clang -v
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: x86_64-unknown-freebsd10.1
Thread model: posix
Selected GCC installation: 
$

qemuxml2argvtest fails are 100% reproducible, there are no fails other than
that though.

The patch proposed by Ján fixes the problem for me. Also, it goes away
when I build with CFLAGS=-fno-inline.

> --
> libvir-list mailing list
> libvir-list redhat com
> https://www.redhat.com/mailman/listinfo/libvir-list


Roman Bogorodskiy

Attachment: pgpNUIkWdpvpC.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]