Re: fx_offset Population

[Tracy Kuhrt <Tracy.Kuhrt@microchip.com>]

Ian,

Here is some more detail...

The new target that I am porting is using a COFF format.  I am trying to
place the addend value in the 16-bits that I have for this operand.  Where
the problem comes in is after fixup_segment calls the md_apply_fix3 function
(which divides this addend by 2) it then checks to see that the value it will
be writing is able to fit into 2 bytes.  2147450880 (0x7FFF8000) does not fit
and I get the error "Value of 2147450880 too large for field of 2 bytes at
0".  But a -32768 should fit in 2 bytes.

Does this mean that anywhere that my md_apply_fix3 function uses the
fx_offset field in a calculation it must first convert it back to a signed
value?

Let me know if I can provide some more detail.

Tracy


Ian Lance Taylor wrote:

> Tracy Kuhrt <Tracy.Kuhrt@microchip.com> writes:
>
> > In fix_new_internal, the fx_offset member of the fixP structure is
> > populated with the offset, which is the value from the expressionS
> > structure's'X_add_number.  The problem...
> >
> > X_add_number is an offsetT (which in the end is a signed value).
> > fx_offset is a valueT (which in the end is an unsigned value).
> > When setting fx_offset to X_add_number, X_add_number is converted from a
> > signed value to an unsigned value.  So in my test case, I have the
> > expression . - 65536.  When the fixup is created -65536 is converted to
> > an unsigned 4294901760.
> >
> > What would be the harm of changing fx_offset to be an offsetT?
>
> Probably none.
>
> However, at the level of the assembler, the differences between signed
> and unsigned numbers in relocation offsets are, as far as I know,
> inconsequential.  I understand what you write above, but I don't
> understand what the actual problem is.  Even if you change fx_offset,
> the number is just going to wind up in the addend field of an arelent,
> and that is also unsigned.
>
> Can you explain the real problem?
>
> Ian