On Tue, Jan 28, 2020 at 2:27 PM Aleksandar Markovic
<address@hidden <mailto:address@hidden>> wrote:
On Tuesday, January 28, 2020, BALATON Zoltan <address@hidden
<mailto:address@hidden>> wrote:
On Tue, 28 Jan 2020, Aleksandar Markovic wrote:
On Sunday, January 26, 2020, Aleksandar Markovic <
address@hidden
<mailto:address@hidden>> wrote:
From: Philippe Mathieu-Daudé <address@hidden
<mailto:address@hidden>>
Some platforms (like AVR) need to determine cpu type by
reading
the ELF flags (field e_flags oin ELF header).
This patch enables discovery of the content of that flag
while
using following functions:
- load_elf()
- load_elf_as()
- load_elf_ram()
- load_elf_ram_sym()
The added argument of these functions is of type
uint32_t*. It is
allowed to pass NULL as that argument, and in such case
no lookup
to the field e_flags will happen, and of course, no
information
will be returned to the caller.
Applied to MIPS queue, with some commit message corrections and fixes.
We plan to use this new functionality for MIPS Malta board,
for detection
of incompatible cpu/kernel combinations, and graceful exit
(right now these
combinations result in hang or crash). I would say other
boards could make
use of it too.
For that reason, if there is no objection, I plan to select
this patch for
next MIPS queue.
No objection but kind of déjà vu:
https://lists.nongnu.org/archive/html/qemu-devel/2019-01/msg03427.html
I still think the interface of load_elf may need to be rethinked
but I don't know a good way.
Perhaps having only two, "in" and "out", arguments that are pointers
to structures?
Another thing that I noticed is "endian argument" that it seems
everyone uses in a different way: 0, 1, true, false, bigendian, etc.
Would c enumeration help? This looks to me like a time ticking bomb.
Just to add that some platforms like MIPS and SPARC must load elfs
of more than one value of EM_MACHINE (in MIPS case, EM_MIPS and
EM_NANOMIPS) and current load_elf() interface offers only clumsy
solutions/workarounds in these cases.
Let's think about everything later on.
This could be fixed in a later patch causing more code churn
again though, so if there's a way to fix this it might be a good
opportunity now. But I don't want to hold your patch series back
so unless someone has a good idea to avoid this situation then
we have to live with it.
Thank you. I will do some minor corrections for obvious unclarities
and typos in the commit message while applying to my qieue.
Regards,
BALATON Zoltan
Regards,
Aleksandar
CC: Richard Henderson <address@hidden
<mailto:address@hidden>>
CC: Peter Maydell <address@hidden
<mailto:address@hidden>>
CC: Edgar E. Iglesias <address@hidden
<mailto:address@hidden>>
CC: Michael Walle <address@hidden>
CC: Thomas Huth <address@hidden
<mailto:address@hidden>>
CC: Laurent Vivier <address@hidden
<mailto:address@hidden>>
CC: Philippe Mathieu-Daudé <address@hidden
<mailto:address@hidden>>
CC: Aleksandar Rikalo <address@hidden
<mailto:address@hidden>>
CC: Aurelien Jarno <address@hidden
<mailto:address@hidden>>
CC: Jia Liu <address@hidden <mailto:address@hidden>>
CC: David Gibson <address@hidden
<mailto:address@hidden>>
CC: Mark Cave-Ayland <address@hidden
<mailto:address@hidden>>
CC: BALATON Zoltan <address@hidden
<mailto:address@hidden>>
CC: Christian Borntraeger <address@hidden
<mailto:address@hidden>>
CC: Thomas Huth <address@hidden <mailto:address@hidden>>
CC: Artyom Tarasenko <address@hidden
<mailto:address@hidden>>
CC: Fabien Chouteau <address@hidden
<mailto:address@hidden>>
CC: KONRAD Frederic <address@hidden
<mailto:address@hidden>>
CC: Max Filippov <address@hidden
<mailto:address@hidden>>
Signed-off-by: Michael Rolnik <address@hidden
<mailto:address@hidden>>
Reviewed-by: Aleksandar Markovic <address@hidden
<mailto:address@hidden>>
[PMD: Extracted from bigger patch,
Replaced 'uint32_t *pe_flags' by 'int proc_flags']
[AM: Replaced 'int proc_flags' with 'uint32_t *pflags',
replaced one instance of 'elf_sword' to 'elf_word',
extended functionality to load_elf()]
Signed-off-by: Philippe Mathieu-Daudé <address@hidden
<mailto:address@hidden>>
Signed-off-by: Aleksandar Markovic
<address@hidden
<mailto:address@hidden>>
---
hw/alpha/dp264.c | 4 ++--
hw/arm/armv7m.c | 2 +-
hw/arm/boot.c | 2 +-
hw/core/generic-loader.c | 2 +-
hw/core/loader.c | 37
+++++++++++++++++++------------------
hw/cris/boot.c | 2 +-
hw/hppa/machine.c | 4 ++--
hw/i386/multiboot.c | 2 +-
hw/i386/x86.c | 2 +-
hw/lm32/lm32_boards.c | 4 ++--
hw/lm32/milkymist.c | 2 +-
hw/m68k/an5206.c | 2 +-
hw/m68k/mcf5208.c | 2 +-
hw/m68k/q800.c | 2 +-
hw/microblaze/boot.c | 4 ++--
hw/mips/mips_fulong2e.c | 2 +-
hw/mips/mips_malta.c | 3 ++-
hw/mips/mips_mipssim.c | 2 +-
hw/mips/mips_r4k.c | 2 +-
hw/moxie/moxiesim.c | 2 +-
hw/nios2/boot.c | 4 ++--
hw/openrisc/openrisc_sim.c | 2 +-
hw/pci-host/prep.c | 3 ++-
hw/ppc/e500.c | 2 +-
hw/ppc/mac_newworld.c | 4 ++--
hw/ppc/mac_oldworld.c | 4 ++--
hw/ppc/ppc440_bamboo.c | 2 +-
hw/ppc/sam460ex.c | 3 ++-
hw/ppc/spapr.c | 6 +++---
hw/ppc/virtex_ml507.c | 2 +-
hw/riscv/boot.c | 4 ++--
hw/s390x/ipl.c | 7 ++++---
hw/sparc/leon3.c | 2 +-
hw/sparc/sun4m.c | 4 ++--
hw/sparc64/sun4u.c | 5 +++--
hw/tricore/tricore_testboard.c | 2 +-
hw/xtensa/sim.c | 2 +-
hw/xtensa/xtfpga.c | 2 +-
include/hw/elf_ops.h | 6 +++++-
include/hw/loader.h | 21 ++++++++++++---------
40 files changed, 92 insertions(+), 79 deletions(-)