On Sat, Aug 25, 2012 at 09:18:17AM +0000, Blue Swirl wrote: > On Fri, Aug 24, 2012 at 6:53 PM, Aurelien Jarno <aurel...@aurel32.net> wrote: > > On Fri, Aug 24, 2012 at 08:43:32PM +0200, Andreas Färber wrote: > >> Am 24.08.2012 20:05, schrieb Aurelien Jarno: > >> > On Fri, Aug 24, 2012 at 05:52:29PM +0200, Andreas Färber wrote: > >> >> Not opposed to changing the argument order, but given that we're inches > >> >> away from v1.2 (in Hard Freeze), it might be better to first get AREG0 > >> >> as first argument working for your favorite hosts as a bugfix and then > >> >> do any larger optimization for v1.3. > >> > > >> > It's what I tried to do first, but I don't think it is realistic to use > >> > such a code for v1.2, it is complex to support all cases, and thus > >> > likely full of bugs. Maybe we should simply disable ARM and MIPS support > >> > for this release. > >> > >> Depends on what you mean with "disable"? Adding an #error would hurt our > >> arm build just like earlier the ppc build, and I would hope from my last > >> testing that the problems would only affect the AREG0 targets, > >> especially not ARM on ARM (or MIPS on MIPS). > >> > > > > I mean basically not building qemu-system-{alpha,i386,x86_64,or32,sparc, > > sparc64,xtensa,ppc,ppc64} on arm and mips hosts. > > It should be easy to fix the call register problems by those who know > the ABIs and the fixes could be applied for stable series even after > release. Disabling the targets and enabling them later would be equal > to introducing new features which is not OK for stable branch. So I'd > just declare in release errata that there are known problem with these > less commonly used combinations and a fix may arrive later.
The problem is that it is not that easy as said in my previous mails. Having to support both AREG0 and non-AREG0 cases make this even worse. My thought was to disable the support completely and add it back to 1.3 not to stable 1.2.x. > > > >> Aborting at runtime, only when really unsupported, would seem better. > > > > What's the point of providing non working binaries, beside getting bug > > reports? > > I think the deeper problem is that most TCG targets are not actively > maintained. Does for example IA64 work at all? If we removed the > unmaintained targets, would anyone complain? Development should not be > stalled because a maintainer is absent for several months. It is broken by recent TCG changes, but I am currently looking at that. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net