[Z80asm-devel] [bugs #10526] Support producing a table of relocations

[H. Peter Anvin]

This mail is an automated notification from the bugs tracker
 of the project: Z80 assembler.

/**************************************************************************/
[bugs #10526] Latest Modifications:

Changes by: 
                H. Peter Anvin <address@hidden>
'Date: 
                Wed 09/29/2004 at 19:16 (GMT)

------------------ Additional Follow-up Comments ----------------------------
If you issue a warning, be a bit careful; sometimes there are legitimate 
reasons to load the low half of a 16-bit number (especially if HI8 is also 
provided.)







/**************************************************************************/
[bugs #10526] Full Item Snapshot:

URL: <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=10526>
Project: Z80 assembler
Submitted by: H. Peter Anvin
On: Tue 09/28/2004 at 20:39

Category:  None
Severity:  5 - Average
Item Group:  None
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open


Summary:  Support producing a table of relocations

Original Submission:  It would be nice to be able to produce a table of 
relocations.  It is basically a list containing (type, offset [,value]) for 
which locations would have to be modified in order to move the code to a 
different location.

In the case of Z80, there are only a few possible relocations:

R_Z80_8            -- absolute 8-bit relocation
R_Z80_16           -- absolute 16-bit relocation
R_Z80_PC8          -- relative 8-bit relocation
R_Z80_HI8          -- high half of an absolute 16-bit value

Out of these, R_Z80_PC8 would only be of interest to linkers, since for a 
finished program they would already be resolved.  R_Z80_HI8 is optional, 
although perhaps useful for things like loading the I register.  It is the only 
relocation which would have to have an additional "value" field (since it's a 
16-bit value, truncated, the source value wouldn't fit in the binary); all the 
other relocations just need to be marked so the data in the binary can be 
shifted appropriately.


Follow-up Comments
------------------


-------------------------------------------------------
Date: Wed 09/29/2004 at 19:16       By: H. Peter Anvin <hpanvin>
If you issue a warning, be a bit careful; sometimes there are legitimate 
reasons to load the low half of a 16-bit number (especially if HI8 is also 
provided.)


-------------------------------------------------------
Date: Wed 09/29/2004 at 12:40       By: Bas Wijnen <shevek>
This sounds like a good idea.  However, currently "the high byte of label" 
would be written as "label >> 8", which would be hard to parse into a 
relocation.  It's not impossible, but it may be easier to add an 
expression-element for it.

Currently, linking parts together can be done by compiling them and including 
each other's label output.  Repeat until nothing changes.  This is of course a 
lot of unneccesary work for the processor, but at least it works.

And of course when one piece of code is relocated by the linker, the code 
calling that should also be changed.  So we'd need import tables and export 
tables.

For proper import tables, variable declaration using "extern" or something may 
be a good idea.  Absolute relocations could then easily be implemented by 
"importing" the start address.  To be able to use the program normally, the 
value should be able to have a non-0 default value, though.

Also, I would prefer to have a "low half of 16 bit value", to be able to 
generate a warning if "absolute 8 bit" falls outside the range (which also 
means it must be known if it's signed or not.)












For detailed info, follow this link:
<http://savannah.nongnu.org/bugs/?func=detailitem&item_id=10526>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/