pc386dx exception 6 was Re: 4.6.0pre2 and docs released

[Joel Sherrill]

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 
>>>>> bound
>>>>> to be
>>>>> putting some ctor in the system.  It has to be doing something 
>>>>> that is
>>>>> not
>>>>> legal on a vanilla i386 system.  It could be because of inline 
>>>>> assembly
>>>>> that
>>>>> 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,
>>>>> etc.
>>>>>
>>>>> 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
>>>>> striaghtforward.
>>>>>
>>>> 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
>>> history.
>>>
>> 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
>
 From http://webster.cs.ucr.edu/Page_TechDocs/Doc386/s15_06.html.

> 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/btr.html>,BTC 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/btc.html>,XCHG 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/xchg.html>,ADD 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/add.html>,ADC 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/adc.html>,SUB 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/sub.html>,SBB 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/sbb.html>,INC 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/inc.html>,DEC 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/dec.html>,AND 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/and.html>,OR 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/or.html>, XOR 
> <http://webster.cs.ucr.edu/Page_TechDocs/Doc386/xor.html>,NOT 
> <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.

--joel