Re: [Qemu-devel] [Bug 929638] Re: qemu 1.0 unable to compile on the pandaboard ES

[Alexander Graf]

On 09.02.2012, at 20:15, Peter Maydell wrote:

> On 9 February 2012 19:12, Alexander Graf <address@hidden> wrote:
>> 
>> On 09.02.2012, at 20:11, Peter Maydell wrote:
>> 
>>> On 9 February 2012 18:23, Andreas Färber <address@hidden> 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