grub-devel
[Top][All Lists]
Advanced

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

Re: [PATCH] Kernel fixes for Cygwin


From: Javier Martín
Subject: Re: [PATCH] Kernel fixes for Cygwin
Date: Mon, 21 Jul 2008 18:50:36 +0200

El lun, 21-07-2008 a las 11:51 -0400, Pavel Roskin escribió:
> On Mon, 2008-07-21 at 13:02 +0200, Javier Martín wrote:
> > El lun, 21-07-2008 a las 12:33 +0200, Christian Franke escribió:
> > > due to the complexity of PE, a stand-alone converter may likely be
> > > larger than the ~680 LoC converter I already offered here.
> > Why do we even consider a PE->ELF converter? I think the easier way to
> > go would have the people building GRUB in cygwin (not exactly newbies)
> > to have an i386-pc-elf "cross compiler" built first, then use that for
> > the bootloader programs and the normal gcc for tools. Even a "naked"
> > (i.e. libraryless) cross compiler would work, since the bootloader part
> > of GRUB is does not need libs (in C terminology, it's "freestanding").
> > That way, we are free from "objcopy bugs" or "BFD design limitations".
> 
> Well, if we want users to recompile their toolchain first, it's too much
> to ask.
I think it is not, since people building GRUB in Cygwin are not exactly
newcomers to the land of compiling: this package requires that its files
and modules be in ELF format; your compiler does not do it, so you need
another compiler. End of the problem.

Of course, another way to go could be to allow the bootloader part of
GRUB to be built in PE format: it would "just" be a matter of writing
the PE counterparts to kern/elf.c and abstracting kern/dl.c "a
bit" (i.e. a lot of work). The downside to this, apart from the
unspecified work required, is that Windows-built i386-pc-pe modules are
no longer compatible with Linux-built i386-pc-elf. Not a showstopper,
but might require a sober thinking. As I have a lot of free time right
now, I'll try to think whether it's possible or not.

> Maybe we could treat ELF header like a multiboot header?  That means
> that we write the header fields in the assembly language, substitute the
> necessary variables and ask objcopy to make a raw binary that would
> actually be an ELF file?
As far as I understand the ELF format, this would be too complex to get
right: there's a lot of info in there.
> 
> We could actually do it for all platforms, so that we won't depend on
> the object file format.
> 

Attachment: signature.asc
Description: Esta parte del mensaje está firmada digitalmente


reply via email to

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