This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Gas, 0F 0B opcodes ??
- To: binutils at sources dot redhat dot com
- Subject: Gas, 0F 0B opcodes ??
- From: Henrik Witt-Hansen <bean at daisy dot net>
- Date: Fri, 12 Jan 2001 12:25:44 +0100
- Organization: Daisy Net A/S
Hi. New to the list, question may have been answered before, sorry!.
In that case, just point me to the right place....
I am working on a development board with an AMD SC520 processor.. AMD
claims that it is a 486, but it does _not_ handle the 0F 0B opcode,
(which is handled fine by other 486's i have tested on).
The problem came into the light with Linux kernel >=2.3.23 (new mm
subsystem), where Gas generates the 0F 0B instruktion ao. from the
mm/bootmem.c file..
I do not see the reason for this opcode (I think it has recently been
assigned mnemonic UD2??), and Gas _does_ put a '#APP' in front of it..
But never the less, it still goes into the linked output (even when
using 386 as target platform)..
What happens is, that the processor generates an 'invalid opcode' int,
which is then handled by the 'ignore_int' function (this is early in the
boot), but the iret does _not_ increment eip (as expected when we have
an unknown opcode). Result, the kernel is stuck..!
Since AMD clearly will deny that this is a bug, i need to make sure that
this instruction does not appear in the output...
How to do that?? (and why does the instruction appear after all?)
Regards.. Henrik
--
** Henrik Witt-Hansen - System Developer - (+45) 2840 8502 **
*** Dixa Net (UK) Ltd. - Enrum Castle, 341 Vedbaek Strandvej ***
** DK-2950 Vedbaek - (+45) 4589 4900 - http://www.dixa.net **