qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: how to extend to load COFF executable image file


From: Peter Maydell
Subject: Re: how to extend to load COFF executable image file
Date: Tue, 12 May 2020 10:31:28 +0100

On Tue, 12 May 2020 at 08:41, xiaolei <address@hidden> wrote:
>
> Hi all,
>   I attempt to add DSP architecture support for some TI processor, based on 
> QEMU 4.2.

Don't try to add new code to QEMU based on an old version.
You should always work with the head-of-git. Otherwise you'll
be dealing with stuff that's gradually drifting out of date
and you'll end up with pain when you need to rebase.

>   When I work on the executable file loading , I try to load COFF executable  
> file. Following the ELF file processing scheme, I thought I could write a 
> function similar to :
>        rom_add_elf_program(label, mapped_file, data, file_size, mem_size, 
> addr, as);
>   But I got lost when I track down the usage to the global variable  :static 
> QTAILQ_HEAD(, Rom) roms;
>   I did not get where this 'roms'  is used for program loading, and how the 
> loaded program get to run eventually.  Can someone give me some hints?

You've gone down too far into the internals of the implementation there.
The way that QEMU's image loading code works is that all the data
that must be loaded is put into a set of "ROM blobs", which we
keep in a linked list. When the system is reset then the function
rom_reset() runs through the list and copies the data in each
blob into the right location in the guest memory. The simplest
way to create a blob is to use rom_add_blob(); but you could
also use rom_add_elf_program() if you wanted. That function is
a bit misnamed: it's not ELF specific and it doesn't handle
an entire program; it just has a couple of extra properties over
rom_add_blob:
 * it lets the caller provide data which only partly fills
   the blob, with the remainder to be zeroes
 * it can work with a GMappedFile so you don't need to copy
   the data out of the mapped file to pass to it

>   Also, the COFF file format differs from the ELF, there is no program 
> header. I wonder if I could reuse the 'rom' structure like loading a ELF. Or 
> there is a better way to do it.

Yes, you want to reuse the Rom struct, which isn't ELF specific
(we also use it for loading raw files and uImages). You would
need to write code which could read and parse a COFF file and
identify what parts of the input file needed to go where in
memory (and what parts of memory would need to be zeroed). Then
for each of those parts of memory you create a rom blob
(via rom_add_blob() or rom_add_elf_program()). That is, you
want the equivalent of the function "static int glue(load_elf, SZ)"
in include/hw/elf_ops.h. (That function is a bit odd because
we use the C preprocessor to create a 32 bit and a 64 bit
version of the function so we can load 32-bit ELF and 64-bit
ELF files. COFF may not need that complication.)

Consider also taking the simpler approach of just using
binutils objcopy to convert the COFF file into an ELF
and then passing that ELF file to QEMU. In particular
if you're also trying to implement an entire new architecture
you might as well skip the pain of writing a COFF file
loader for the moment.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]