I will take a look at the dependencies between the ELF loader and gem5
next week.
Randolf
Am 11.12.2014 um 17:01 schrieb Steve Reinhardt via gem5-dev:
HIstorically we started out with Alpha Tru64, so I think our first loader
was the ecoff one. When we added ELF support we probably tried too
Hello Nilay,
many thanks for your answer. I hope I can clarify a little bit what we
had in mind.
As far as I know, the legacy interrupt mechanisms are not working on x86
32-bit full system and we are not going to use them. Our kernels just
use a 32-bit entry point and then switch to 64-bit
Hi Randolf. I'm not familiar with the multiboot patches, but yes, secondary
(AP) CPUs make a brief trip through real mode and 32 bit mode on their way
to 64 bit mode, and we simulate that.
The ELF loader in SE mode predates me, but I've always thought it tried too
hard to identify what was what
HIstorically we started out with Alpha Tru64, so I think our first loader
was the ecoff one. When we added ELF support we probably tried too hard to
keep the same structure as the ecoff loader. A simplified, generalized ELF
loader would be a fine thing in my opinion.
Steve
On Thu, Dec 11, 2014
A couple of things that might help. First, I think x86 32-bit support is
only available in system call emulation mode. For 32-bit x86 full system,
you probably will have to make significant changes to gem5. Second, since
you are not able to boot a single kernel, I don't see the point of
Hello,
my research group is working on lightweight operating systems for
many-core processors. We are looking for a full system simulator that
supports debugging of x86-64 code and processor state. Qemu does not
tell much about the cpu state and the Bochs debugger has problems with
addresses
