On 09.02.2012, at 20:15, Peter Maydell wrote: > On 9 February 2012 19:12, Alexander Graf <ag...@suse.de> wrote: >> >> On 09.02.2012, at 20:11, Peter Maydell wrote: >> >>> On 9 February 2012 18:23, Andreas Färber <afaer...@suse.de> wrote: >>>> Am 09.02.2012 18:07, schrieb Peter Maydell: >>>>> (2) qemu 1.0 does not work on ARM hosts -- see the release notes. >>>>> (3) at least one of the problems which meant we marked it as unsupported >>>>> is still unfixed in master, so this isn't going to work >>>> >>>> What's the remaining issue? I was able to successfully compile and run >>>> arm-softmmu + arm-linux-user on Oneiric the weekend. >>> >>> On ARM Linux glibc provides a makecontext() that always fails ENOSYS, >>> so our configure test thinks there is makecontext support but when we >>> try to use it for coroutines it will fail and we abort. >>> >>> I have a workaround in qemu-linaro that just forces the makecontext >>> test to fail on ARM but I don't like that much. It would be better >>> to either drop our requirement for makecontext (Paolo had some patches >>> to try to do this IIRC) or to handle it failing at runtime. >> >> Or make the configure test be an execution test and always disable it for >> cross-compile? > > Don't like that idea much either :-) > > Really what I want is for ARM hosts to be using the same execution > paths as x86, because being on a less-tested fallback code path > is likely to result in hitting more bugs.
True. > So either we should > make qemu not rely on makecontext or we should get makecontext > added to glibc (David Gilbert has an implementation which we're > attempting to submit to eglibc) Good point, that's certainly the better way to go > and make sure that configure/qemu > can cope with both ARM systems with working makecontext and the > old ones without. Then you're back again to square one where you take different code paths from x86. Could you emulate makecontext inside a compat wrapper in qemu like you implement it in your eglibc patch? Then the "fallback code" wouldn't be a different code path, it'd just move functionality from glibc into qemu for compatibility with older libc. Alex
