aboutsummaryrefslogtreecommitdiff
path: root/slirp
diff options
context:
space:
mode:
authorblueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>2009-03-13 21:16:24 +0000
committerblueswir1 <blueswir1@c046a42c-6fe2-441c-8c8c-71466251a162>2009-03-13 21:16:24 +0000
commit7f70c93716412b0874ae231c2f5416edccb22e7f (patch)
tree4d0b56b7eba01af64aaa3327dabc6b13b2cb6e45 /slirp
parent92a3ecda6735ca9d15cd739ca5973e006bb2cf7a (diff)
Make the ELF loader aware of backwards compatibility
Most 64 bit architectures I'm aware of support running 32 bit code of the same architecture as well. So x86_64 can run i386 code easily and ppc64 can run ppc code. Unfortunately, the current checks are pretty strict. So you can only load e.g. an x86_64 elf binary on qemu-system-x86_64, but no i386 one. This can get really annoying. I first encountered this issue with my multiboot patch, where qemu-system-x86_64 was unable to load an i386 elf binary because the elf loader rejected it. The same thing happened again on PPC64 now. The firmware we're loading is a PPC32 elf binary, as it's shared with PPC32. But the platform is PPC64. Right now there is a hack for this in the ppc cpu.h definition, that simply sets the type to PPC32 in system emulation mode. While that works fine for the firmware, it's no good if you also want to load a PPC64 kernel with -kernel. So in order to solve this mess, I figured the easiest way is to make the elf loader aware of platforms that are backwards compatible. For now I was only sure that x86_64 does i386 and ppc64 does ppc32, but maybe there are other combinations too. This patch is a prerequisite for having a working -kernel option on PPC64. Signed-off-by: Alexander Graf <alex@csgraf.de> git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6855 c046a42c-6fe2-441c-8c8c-71466251a162
Diffstat (limited to 'slirp')
0 files changed, 0 insertions, 0 deletions