Mail Archives: djgpp-workers/2002/11/29/12:07:25
> 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?
It corrects for the offset in the DXE code image from it's zero base to
the main image base. (The DXE will get loaded at different addresses;
and we don't know at DXE link time where "printf" will be in the main image).
Probably the best thing to say is this is the math that makes it work :-)
> BTW you've mispelt absolute as "absolulte" a couple of times.
I'll try to fix those things.
> Are you planning to support 2.03 DXEs with the new loader code? (I'm just
> asking out of curiousity.)
Old DXEs are completely backwards compatible; you can also create old
style DXEs and use them on previous versions.
> 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.
Thanks - it's a hack or two away from being final, but I'm looking for
early comments at this point to see if I'm missing anything.
> You could free import_symndx and import_name at the end of dxegen's main,
Not really necessary because of the way our cleanup code works, but it
does tidy up the lose ends for a small speed cost.
- Raw text -