pc386dx exception 6 was Re: 4.6.0pre2 and docs released
joel.sherrill at OARcorp.com
Fri Apr 25 12:38:57 UTC 2003
Angelo Fraietta wrote:
> Angelo Fraietta wrote:
>> Joel Sherrill wrote:
>>> Angelo Fraietta wrote:
>>>> Joel Sherrill wrote:
>>>>> I am in agreement with Ralf's hunch here. including iostream is
>>>>> to be
>>>>> putting some ctor in the system. It has to be doing something
>>>>> that is
>>>>> legal on a vanilla i386 system. It could be because of inline
>>>>> is not i386 pure or incorrect code generation for pure i386 that
>>>>> no one
>>>>> has noticed because most people are Pentium and above for Linux, BSD,
>>>>> We really need to know that address of the illegal instruction so
>>>>> we can
>>>>> figure out where it is coming from. Fixing it then will probably be
>>>> So how do I find the address?
>>> If you don't have visibility with a debugger, then all I know to do
>>> is modify the default exception handler to print the eip somewhere
>>> you can see it.
>>> When I look at _defaultExcHandler in cpukit/score/cpu/i386/cpu.c, it
>>> already is printing eip. Are you sure it isn't there? If it has
>>> scrolled off, move the print with the eip to the end so it is
>>> visible or switch the console to a com port so you have scroll
>> PC 104125
>> The instructions there are
>> 104125: f0 0f c1 05 5c 0d 15 lock xadd %eax,0x150d5c
> In have done an objdump on my working exe and lock xadd is in quite a
> few places.
> If I do an objdump on my exe built with gcc295, lock xadd is nowhere
> at all.
> I did a search on google for lock xadd and in quite a few places it
> says it is an illegal instruction. It is probably a GCC issue
> LOCK <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/lock.html> is
> restricted to certain instructions. The LOCK
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/lock.html> prefix and
> its corresponding output signal should only be used to prevent other
> bus masters from interrupting a data movement operation. The 80386
> always asserts the LOCK
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/lock.html> signal
> during an XCHG
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/xchg.html> instruction
> with memory (even if the LOCK
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/lock.html> prefix is
> not used). LOCK
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/lock.html> may only be
> used with the following 80386 instructions when they update memory:
> BTS <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/bts.html>,BTR
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/or.html>, XOR
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/not.html>, and NEG
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/neg.html>. An
> undefined-opcode exception (interrupt 6) results from using LOCK
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/lock.html> before any
> other instruction.
Thee offending file appears to be
gcc-XXX/libstdc++-v3/config/cpu//i?86/bits/atomicity.h. There is
an i386 and an i486 directory which have the same code for atomicity.h.
I don't know off hand how
each one is selected and for sure the i386 specific version is using
xadd with a lock which is wrong.
Looking at libstdc++-v3/configure.tgt, I think that fixing the code in
the i386/bits/atomicity.h would
be enough to solve this.
I will file a gcc PR once we figure out how to patch the code.
More information about the users