qemu optflags

[David Woodhouse]

On Wed, 2007-01-31 at 08:58 +0100, Hans de Goede wrote:
> I'm sort of co-maintaining qemu, I've added a comment to this bug to try 
> to get this sorted out. Also I'm a bit annoyed about this public naming 
> and shaming of this bug, without first properly discussing this.

But how can we discuss it without referring to it :)

>  This bug has only 1 comment and that is from the maintainer:
> 
> "Feel free to provide a tested patch which doesn't affect performance"

> After which he closed it. IOW he gave the reporter plenty of room to 
> start a discussion about this. But instead the reporter has choosen to 
> start complaining about it here. Not a good move IMHO.

I don't mind much where the discussion happens, although it's best to Cc
me if it's on a mailing list. In fact, using the mailing list may entice
other capable people to look at the problem so maybe it's not such a bad
move.

I'll elucidate, shall I? Let's start with an excerpt from the changelog
for the package in question...

* Sat Mar 18 2006 David Woodhouse <dwmw2 at infradead.org> 0.8.0-5
- Just drop $RPM_OPT_FLAGS. They're too much of a PITA

* Sat Mar 18 2006 David Woodhouse <dwmw2 at infradead.org> 0.8.0-4
- Disable stack-protector options which gcc 3.2 doesn't like

* Fri Mar 17 2006 David Woodhouse <dwmw2 at infradead.org> 0.8.0-3
- Use -mcpu= instead of -mtune= on x86_64 too
- Disable SPARC targets on x86_64, because dyngen doesn't like fnegs

* Fri Mar 17 2006 David Woodhouse <dwmw2 at infradead.org> 0.8.0-2
- Don't use -mtune=pentium4 on i386. GCC 3.2 doesn't like it

* Fri Mar 17 2006 David Woodhouse <dwmw2 at infradead.org> 0.8.0-1
- Update to 0.8.0
- Resort to using compat-gcc-32
- Enable ALSA

* Mon May 16 2005 David Woodhouse <dwmw2 at infradead.org> 0.7.0-2
- Proper fix for GCC 4 putting 'blr' or 'ret' in the middle of the function,
  for i386, x86_64 and PPC.

* Sat Apr 30 2005 David Woodhouse <dwmw2 at infradead.org> 0.7.0-1
- Update to 0.7.0
- Fix dyngen for PPC functions which end in unconditional branch


Qemu is, as stated, a pain in the arse. It's _very_ dependent on
compiler output, because of the way it takes 'snippets' of code from
tiny functions and uses those as the building blocks for its
translation.

In particular, we can't use GCC 4.x for it, because that'll tend to
insert 'blr' instructions in the middle of function calls rather than
jumping to the end and having only a single return -- and that really
makes qemu unhappy when it just knocks the 'blr' off the end and sticks
those blocks of code together sequentially. When we used GCC 4 I think
there was also a problem with global register variables on some crappy
arch with too few registers too.

There's work on making qemu happy with current compilers, but it's not
ready yet. I've poked at it myself on occasion, as evidenced above, but
there's _always_ something more important to do and something else that
goes wrong with it just when you think it's OK. And the work I _have_
done on qemu recently has been on NPTL support in the qemu-user tools,
so you can actually run current userspace (I want i386 flash plugin in
qemu in nspluginwrapper in my ppc firefox, and I actually have it just
about working).

So we can't "just use $RPM_OPT_FLAGS" because some of those flags don't
work with the older compiler. Although there _is_ a possibility of using
one compiler for dyngen and another for qemu proper, which could perhaps
be investigated.

The bit about -fomit-frame-pointer I wasn't really paying much attention
to -- I never debug on i386 anyway, and in fact I rarely debug qemu
itself; more often I want to debug the stuff I run _in_ it.

The above-quoted sentence should be taken with emphasis on the "provide
a tested patch" part rather than the "doesn't affect performance" part.
And in the context of the changelog...

And it should be taken at face value -- really, feel free to provide a
patch. It wasn't just a brush-off. It's not that I don't want to do it.
It's not (just) that I'm lazy. It's that I tried, and I failed, and I
ended up reverting to what we have at the moment.

There is probably room for improvement -- perhaps by using GCC 4 for
most of it but GCC 3 for dyngen. But then you have to deal with that
crappy register-starved arch, I think, which is why I didn't do it
before. Although I have to admit I _was_ tempted to ExcludeArch: i386 :)

-- 
dwmw2