2/2 
|
[PATCH] GCC: split sfCC+bX
by Unknown on Mar 16, 2004 |
Not available! | ||
|
Johan Rydberg wrote:
Scott Furman sfurman@rosum.com> wrote:
: The linker already propagates carry bits from a 'lo(sym)' field to the
: nearest preceding 'hi(sym)' field. (This is necessary because the
: values of symbols change each time an object file is relocated and the
: or32 linker uses REL-style relocation, in which the relocation offsets
: are embedded in the instructions rather than in a separate section.)
I did a small test. By putting the data segment at 0xfff00 forcing
negative values into the low order bits. All relocations is done
on the object "bar", located at 0xfff00.
objdump output:
01000074 :
1000074: 18 60 00 0f l.movhi r3,0xf
1000078: 84 63 ff 00 l.lwz r3,0xffffff00(r3)
Low order bits sign extended, no carry from lower bits to upper.
EA result: 0xf0000 + -256 = 0xeff00. Invalid address!
Just to be clear, I wasn't saying that the linker already handled this case - just that it already propagated carry from a lo(sym) relocation to a preceding hi(sym) relocation. As you say, if you wanted to handle both unsigned and signed lo(sym) variants, you would need a way for the linker to modify the hi(sym) relocation for the latter type. This could be handled by introducing a different relocation record type. -Scott |
|||
2/2