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

[Chris Walsh]

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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: osx.tgz
Type: application/octet-stream
Size: 4792 bytes
Desc: not available
Url : http://mailman.videolan.org/pipermail/x264-devel/attachments/20060603/f806f347/attachment.obj 
-------------- next part --------------



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
>