bugZ80 assembler - Bugs: bug #10526, Support producing a table of...

 
 

bug #10526: Support producing a table of relocations

Submitter:  H. Peter Anvin <hpanvin>
Submitted:  Tue 28 Sep 2004 08:39:16 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Wed 29 Sep 2004 07:16:45 PM UTC, comment #2: 

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.)

H. Peter Anvin <hpanvin>
Wed 29 Sep 2004 12:40:22 PM UTC, comment #1: 

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.)

 Bas Wijnen <shevek>
Group administrator
Tue 28 Sep 2004 08:39:16 PM UTC, 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.

H. Peter Anvin <hpanvin>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

Only logged-in users can vote.

 

No changes have been made to this item

Back to the top

Copyright © 2024 Free Software Foundation, Inc.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team.
Page source code

Powered by Savane 3.14-f13d.
Corresponding source code