[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: |
Bas Wijnen |
Subject: |
[Z80asm-devel] [bugs #10526] Support producing a table of relocations |
Date: |
Wed, 29 Sep 2004 09:13:25 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040917 Firefox/0.9.3 |
This mail is an automated notification from the bugs tracker
of the project: Z80 assembler.
/**************************************************************************/
[bugs #10526] Latest Modifications:
Changes by:
Bas Wijnen <address@hidden>
'Date:
Wed 09/29/2004 at 12:40 (Europe/Amsterdam)
------------------ Additional Follow-up Comments ----------------------------
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.)
/**************************************************************************/
[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 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/