Created attachment 3034 [details] log.do_compile Git rev: master/8debfea81e69d038bd2d56314b272cb74f5582ed Steps: 1. Set MACHINE = "qemumips64" 2. Run bitbake gobject-introspection This issue only happens on i686 hosts (I tested on Debian 8 and Fedora 23) for qemumips64. Please see the attached log for details.
Please set the attachment type to text/plain if it's a plaintext log, so it can be viewed directly in the browser.
I believe this might be a limitation of qemu ('Address overflow loading ELF binary'), or simply unsupported. Why do we test 32 bit build hosts in the first place? They're well obsolete.
(In reply to comment #2) > I believe this might be a limitation of qemu ('Address overflow loading ELF > binary'), or simply unsupported. > > Why do we test 32 bit build hosts in the first place? They're well obsolete. Hi Alexander, As I know there is no one says the Yocto doesn't support i686 host or it *only* supports x86_64 host. So as a QA, I still need to test it on i686 host now. Thanks, Yi
Alright, seems like this issue could be reported directly to qemu upstream. We simply don't have the competence to figure out intricate details of emulating mips64 on 32 bit intel.
Created attachment 3086 [details] the same logfile as text/plain
Can you attach the file /buildarea/poky/build/tmp/work/mips64-poky-linux/gobject-introspection/1.46.0-r0/build/g-ir-scanner-qemuwrapper ? Before reporting upstream, I'd like to verify that the correct qemu binary is used to run mips64 executables.
Created attachment 3097 [details] g-ir-scanner-qemuwrapper
The g-ir-scanner-qemuwrapper is attached.
This issue still exists in 2.2 M1. Git rev: master/6f0c5537e02c59e1c8f3b08f598dc049ff8ee098
Confirmed. Can you report this issue upstream? There's not much else we can do. http://wiki.qemu.org/Contribute/ReportABug
(In reply to comment #10) > Confirmed. Can you report this issue upstream? There's not much else we can > do. > > http://wiki.qemu.org/Contribute/ReportABug Report to upstream: https://bugs.launchpad.net/qemu/+bug/1600681
(In reply to comment #11) > Report to upstream: > https://bugs.launchpad.net/qemu/+bug/1600681 Please fix the title, because it's not about gobject introspection at all. It should say: Usermode qemu-mips64 does not run on 32 bit i686 hosts And add this to the beginning of the bug description, so the upstream immediately sees the crux of the issue: Usermode qemu-mips64 fails to execute on 32 bit hosts with this error: "Address overflow loading ELF binary"
(In reply to comment #12) > (In reply to comment #11) > > Report to upstream: > > https://bugs.launchpad.net/qemu/+bug/1600681 > > Please fix the title, because it's not about gobject introspection at all. > It should say: > Usermode qemu-mips64 does not run on 32 bit i686 hosts > > And add this to the beginning of the bug description, so the upstream > immediately sees the crux of the issue: > > Usermode qemu-mips64 fails to execute on 32 bit hosts with this error: > "Address overflow loading ELF binary" Thanks. Update complete.
Someone replied in upstream bug tracer: https://bugs.launchpad.net/qemu/+bug/1600681/comments/2 Peter Maydell (pmaydell) wrote on 2016-07-12: #2 Yes, in general you can't reliably run the linux-user QEMU for a 64-bit target on a 32-bit host. You'll need to run it on a 64-bit host instead. Looks like they don't want to fix it recently. So what should we do for this bug? Thanks, Yi
If upstream say that 32-bit hosts running 64-bit user guests are not supported then we should probably: 1) document this 2) refuse to allow this combination in qemu.bbclass
Hi, I am trying to dig out the change for this for the YP docs. We have a chapter called "Using the Quick EMUlator (QEMU)" (http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#dev-manual-qemu) in the dev-manual that overviews using QEMU. Is it appropriate to declare in a note early in this chapter that we do not support using QEMU to run 64-bit user guests on a 32-bit host? Thanks, Scott
(In reply to comment #16) > I am trying to dig out the change for this for the YP docs. We have a > chapter called "Using the Quick EMUlator (QEMU)" > (http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#dev-manual- > qemu) in the dev-manual that overviews using QEMU. Is it appropriate to > declare in a note early in this chapter that we do not support using QEMU to > run 64-bit user guests on a 32-bit host? I think this should go to known issues section of gobject introspection support chapter: http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#known-issues Specifically, that using qemu in usermode may not work properly when running 64 bit binaries under 32 bit host machines (mips64 in particular is known to not work under i686).
(In reply to comment #15) > If upstream say that 32-bit hosts running 64-bit user guests are not > supported then we should probably: > 2) refuse to allow this combination in qemu.bbclass I guess this check should go to qemu_target_binary() in qemu.bbclass, but I'm not sure what 'refuse' would mean specifically. Ross, can you take this?
(In reply to comment #17) > (In reply to comment #16) > > I am trying to dig out the change for this for the YP docs. We have a > > chapter called "Using the Quick EMUlator (QEMU)" > > (http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#dev-manual- > > qemu) in the dev-manual that overviews using QEMU. Is it appropriate to > > declare in a note early in this chapter that we do not support using QEMU to > > run 64-bit user guests on a 32-bit host? > > I think this should go to known issues section of gobject introspection > support chapter: > http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#known-issues > > Specifically, that using qemu in usermode may not work properly when running > 64 bit binaries under 32 bit host machines (mips64 in particular is known to > not work under i686). See http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#known-issues for a new bullet item added for this. I was not sure on some of the terminology. Please check it out and let me know if this is good for the doc component of this bug - Scott
"Using QEMU in usermode might not work properly when running 64-bit binaries under 32-bit host machines. In particular, "qemumips64" is known to not work under i686. " This is good, I would only start this way: "QEMU might not work properly when..."
Hi, I could not just add that phrase to the front of that bullet. So, I did a little rewriting. I am assuming that noting user mode was still important. Look at the new version and tell me if this is okay. If not, we can change it. http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#known-issues Thanks, Scott
"QEMU might not work properly when using QEMU in usermode..." Drop 'when using QEMU' and we're good.
Actually, "QEMU might not work properly when using QEMU in usermode and running.. " should be "QEMU usermode might not work properly when running..."
Hi Alexander, See http://www.yoctoproject.org/docs/2.2/dev-manual/dev-manual.html#known-issues for the change in that last bullet item. Let me know if this is good and I will close the bug out. Thanks, Scott
Yes, looks good now.
Thanks, Marking the bug as RESOLVED and putting the doc flag to "done". Scott
(In reply to comment #18) > (In reply to comment #15) > > If upstream say that 32-bit hosts running 64-bit user guests are not > > supported then we should probably: > > 2) refuse to allow this combination in qemu.bbclass > > I guess this check should go to qemu_target_binary() in qemu.bbclass, but > I'm not sure what 'refuse' would mean specifically. Ross, can you take this? Hi Alexander, Is there any progress for step 2? Thanks, Yi
(In reply to comment #27) > > I guess this check should go to qemu_target_binary() in qemu.bbclass, but > > I'm not sure what 'refuse' would mean specifically. Ross, can you take this? > Is there any progress for step 2? Nope. To be honest, I don't see this as an important thing to fix; we mention the problem in the documentation, use of qemu usermode is easy to disable via local config, and that should be enough. Also, 64 bit arm for instance works fine under 32 bit qemu, so refusing all of 64 bit under 32 bit host would be overkill - it would have to be done specifically for 64 bit mips, and maybe other architectures where the problem is actually confirmed by testing.