[MiNT] DR relocations (for lib converter)

["Guido Flohr" <gufl0000@stud.uni-sb.de>]

Hi,

I finally had time today to write that library (and object file) converter
I have promised here.  But I must have missed something about the way
relocation info is stored in DR binaries.

If there are no unresolved references to external symbols (like in
standard GEMDOS program files) the thing is clear.  The relocation table
is more or less an array of offsets into the program image in memory and
at these offsets, the text start address is added to the contents.

But how to code relocation against an external symbol?  Say we've got an
external symbol "_printf" that is referenced at offset 0x456 in the text
segment.  How the heck can the linker find out that "_printf" is
referenced there?  The only way I could think of would be:

	- Write 0x456 into the relocation table.
	- Write the file offset (to the beginning of TEXT or to the 
	  beginning of the file?) of symbol "_printf" at offset 0x456
	  into the file so that the linker has a chance to find out
	  which symbol is referenced.

That would lose for pc-relative relocations, and for relocations against a
segment (or should I simply add a symbol "etext" with value 0 and "edata"
with value N_DATOFF(exec) then?)

The next problem are set elements and indirect symbols.  I currently
discard them silently.  Any better idea?

And for weak symbols?  One possibility would be to check if a weak and a
regular symbol have the same value and belong to the same segment and then
replace the regular symbol's name with the name of the weak symbol with
the same value.  Example: I come across a symbol `___strtok_r' which is
defined and of type N_TEXT | N_EXT.  There is another symbol `_strtok_r'
of type N_WEAKT and with the same value as `___strtok_r'.  I would then
rename `___strtok_r' to `_strtok_r'.  This will work most of the time (and
would cause a lot of extra work for me) but it will lose if I find more
then one weak symbol with the same value as `___strtok_r'.  Another
possibility is to ignore the problem and leave it to the library user to
write a header file with appropriate defines (`#define strtok_r
__strtok_r') but that would require some knowledge of the internals of the
library.  I would prefer the second solution.   The library user can
always run the nm program over the library to find out what symbol
`strtok_r' is a weak alias for.

Any help is appreciated!

Guido
-- 
http://stud.uni-sb.de
mailto:gufl0000@stud.uni-sb.de
     \   |__
      ####  \ /    Total solar eclipse of 1999 August 11
    ######## |_    over Saarbrücken/Germany.
    ######## |     Countdouwn: 26d13h31m40s.
      ####__/ \
     /   |