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@xxxxxxxxxxxxx> 0.8.0-5 - Just drop $RPM_OPT_FLAGS. They're too much of a PITA * Sat Mar 18 2006 David Woodhouse <dwmw2@xxxxxxxxxxxxx> 0.8.0-4 - Disable stack-protector options which gcc 3.2 doesn't like * Fri Mar 17 2006 David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 0.8.0-1 - Update to 0.8.0 - Resort to using compat-gcc-32 - Enable ALSA * Mon May 16 2005 David Woodhouse <dwmw2@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> 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 -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
