Re: An old gas bug

Re: An old gas bug

[H.J. Lu]

> gas isn't my responsibility, but I think this fix is wrong.  It
> appears to assume that the field holds a signed value.  You can't make
> that assumption in the machine independent file write.c.  Suppose the
> field were intended to hold an unsigned value, and the user tried to
> put 0x80 in it?
> 

That is true. But, at least my patch won't generate bogus code :-(.

> I think this sort of thing needs to be checked in md_apply_fix.
> 
> Ian
> 


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: An old gas bug

[H.J. Lu]

> 
> | Hi,
> | 
> | This is a very old bug date back to 1.38.1. The reason no one really
> | cares is gcc won't generate that kind of code, i.e., jump out of range.
> | When some Linux people were working on X11R5, they used an Intel x86
> | branch/loop instruction, jcxz, which has only byte displacements in
> | the hand coded asm code. The AT&T as worked fine with expansion. But
> | gas 1.38.1 generated some bogus codes. I fixed the bug for them. I
> | think it is correct. The test case is very easy to produce. Please let
> | me know if you need one.
> 
> While it should be certainly fixed in the assembler, the X11 code
> should also replace the jcxz instruction with a compare against 0 and
> jmp sequence, since that is faster on anything but an original 386.
> See the optimization guides in the 486/pentium manuals.
> 
> 

After I told them that, they have then changed the code.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

An old gas bug

[Michael Meissner]

| Hi,
| 
| This is a very old bug date back to 1.38.1. The reason no one really
| cares is gcc won't generate that kind of code, i.e., jump out of range.
| When some Linux people were working on X11R5, they used an Intel x86
| branch/loop instruction, jcxz, which has only byte displacements in
| the hand coded asm code. The AT&T as worked fine with expansion. But
| gas 1.38.1 generated some bogus codes. I fixed the bug for them. I
| think it is correct. The test case is very easy to produce. Please let
| me know if you need one.

While it should be certainly fixed in the assembler, the X11 code
should also replace the jcxz instruction with a compare against 0 and
jmp sequence, since that is faster on anything but an original 386.
See the optimization guides in the 486/pentium manuals.

An old gas bug

[H.J. Lu]

Hi,

This is a very old bug date back to 1.38.1. The reason no one really
cares is gcc won't generate that kind of code, i.e., jump out of range.
When some Linux people were working on X11R5, they used an Intel x86
branch/loop instruction, jcxz, which has only byte displacements in
the hand coded asm code. The AT&T as worked fine with expansion. But
gas 1.38.1 generated some bogus codes. I fixed the bug for them. I
think it is correct. The test case is very easy to produce. Please let
me know if you need one.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com
----
Tue Aug 16 18:48:10 1994  H.J. Lu (hlu@nynexst.com)

	* write.c (fixup_segment): fix the displacement range
	  checking. "add_number" may be signed and is of type int.
	  We only shift by size * 8 - 1.

*** gas/write.c	Thu Jul 14 14:57:47 1994
--- gas/write.c.new	Tue Aug 16 18:47:11 1994
***************
*** 2195,2202 ****
  		 half-way operations should both be defined.  And the
  		 compiler should be able to combine them if it's valid on
  		 the host architecture.  */
! 	      mask <<= size * 4;
! 	      mask <<= size * 4;
  	      if ((add_number & mask) != 0
  		  && (add_number & mask) != mask)
  		{
--- 2195,2201 ----
  		 half-way operations should both be defined.  And the
  		 compiler should be able to combine them if it's valid on
  		 the host architecture.  */
! 	      mask <<= size * 8 - 1;
  	      if ((add_number & mask) != 0
  		  && (add_number & mask) != mask)
  		{