Mail Archives: djgpp-workers/2002/11/29/05:48:46
Hello.
Charles Sandmann wrote:
>
> I've been hacking on DXEs. In particular, I want to be able to call I/O
> and other lib routines from DXEs; this will allow us to put big libraries
> such as libiconv there.
Cool.
> Included below are my current working patches for comments. There is a
> new switch "-i" which enables the new behavior. If you use it, it does
> not complain about unresolved symbols, it assumes they will be fixed up
> at _dxe_load time; it then puts the required fixups at the end of the image.
>
> _dxe_load has a corresponding change to check for this new section and
> fix up values. It needs a fixup vector which is assumed to be set
> externally before calling _dxe_load in a wrapper. This fixup vector
> is currently written to the screen by dxegen; it would be linked into
> images loading the DXE (solves the strip issue).
[snip]
I was trying to work out what the line:
j = _dxe_fixup[i-1] - (int)data; /* Relative - code */
does. Is it because we added (int)data in the initial pass of the relocation
table, but now we want to remove it, because the symbol is not in the DXE (in
the code read into data)? Is the fixup in this case the relative address in
the main image? How does the absolute (data) case work? If the address is
absolute, why does the code add it to an offset?
BTW you've mispelt absolute as "absolulte" a couple of times.
Are you planning to support 2.03 DXEs with the new loader code? (I'm just
asking out of curiousity.)
I don't know much about COFF (I'm extrapolating from how dxegen/dxeload
currently work), but the non-COFF parts of the patch looked fine to me. You
could free import_symndx and import_name at the end of dxegen's main, though.
Bye, Rich =]
--
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]
- Raw text -