[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Z80asm-devel] [bugs #10526] Support producing a table of relocations
From: |
H. Peter Anvin |
Subject: |
[Z80asm-devel] [bugs #10526] Support producing a table of relocations |
Date: |
Wed, 29 Sep 2004 15:23:22 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.2) Gecko/20040803 |
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/