A Question About Linking/Loading and A Simulator_问答_开发者

I have designed a MIPS I simulator using Verilator which allows me to wrap verilog code into c++. I am attempting to run a c++ program on my processor but I've reached some problems. My goal is to:

write a test program in c++
compile this program using a cross compiler g++ (mips-linux)
take generated ELF file and disassemble it using objdump
store the entire binary object dump in a text file
open text file in my simulator
run some text manipulating开发者_开发技巧 functions to isolate the HEX dump portion of the objdump
load entire elf hex dump into my processor's memory (a c++ memory map containing elements keyed by their address in memory as defined by the ELF file.)
run the program by setting the program counter and letting it go until exit syscall of program.

The problem would be steps 7 and 8. I have a very rudimentary understanding of the ELF file format. As far as I can tell (readelf can be used to output a program starting point) the program ounter should be set initially at the address of the beginning of the .text section. Unfortunately doing this does not result in a proper program run on my processor.

I have verified proper program execution of my processor by writing assembly programs, loading them into MIPS assembly simulators, and verifying, instruction by instruction, that the register file and generated addressing matches. What I don't understand is why I can't get even a "helloworld" program to run by writing in c++, compiling, and loading into my "memory"? I'm not particularly knowledgeable in this field. I could really use some help figuring this out.

My understanding is that .text and .data contain everything needed for my program to run. This is obviously not the case because as I traverse the .text section, my program does not execute correctly. Is there something else I need to do with the ELF file before loading it into memory?

I have written a full MIPS I simulator that can load ELF binaries. You can get the source code here, maybe you'll get answers to your questions. There are also some demo programs included. The key point is to get the compiler to generate a freestanding executable that does not use any run-time library, not even the gcc's support library.

Here is an explanation of elf that I liked, although it seems that you understand the elf issues. They also explain how g++ outputs elf files, so it might help you parse your output file (more good info in part 1 as well).

Hope some of that info helps.

zvrba may have hit the nail on the head, you cannot/should not call C library functions like printf in your program.

Write a simple C program to start with maybe:

const unsigned char hello[]="helloworld";

void notmain ( void )
{
   unsigned int ra;

   for(ra=0;hello[ra];ra++)
   {
       PUT32(0x1234,hello[ra]);
   }
}

and call notmain from the assembler programs that you have written and have working and link together.

PUT32 just writes some data to some address, I normally implement these in assembler, ymmv.

Choose some address other than 0x1234, my assumption is with your sim environment you can watch accesses to an address location and watch the characters. no need yet to talk to a uart and have to decode serial in a simulation when you can watch the bytes on a bus.

Elf files really are simple to parse, if you have written a simulator, reading an elf file is not a big deal. I dont bother with libraries they just make it harder. It is a few structures if you chose to use structures. I can provide you with code that will get you started if you like. An alternative is to use gnu tools to convert the elf into a binary file (mips-whatever-objcopy file.elf -O binary file.bin). If your .text and .data are not close to each other the objcopy program will make a huge file with zeros for fill between the two address spaces. For embedded you want to avoid having anything in your .data section anyway, always initialize variables in the program not ahead of time and read only tables make const so they are in .text instead of .data

is this a project for fun or work or general public consumption? I might be interested in using it someday I like the concept of verilator but its either limited or too rigid to the verilog standard and so much verilog out there wont run under it without work, so I have not gotten to really play with it.

good luck.