how to extend to load COFF executable image file

how to extend to load COFF executable image file

[xiaolei]

Hi all,
  I attempt to add DSP architecture support for some TI processor, based on QEMU 4.2.
  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?

  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.

struct Rom {
    char *name;
    char *path;

    /* datasize is the amount of memory allocated in "data". If datasize is less
     * than romsize, it means that the area from datasize to romsize is filled
     * with zeros.
     */
    size_t romsize;      //?how to fill romsize for coff file 
    size_t datasize;    //?how to fill datasize for coff file 
    uint8_t *data;      //? for coff file 
    MemoryRegion *mr;
    AddressSpace *as;
    int isrom;
    char *fw_dir;
    char *fw_file;
    GMappedFile *mapped_file;
    bool committed;
    hwaddr addr;
    QTAILQ_ENTRY(Rom) next;
}; 
    Any advise would be appreciated!!

regards,

xiaolei cui

Re: how to extend to load COFF executable image file

[Peter Maydell]

On Tue, 12 May 2020 at 08:41, xiaolei <1482995675@qq.com> 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

Re: how to extend to load COFF executable image file

[Peter Maydell]

On Thu, 14 May 2020 at 09:44, casmac <1482995675@qq.com> wrote:
>
> Hello,
>    Thanks for the detailed explaination and insightful advise!!
>    I firstly give a try to use objcopy from GNU binutils, but it seems the COFF file I am work on (which is generated by TI's CCS IDE) cannot be recognized. The COFF format used by TI sllightly differs from GNU's definition. So I guess I have to parse and load the COFF file myself.

Ha. Over a decade ago I had to deal with TI's weirdo COFF file
variant. I took the approach of getting binutils to handle it
at least sufficiently to do COFF-to-ELF conversion:
http://www.chiark.greenend.org.uk/~pmaydell/misc/binutils.notes.txt
http://www.chiark.greenend.org.uk/~pmaydell/misc/binutils.patch.txt
though I imagine that getting that to work with a modern binutils
might be a bit of a pain.

>    As far as I understand how a COFF executable file is organized, there are generally 3 section 'chuncks'  to load. A section chunck may contain mutilple sections. For example, a program may contain 3 section chucks:
> Section chucks:                               target address on DSP processor
> Chunk 1 = txt + bss                                  0x1000
> Chunck 2= cio+const+data+stack             0x800000
> Chunck3 = vector                                    0x809fc1
>     Now, I am trying to make use of "ROM blobs" and rom_add_blob() call. I am confused about how to map the sections to blobs, one ROM for one section(for example .txt) , or one ROM for a section chunk?

You want one ROM blob for each contiguous lump of guest memory
for which you have data to provide. Guest memory which is
all-zeroes you can either do by passing a block of zeroes
to rom_add_blob(), or for the special case where the zeroes
directly follow a lump of other data, you can use
rom_add_elf_program() to avoid having to allocate the zeroes.

> Meanwhile, how to use the fileds from the  Rom struct:

You don't need to look at the rom struct fields. Just
call either rom_add_blob() or rom_add_elf_program() and
those functions will handle the rom struct for you.

thanks
-- PMM