Summary: | app-emulation/qemu: ELF loaders should dynamically allocate target pages to hold command line / environment | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Jones <gentoo> |
Component: | [OLD] Core system | Assignee: | Gentoo QEMU Project <qemu+disabled> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | calchan, eugenecormier, mmk |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log.gz
qemu-max-args.patch |
Description
Michael Jones
2014-12-29 00:49:52 UTC
Created attachment 392610 [details]
build.log.gz
i imagine it's qemu related there is an answer how to fix this here: https://blogs.gentoo.org/calchan/2015/03/11/binsh-argument-list-too-long/ maybe we can get a patch? Created attachment 400298 [details, diff]
qemu-max-args.patch
Drop into /etc/portage/patches/app-emulation/qemu/
and then rebuild qemu.
Have not verified that this actually fixes the problem yet.
the linux kernel itself changed from a static limit to dynamic on MMU systems. qemu should do the same. increasing that constant is a workaround, but it's not entirely free -- it will attempt to allocate that many pages and make it available in the target memory space. even if you only need ~1 page of data normally. Hopefully Qemu addresses the dynamic allocation problem soon then. Even bumping it to 64 wasn't enough for LibreOffice. 256 seemed to be enough though. (In reply to SpanKY from comment #5) > the linux kernel itself changed from a static limit to dynamic on MMU > systems. qemu should do the same. increasing that constant is a > workaround, but it's not entirely free -- it will attempt to allocate that > many pages and make it available in the target memory space. even if you > only need ~1 page of data normally. Oh, now I understand why I was CCed on this bug. Do you want me to add a fix to the ebuild to work around the issue? And if so, do you prefer a patch or a sed? I have looked at discussions about it on upstream's mailing list, and it doesn't look like we're getting a dynamic solution anytime soon. But you may know more than me about this. If you want me to do it then I'll bisect the minimum required value for binutils to build. I think minimizing the value should also minimize the amount of potential issues we could get due to increasing it. In my blog post I just doubled the kernel value because all I wanted was for binutils to build. So far it's been the only problematic package, and I have tried a truckload of them, even some very non-embedded ones. Using my crossroot tool (which I should release, someday I'll eventually stop slacking) makes this bisecting easy. Denis. (In reply to Denis Dupeyron from comment #7) nah, i'm not really looking for a workaround patch here. just cc-ing you since your post covered the issue and you were interested in doing more, or wanted to follow along. This was fixed upstream by commit commit 59baae9a626396a3a05840279084c4bf2beb8f40 Author: Stefan Brüns <stefan.bruens@rwth-aachen.de> Date: Wed Sep 2 03:38:53 2015 +0200 linux-user: remove MAX_ARG_PAGES limit Instead of creating a temporary copy for the whole environment and the arguments, directly copy everything to the target stack. For this to work, we have to change the order of stack creation and copying the arguments. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Signed-off-by: Riku Voipio <riku.voipio@linaro.org> |