Home Original page

offset_in_range() question

Jan Beulich jbeulich@suse.com
Mon Jul 13 12:50:48 GMT 2020 
H.J.,

the dependency on presence of an address size override, when the
function is also used on immediate operands, struck me as being
a possible source for problems. On 2009-09-15 you've made two
changes to the construct in question, but I wonder whether even
back then this code wasn't already dead. When, after quite a bit
of playing, I couldn't come up with any immediate that this
would go wrong on, I thought I'll give a try to removing that
code altogether. And indeed - no fallout. Looking more closely
then suggested that respective logic in optimize_imm() and
optimize_disp() are already arranging for values to never need
further massaging here.

Do you agree that the code could be removed (see patch below in
case of any uncertainty about what block of code I mean), or are
you aware of things that might break this way?

As an aside, I don't think the handling of out-of-range
immediates is quite correct, but I'll get to this in more detail
after thinking some more on possible solutions.

Jan

--- a/gas/config/tc-i386.c
+++ b/gas/config/tc-i386.c
@@ -2539,14 +2539,6 @@ offset_in_range (offsetT val, int size)
     default: abort ();
     }
 
-#ifdef BFD64
-  /* If BFD64, sign extend val for 32bit address mode.  */
-  if (flag_code != CODE_64BIT
-      || i.prefix[ADDR_PREFIX])
-    if ((val & ~(((addressT) 2 << 31) - 1)) == 0)
-      val = (val ^ ((addressT) 1 << 31)) - ((addressT) 1 << 31);
-#endif
-
   if ((val & ~mask) != 0 && (val & ~mask) != ~mask)
     {
       char buf1[40], buf2[40];
More information about the Binutils mailing list