[Top][All Lists]

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

Re: RE : grub-emu state of the art

From: Marco Gerards
Subject: Re: RE : grub-emu state of the art
Date: Fri, 05 May 2006 13:39:03 +0200
User-agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux)

Eric Salomé <address@hidden> writes:

> GRUB 2 Wiki
> ToDoList : Implement ModuleLoading in grub-emu

Right, and I even added this item.  Sorry, I just misunderstood your
previous email.

> I worked on that : Architecture i386/pc - Emulation on Linux/Ubuntu
> grub-emu is loading all current modules, though some won't do anything
> in emulation mode. The modules .mod are the same as those used for boot
> time.


> Little changes in source code, though I had to adapt asm files to
> passing parameters in stack (I compile without -mregparm=3 -mrtd options
> as I didn't want to recompile the whole C library with those passing
> parameters conventions).

It would be nice to get this to work for the regular modules too.  In
that case we do not need two set of modules.  Besides that, it should
also work on the PPC, for example.  Which is a lot harder.

BTW, how did you implement this?  I once wrote a hack to do exactly
the same by using mmap to allocate executable memory.  On the PPC this
memory needs to be allocated close to the grub-emu binary because
otherwise the relocations would fail.

> ... when I be done with grub 2 debugging I'll just have to recompile
> with these options (if you like them a lot) and it will work just fine
> (boot time only).

It's not only that we like them.  They make the size of the binaries
smaller.  And it is a requirement for the assembler code.

> ToBeAwardedOf:
> Don't use gcc 3.3 with grub 2's current source files : compiled code is
> wrong and subject to unattended results.
> Runs fine with gcc 4.0. I have still a doubt about gcc 3.4.

Wrong in what way?  We have some workaround for specific gcc bugs.
Although these are sometimes hard to locate, sometimes it might be
worth the effort.

> LeftToDo : 
> - see if every modification is useful, as I tried a few things before I
> got a good result, and send a diff patch.

Please describe how things work in detail so we can discuss possible

> - I need a "patched" symlist.c to compile with grub-emu (could be
> generated by a script, but I am too lazy).


> - let gdb know about dynamically loaded modules ;-), but I guess it
> won't be the easy part.

Yeah, I can imagine that.  But in case specific modules have to be
debugged, we can just compile them in as happens currently.  This is
what I do now.

The big advantage of having module support in grub-emu is as a
debugging tool for module loading itself.  It will make porting GRUB
to another architecture a lot easier.  And besides that, debugging
will be a lot easier too.


reply via email to

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