[Qemu-devel] Tracking down a bug in CIL + tcg + kernel >= 3.2

[Gabriel Kerneis]

Dear all,

I am using CIL [1] to compile QEMU. CIL is a wrapper around gcc which can be
used to analyse C code. As explained recently on this list, the ultimate goal is
to check coroutine_fn annotations statically [2]. When CIL compiles C code, it
performs a number of simplifications, which are supposed to preserve behaviour.
As a matter of fact, CIL processes the whole of QEMU (all backends), gcc does
not complain (with --disable-warn-error), and "make check" completes
successfully.  But I'm nonetheless hitting a bug in CIL simplifications and I
have a hard time tracking it down.

  [1] http://kerneis.github.io/cil/
  [2] https://github.com/kerneis/corocheck

When I try to boot a "recent" Debian kernel (>= 3.2) with -machine accel=tcg, I
get the following kernel panic:

------------[ cut here ]------------
WARNING: at /build/buildd-linux_3.2.41-2-amd64-Wvc92F/linux-3.2.4 
1/kernel/rcutree.c:2052 rcu_scheduler_starting+0x27/0x4e()       
Hardware name: Bochs                                           
Modules linked in:                                               
Pid: 0, comm: swapper/0 Not tainted 3.2.0-4-amd64 #1 Debian 3.2.4 1-2           
                                   
Call Trace:                                            nabled.
 [<ffffffff81046a55>] ? warn_slowpath_common+0x78/0x8c
 [<ffffffff810960fa>] ? rcu_scheduler_starting+0x27/0x4e
 [<ffffffff81330712>] ? rest_init+0x6/0x6b
 [<ffffffff816abb36>] ? start_kernel+0x3b8/0x3c3
 [<ffffffff816ab140>] ? early_idt_handlers+0x140/0x140
 [<ffffffff816ab3c4>] ? x86_64_start_kernel+0x104/0x111          
---[ end trace 9a2513986472a43d ]---

Older kernels (2.6.32) boot fine. Recent kernels with KVM boot fine. Compiling
with gcc (of course) boots fine.

So CIL introduces a bug in TCG which prevents >= 3.2 kernels from booting with
the above error message, but I have absolutely no clue which files of QEMU's 
code
might be involved.

Does that ring a bell? It would help me tremendously if someone could point me
at a specific file (or, even better, function) that I could analyse by hand to
look for unsound simplifications.

Many thanks,
-- 
Gabriel