[x264-devel] Re: Illegal Instruction Crash (OS X/Intel Mac)

Mon Jun 5 04:47:00 CEST 2006

Chris,

Have you tried building this as a .dylib, because what Sam is doing  
in the code below is a "hack" to enable Position Independent Code  
which is necessary for .dylibs, .so's and .bundles on OS X (and  
certainly the x264 module in VLC). Usually errors will commence in  
linking, although they can be suppressed.

As per my email to this thread dated 1/14/2006, I did indicate that a  
CVS build of nasm was necessary for compilation - .rodata support was  
offered later than the version XCode ships with. It looks like the  
PIC hack masks an earlier version of nasm that may or may not have  
errors within it.

I can't seem to find where else Apple may host their version of nasm,  
assuming they do have their own builds now. A commit to nasm CVS  
hasn't been made for 3 months for mach-o output... I'd love to be  
able to put in some true PIC support, but Apple's example of dynamic  
code in their mach-o documentation is still currently PowerPC  
specific ( http://developer.apple.com/documentation/DeveloperTools/ 
Conceptual/MachOTopics/Articles/dynamic_code.html )

- David

On Jun 3, 2006, at 12:51 PM, Chris Walsh wrote:

>
> SVN Revision 449 of x264 took all the '.rodata data align=16'  
> statements out of the various common/i386/*.asm files, and made a  
> macro in i386inc.asm specifically for intel macs.  According to the  
> comment, there apparently was some problem with the nasm version  
> that Apple ships with their developer tools at that time (March  
> 1st, 2006 by the checkin date) that necessitated replacing the  
> "SECTION .rodata align=16" with "SECTION .text".
>
> Apple XCode 2.3 (released a week or two ago) ships with a new  
> version of nasm which gets put in /usr/bin/nasm.  XCode 2.2 nasm -v  
> comes up with "nasm version 0.98.40, compiled Jan 13 2006".   
> Install XCode 2.3, and nasm -v now comes up with "nasm version  
> 0.98.40 (apple computer build 9)".
>
> Apparently this new version of NASM has fixed whatever problem was  
> being addressed with SVN revision 449.  Compiling with SVN revision  
> 449-531 (current at time of writing), results in an "Illegal  
> Instruction", which appears to have something to do with  
> instruction alignments.  However, revision 448 and below compiles  
> and executes fine on an Intel Mac, using Apple's XCode 2.3 toolset.
>
> To get the top of the tree working on your Intel Mac with XCode  
> 2.3, simply comment out the ifdef macho section on line 43-45 in  
> the common/i386/i386.asm file.  It would appear that this MacOS  
> hack is no longer needed, with the caveat that you need to be using  
> XCode 2.3.   Perhaps this can be taken out of the svn tree.
>
> svn 531 code...
>
> ; Name of the .rodata section. On OS X we cannot use .rodata  
> because NASM
> ; is unable to compute address offsets outside of .text so we use  
> the .text
> ; section instead until NASM is fixed.
> %macro SECTION_RODATA 0
>     %ifidn __OUTPUT_FORMAT__,macho
>         SECTION .text
>         fakegot:
>     %else
>         SECTION .rodata data align=16
>     %endif
> %endmacro
>
>
> with an Intel Mac using XCode 2.3...
>
> ; Name of the .rodata section. On OS X we cannot use .rodata  
> because NASM
> ; is unable to compute address offsets outside of .text so we use  
> the .text
> ; section instead until NASM is fixed.
> %macro SECTION_RODATA 0
> ;    %ifidn __OUTPUT_FORMAT__,macho
> ;        SECTION .text
> ;        fakegot:
> ;    %else
>         SECTION .rodata data align=16
> ;    %endif
> %endmacro
>
> All this is doing is putting the i386 assembly code back where it  
> was before March 1st (SVN release 449).
>
> On another note, for anyone using an Intel Mac for work /  
> development on x264, an XCode project is attached (i386 only).  The  
> intent is to put it in build/osx, to be parallel to the build/win32  
> project already there.
>
>
> <osx.tgz>
>
>
>
> On 26-May-06, at 3:16 AM, Rarity wrote:
>
>> x264 crashes in the following manner:
>>
>> <begin quote>
>> $ ffmpeg -i /tmp/test.avi -f rawvideo -s 320x240 - | ./x264 -o ./ 
>> output.mov - 320x240
>> FFmpeg version CVS, Copyright (c) 2000-2004 Fabrice Bellard
>>   configuration:  --prefix=/usr/local --disable-mmx --enable-faac  
>> --enable-mp3lame --enable-x264 --enable-gpl
>>   libavutil version: 49.0.0
>>   libavcodec version: 51.9.0
>>   libavformat version: 50.4.0
>>   built on May 26 2006 07:32:49, gcc: 4.0.1 (Apple Computer, Inc.  
>> build 5250)
>> Input #0, avi, from '/tmp/test.avi':
>>   Duration: 00:00:02.8, start: 0.000000, bitrate: 1228 kb/s
>>   Stream #0.0, 25.00 fps(r): Video: h264, yuv420p, 700x394
>>   Stream #0.1: Audio: mp3, 44100 Hz, stereo, 128 kb/s
>> Output #0, rawvideo, to 'pipe:':
>>   Stream #0.0, 25.00 fps(c): Video: rawvideo, yuv420p, 320x240,  
>> q=2-31, 200 kb/s
>> Stream mapping:
>>   Stream #0.0 -> #0.0
>> Press [q] to stop encoding
>> x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
>> Illegal instruction
>> <end quote>
>>
>> gdb indicates some sort of stack corruption. Additionally, the  
>> following change just after
>> line 54 of 'common/cpu.c' stops prevents x264 from crashing:
>>
>> <begin quote>
>>   x264_cpu_cpuid( 1, &eax, &ebx, &ecx, &edx );
>>
>>     /* NEW*/
>>     return 0;
>>
>>     if( (edx&0x00800000) == 0 )
>>     {
>>         /* No MMX */
>>         return 0;
>>     }
>> <end quote>
>>
>> The latest nightly build of VLC also crashes when attempting to  
>> transcode to H.264.
>>
>> Thanks.
>>
>>
>>
>>
>>
>> -- 
>> This is the x264-devel mailing-list
>> To unsubscribe, go to: http://developers.videolan.org/lists.html
>>
>

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html