* fx_offset Population
@ 2001-08-30 13:03 Tracy Kuhrt
2001-08-30 13:08 ` Ian Lance Taylor
0 siblings, 1 reply; 5+ messages in thread
From: Tracy Kuhrt @ 2001-08-30 13:03 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fx_offset Population
2001-08-30 13:03 fx_offset Population Tracy Kuhrt
@ 2001-08-30 13:08 ` Ian Lance Taylor
2001-08-30 13:41 ` Tracy Kuhrt
0 siblings, 1 reply; 5+ messages in thread
From: Ian Lance Taylor @ 2001-08-30 13:08 UTC (permalink / raw)
To: Tracy Kuhrt; +Cc: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fx_offset Population
2001-08-30 13:08 ` Ian Lance Taylor
@ 2001-08-30 13:41 ` Tracy Kuhrt
2001-08-30 13:59 ` Ian Lance Taylor
0 siblings, 1 reply; 5+ messages in thread
From: Tracy Kuhrt @ 2001-08-30 13:41 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fx_offset Population
2001-08-30 13:41 ` Tracy Kuhrt
@ 2001-08-30 13:59 ` Ian Lance Taylor
2001-08-30 14:11 ` Tracy Kuhrt
0 siblings, 1 reply; 5+ messages in thread
From: Ian Lance Taylor @ 2001-08-30 13:59 UTC (permalink / raw)
To: Tracy Kuhrt; +Cc: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: fx_offset Population
2001-08-30 13:59 ` Ian Lance Taylor
@ 2001-08-30 14:11 ` Tracy Kuhrt
0 siblings, 0 replies; 5+ messages in thread
From: Tracy Kuhrt @ 2001-08-30 14:11 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2001-08-30 14:11 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-30 13:03 fx_offset Population Tracy Kuhrt
2001-08-30 13:08 ` Ian Lance Taylor
2001-08-30 13:41 ` Tracy Kuhrt
2001-08-30 13:59 ` Ian Lance Taylor
2001-08-30 14:11 ` Tracy Kuhrt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).