On 18 January 2016 at 07:12, Peter Crosthwaite <crosthwaitepe...@gmail.com> wrote: > Some CPUs are of an opposite data-endianness to other components in the > system. Sometimes elfs have the data sections layed out with this CPU > data-endianess accounting for when loaded via the CPU, byte swaps > (relative to other system components) will occur. > > The leading example, is ARM's BE32 mode, which is is basically LE with > address manipulation on half-word and byte accesses to access the > hw/byte reversed address. This means that word data is invariant > accross LE and BE32. This also means that instructions are still LE. > The expectation is that the elf will be loaded via the CPU in this > endianness scheme, which means the data in the elf is reversed at > compile time. > > As QEMU loads via the system memory directly, rather than the CPU, we > need a mechanism to reverse elf data endianness to implement this > possibility. > > Signed-off-by: Peter Crosthwaite <crosthwaite.pe...@gmail.com>
> diff --git a/include/hw/loader.h b/include/hw/loader.h > index 33067f8..e542575 100644 > --- a/include/hw/loader.h > +++ b/include/hw/loader.h > @@ -35,7 +35,7 @@ const char *load_elf_strerror(int error); > int load_elf(const char *filename, uint64_t (*translate_fn)(void *, > uint64_t), > void *translate_opaque, uint64_t *pentry, uint64_t *lowaddr, > uint64_t *highaddr, int big_endian, int elf_machine, > - int clear_lsb); > + int clear_lsb, int data_swab); > void load_elf_hdr(const char *filename, void *hdr, bool *is64, Error **errp); > int load_aout(const char *filename, hwaddr addr, int max_sz, > int bswap_needed, hwaddr target_page_size); Can we have a doc comment so we have something that defines what values data_swab accepts? (it's not just a bool). Otherwise Reviewed-by: Peter Maydell <peter.mayd...@linaro.org> thanks -- PMM
