Description of problem: The version of the GNU assembler in this binutils has a bug. Since 7.3 is still maintained, an updated binutils package should be released for it that fixes this serious and known bug. This bug definitely prevents people from using newer GCC's with 7.3. But it could also cause existing programs to fail in strange and mysterious ways. For some x86 instructions (such as a 32-bit add of an immediate value to a register), the version that operates on the eax register is 1 byte shorter than the version that operates on any other register. Sadly, as doesn't take this into account when generating relocation offsets. So if such an instruction is used with the eax register and an immediate value that requires a relocation, the area relocated is off by one byte and disaster strikes. The URL above shows a small chunk of C code that if compiled on gcc 3.3 with certain flags will crash. However, this is just way to trigger this bug. It could be triggered any number of other ways. Version-Release number of selected component (if applicable): binutils-2.11.93.0.2-12 How reproducible: Every time Steps to Reproduce: 1. Install/compile gcc-3.3 2. Compile the source code at the URL above with -O3 -fPIC 3. Run it (Alternatively, write any assembly code that uses the 'addl' instruction to add the address of a function in another translation unit to the value in the 'eax' register.) Actual results: Program most likely crashes due to incorrect relocation. Expected results: Relocation is applied correctly, program does not crash. Additional info: This is the C code needed to reproduce the bug. Compile it with GCC-3.3 and the -O3 and -fPIC options. int* i; int& get_x() { return *i; } int main() { int j; i = &j; get_x(); } Again, I stress that while it's easier to reproduce this bug with GCC-3.3, it's not a GCC bug. It's a gas bug that could be triggered by other things as well.
It's been two months with no action. This isn't very difficult to replicate or fix.
I believe this is http://sources.redhat.com/ml/binutils/2002-08/msg00044.html I don't think this is severe enough to warrant an errata though. The thing is, older GCCs don't generate such code and if you build gcc yourself, you should as well binutils it depends on. Or install a distribution which comes with such GCC and where all this is handled (either RHL9/Taroon with gcc 3.2.3-rh or Severen with gcc 3.3.1-rh).
This is a code generation bug in 'as' that can cause programs to mysteriously fail. 7.3 is still supposed to be being maintained. Doesn't that mean known bugs are supposed to be fixed? Yes, I agree it would be more serious if the version of gcc that shipped with 7.3 was known to trigger the bug. But this bug can also be triggered by hand- coded assembly with the gcc that comes with 7.3. If gcc/as is supported, known code generation bugs that can easily and safely be fixed should be fixed. I guess I misunderstood what RedHat means by supported. Known bugs in a supported product should be fixed.