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 at 12:19 AM, Gabe Black via gem5-dev <gem5-dev@gem5.org
> wrote:
> 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 instead of just doing what the file says. My
> thought would be to rework the ELF loader so it just follows the
> instructions in the headers and make everything work that way. It should be
> fairly straightforward, but I can't guarantee there won't be nasty spots
> where things break down.
>
> As far as how to set up your System class, yes, you should inherit from
> System somehow. There are a lot of things which try to access the System
> object, and if they can't it would be bad. I think gem5 will at least
> complain if you don't have a kernel, but you could probably make it stop
> pretty easily. I think right now the assumption about what kind of thing
> the System is going to load is too baked in, but fixing that would be a big
> change.
>
> Gabe
>
> On Thu, Dec 11, 2014 at 12:07 AM, Randolf Rotta via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> > 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 mode. This worked well with
> > bochs, qemu, grub, XeonPhi and other platforms. I assume that limited
> > 16-bit and 32-bit support is in gem5 already. Usually, it is needed in
> > order to activate the other hardware threads ("application processors")
> > after the kernel booted on the first.
> >
> > The naming "multiboot" is misleading. It is not about selecting kernels
> > interactively during the boot process. Indeed, this would be of little
> use
> > within a simulator. The multiboot specification defines an interface
> > between bootloader/system and the OS kernel [1]. For example, a memory
> map
> > table that enumerates the reserved and usable memory ranges is passed to
> > the kernel. This simplifies the boot process a lot usually.
> >
> > With the patches from [2] everything needed for a limited multiboot
> > support is in place. The only problem is, that the current ELF loader of
> > gem5 ignores the PT_LOAD segments (aka program headers) in the ELF image
> > and, instead, misinterprets the sections information. In the context of
> the
> > ELF format, sections are used by the linker and the segments should be
> used
> > by the the loader...
> >
> > Unfortunately, usage of the current gem5 ELF loader is triggered by the
> > constructor of class System and System* pointers are used in other places
> > of the gem5 code.
> >
> > Is there anything to be aware of when doing a full system simulation
> > without setting a kernel image in the System class, i.e. FullSystem=true
> > and params()->kernel == "" ??? Then, I could load the kernel image with
> an
> > own loader in MultibootX86System...
> >
> > Best regards,
> >
> > Randolf Rotta
> > (Brandenburgische Technische Universität Cottbus)
> >
> > [1] http://en.wikipedia.org/wiki/Multiboot_Specification
> > [2] https://bitbucket.org/chrism333/gem5-patches/src/
> >
> > Am 28.11.2014 um 15:55 schrieb Nilay Vaish via gem5-dev:
> >
> > > 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 going for multiboot. In fact, I am unable to think of any
> > > benefits that multiboot would provide. On an actual system, it takes
> > > time to install a kernel and if things go wrong, you would want to
> > > switch back to some working version. With a simulator, you can
> maintain
> > > different kernel versions somewhere, and supply the right path to the
> > > simulator.
> > >
> > > --
> > > Nilay
> > >
> > > On Thu, 27 Nov 2014, Randolf Rotta via gem5-dev wrote:
> > >
> > >> 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 in the high 64bit kernel-space. Hence, gem5 is very
> > >> interesting for us.
> > >>
> > >> Unfortunately, we are not able to boot our kernel ELF images at the
> > >> moment. I applied the x86 32bit multiboot patches from
> > >> https://bitbucket.org/chrism333/gem5-patches/src/ and adapted the
> gem5
> > >> configuration successfully. Now gem5 tries to load the ELF image via
> > >> sim/system.cc, which ends up in ElfObject::loadSections and does fancy
> > >> things with virtual addresses and hard-coded section names.
> > >>
> > >> The ELF loader is surely doing the correct thing to load 64bit
> > >> user-space applications. But during the multiboot startup it should
> > >> really just load all LOAD segments to the requested physical addresses
> > >> and leave everything else alone -- especially virtual addresses.
> > >>
> > >> Assuming that I am able to implement such a simplified ELF loader for
> > >> kernel images, what is a good way to integrate it into the existing
> > >> infrastructure? Is it mandatory to derive the class MultibootX86System
> > >> (in arch/x86/multiboot/system.hh) from the class System (in
> > >> sim/system.hh)?
> > >>
> > >> Best regards,
> > >> Randolf Rotta
> > >>
> > >>
> > >> For reference, our kernel ELF image looks like this:
> > >> objdump -fph boot32.elf
> > >>
> > >> boot32.elf: file format elf32-i386
> > >> architecture: i386, flags 0x00000012:
> > >> EXEC_P, HAS_SYMS
> > >> start address 0x00200058
> > >>
> > >> Program Header:
> > >> LOAD off 0x00000078 vaddr 0x00200000 paddr 0x00200000 align
> 2**3
> > >> filesz 0x000003ed memsz 0x00206000 flags rwx
> > >> LOAD off 0x00000480 vaddr 0x81000000 paddr 0x00800000 align
> 2**6
> > >> filesz 0x0000da90 memsz 0x00401000 flags rwx
> > >>
> > >> Sections:
> > >> Idx Name Size VMA LMA File off Algn
> > >> 0 .init 000003ed 00200000 00200000 00000078 2**3
> > >> CONTENTS, ALLOC, LOAD, READONLY, CODE
> > >> 1 .initbss 00205000 00201000 00201000 00000465 2**0
> > >> ALLOC
> > >> 2 .text 00009256 81000000 00800000 00000480 2**1
> > >> CONTENTS, ALLOC, LOAD, READONLY, CODE
> > >> 3 .rodata 00000c4d 81009280 00809280 00009700 2**6
> > >> CONTENTS, ALLOC, LOAD, READONLY, DATA
> > >> 4 .eh_frame 00003bb8 81009ed0 00809ed0 0000a350 2**3
> > >> CONTENTS, ALLOC, LOAD, READONLY, DATA
> > >> 5 .init_array 00000008 8100da88 0080da88 0000df08 2**3
> > >> CONTENTS, ALLOC, LOAD, DATA
> > >> 6 .bss 003f3540 8100dac0 0080dac0 0000df10 2**6
> > >> ALLOC
> > >> _______________________________________________
> > >> gem5-dev mailing list
> > >> gem5-dev@gem5.org
> > >> http://m5sim.org/mailman/listinfo/gem5-dev
> > >>
> > >>
> > > _______________________________________________
> > > gem5-dev mailing list
> > > gem5-dev@gem5.org
> > > http://m5sim.org/mailman/listinfo/gem5-dev
> > _______________________________________________
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
> >
> _______________________________________________
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
