fx_offset Population

fx_offset Population

[Tracy Kuhrt]

In working on testing a new port, I found a problem...

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?

Tracy

Re: fx_offset Population

[Ian Lance Taylor]

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

Re: fx_offset Population

[Tracy Kuhrt]

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

Re: fx_offset Population

[Ian Lance Taylor]

Tracy Kuhrt <Tracy.Kuhrt@microchip.com> writes:

> 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?

Yes, md_apply_fix3 must apply any relocation changes using the correct
type of arithmetic.  In this case, it presumably must use signed
division.

Always making fx_offset signed is no more correct than always making
it unsigned.  Either way, md_apply_fix3 is responsible for doing the
right thing.

Ian

Re: fx_offset Population

[Tracy Kuhrt]

Ian,

Great!  Thanks for helping me figure this one out.  Agree that it is better to fix
the root problem than just the symptom.

Tracy


Ian Lance Taylor wrote:

> Tracy Kuhrt <Tracy.Kuhrt@microchip.com> writes:
>
> > 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?
>
> Yes, md_apply_fix3 must apply any relocation changes using the correct
> type of arithmetic.  In this case, it presumably must use signed
> division.
>
> Always making fx_offset signed is no more correct than always making
> it unsigned.  Either way, md_apply_fix3 is responsible for doing the
> right thing.
>
> Ian