This reverts commit 9f5a6f89d9f4a6c7bed3b163e6eaa764d762f523.

The reason for reverting this is:
 * qemuwrapper has now a fallback method;
 * when using multilib, calling qemu_target_binary from recipes would
   always point to the qemu binary corresponding to the machine
   architecture. Hence, postinstalls needing to use qemu would call the
   wrong qemu user emulation binary;

(From OE-Core master rev: 15408466515cec7cbb4c394aa203c87b6165f884)

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Postinstalls that use qemu are throwing a segmentation fault when
building for qemux86-64 on a 64bit host (it might also happen for
qemux86 if building on a 32bit host but I didn't test). It looks like
qemu looks for ld.so.cache which is not found because it is generated
after rootfs_(rpm|ipk|deb)_do_rootfs is called and then it tries to load
libraries from the default paths (which are the host's). In order to
avoid this, pass the LD_LIBRARY_PATH explicitly to the target's dynamic
loader.

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The intercept scripts fail to run on 32 bit hosts. Apparently, the
current approach worked on 64 bit hosts due to the larger virtual address
space (probably). On 32 bit hosts, however, calling the target binary like:

qemu-arm ld-linux.so --library-path /lib:/usr/lib arm_binary

fails with:

arm_binary: error while loading shared libraries: arm_binary: failed to
map segment from shared object: Operation not permitted

When run like this, qemu-arm fails to map the arm_binary executable in
memory because it's hitting the lower limit of
/proc/sys/vm/mmap_min_addr. That's because it loads the
ld-linux.so binary successfully, taking into account mmap_min_addr, runs
it, and then ld-linux.so will map the arm_binary at a fixed address but this
will fail because it is below mmap_min_addr. The qemu's guest base probing,
apparently, doesn't work fine when a program runs inside other.

One way around this would be to set mmap_min_addr to 0 (on recent
distributions is set to 65536 to avoid "kernel NULL pointer dereference"
defects) but this approach is not safe.

The other way is to call the binary directly but providing qemu with a
prefix (-L option) in order to find the elf interpreter correctly. This
way, both the target binary and dynamic loader are mapped into memory
under qemu's control and, only after, the dynamic loader is started.

[YOCTO #4179]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

qemu user binaries sometimes segfault when running them through pseudo.
So, set PSEUDO_UNLOAD to 1 before running any qemu binary.

[YOCTO #3788]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

For example with a lib32 multilib, we need to still use the 64 bit
qemu binary in case we do encounter a 64 bit binary.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

When qemu bbclass is inherited from a recipe that is not architecture
dependent, qemu_run_binary will return "qemu-allarch". However this
binary does not exist. Instead, return "qemuwrapper" which will, in
turn, execute the right binary for the target the image was built for.

[YOCTO #2599]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

[YOCTO #3602]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

The bb and os modules are always imported so having these extra import calls
are a waste of space/execution time. They also set a bad example for people
copy and pasting code so clean them up.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>