Re: [Etherboot-developers] Mknbi is the misbehaving when reloc'd

[Eric W B. <ebi...@ln...>]

Marc Singer <el...@bu...> writes:

> On Sat, Sep 21, 2002 at 09:36:15AM -0700, Marc Singer wrote:
> > On Sun, Sep 22, 2002 at 02:07:59AM +1000, Ken Yap wrote:
> > > >I was wondering about that.  I was also wondering if there would be
> > > >any utility in changing mknbi to PIC, position independent code.  It
> > > >may be overkill since are likely to know where things are in memory.
> > > 
> > > If you know a way to generate PIC with gcc that doesn't have a large
> > > overhead in code size or relocation tables, or require a bulky runtime
> > > relocating loader, let us know.
> > 
> > Well...it make the mknbi loader at least 6732 bytes long.  I faked one
> > of the symbols, so there may be more data.  Is it possible to give the
> > loader 8K instead of 6K?  I haven't looked at etherboot, but I'd guess
> > it has a similar bloat of about...good grief...a 90% increase.
> > 
> > So we know that it is expensive.  Are we really that tight on memory?
> > 
> 
> Nevermind.  I found something that describes what needs to be done.
> It's way to much work for something of nominal value.

There are two ways to do PIC on x86.  And I have played with and implemented
both of them.

1) Use -fPIC when you compile and actually change all of the absolute references
   in your code to know about the current load address.  See memtest86-3.0
   for an implemenation.  The more relocations the linker can resolve
   at link time the better.

2) Modify the code to use a protected mode code and data segment with base != 0.
   This is what I have done with etherboot.  If you need to refer to an absolute
   memory location you need a virt_to_phys/phys_to_virt set of calls.  This
   technique is still compatible with the existing
   real_to_prot/prot_to_real stubs in mknbi.  Except for the expense
   of modifying the code this method is not to bad.

Eric