From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tracy Kuhrt To: Ian Lance Taylor Cc: binutils@sourceware.cygnus.com Subject: Re: fx_offset Population Date: Thu, 30 Aug 2001 13:41:00 -0000 Message-id: <3B8EA523.A8C81523@microchip.com> References: <3B8E9C1C.861BE80A@microchip.com> X-SW-Source: 2001-08/msg00700.html 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 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