[XviD-devel] Mach-O and SECTION .rodata

David DeHaven dave at sagetv.com
Sat Dec 6 23:47:43 CET 2008


> After a few hour search, I have found
> - <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2008-August/015984.html
>>
>
> Directive ALIGN for SECTION .rodata may not function well - under
> "some" MacOS X; at least my mac.
> (It seems to be, not yasm/nasm issue though... by ld64?)

I'm going to go out on a limb here and say ld64 is doing exactly what  
it's supposed to do and the bug is in the mach-o object code in nasm/ 
yasm.


A note in yasm/modules/objfmts/macho/macho-objfmt.c:
   2.3) section/data alignment
        Normally, you specify sections with a specific alignment
        and get your data layed out as desired. Unfortunately, the
        linker in MacOS X seems to ignore the section alignment  
requests.
        The workaround is an explicit alignment at the end of the text  
section.

        section .text
         movdqa xmm0,[_foo wrt rip]

         align 16
        section .data align=16
         _foo dw 32,32,32,32,32,32,32,32

        FIXME: perform that operation implicitly!


If it was just ld64, then I would think gcc would exhibit the same  
problem with __attribute__((aligned(16))).

Observe:
cat > aligntest.c << EOF
#include <stdio.h>
int somedata[16] __attribute__((aligned(16))) =  
{0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15};
int main(int argc, char **argv)
{
     printf("somedata is at %p\n", somedata);
     return 0;
}
EOF

compiled (gcc -c -o aligntest.o aligntest.c; gcc -o aligntest  
aligntest.o) and run returns:
somedata is at 0x2020


otool -lv aligntest.o shows the data section:
Section
   sectname __data
    segname __DATA
       addr 0x00000590
       size 0x00000040
     offset 1884
      align 2^4 (16)
     reloff 0
     nreloc 0
       type S_REGULAR
attributes (none)
  reserved1 0
  reserved2 0

otool -lv aligntest shows it's ultimate data section:
Section
   sectname __data
    segname __DATA
       addr 0x00002000
       size 0x00000060
     offset 4096
      align 2^4 (16)
     reloff 0
     nreloc 0
       type S_REGULAR
attributes (none)
  reserved1 0
  reserved2 0


You can see the section is to be loaded at a 16 byte aligned address  
in the object file, yasm does not do this per it's note above. ld64 is  
preserving this alignment when it brings all the section data together.

Indeed, otool -lv fdct_sse2_skal.o shows:
Section
   sectname __const
    segname __DATA
       addr 0x00000b2a
       size 0x00000330
     offset 3102
      align 2^4 (16)
     reloff 0
     nreloc 0
       type S_REGULAR
attributes (none)
  reserved1 0
  reserved2 0

And when built into xvid_bench, the tan2 array is (eventually) being  
loaded at 0xa1bea which is exactly the same alignment as the original  
object file, so ld64 is once again preserving the original alignment  
as it should.

What ld64 is doing is preserving the _structure_ of the data section,  
which considers BOTH the load address and the alignment value. It's  
perfectly acceptable to have a load address that isn't 16 byte aligned  
but have 16 byte alignment, that tells ld64 that the final location  
must preserve the lower 4 bits of the original address when it figures  
out where it's final resting place is.

The only reason you're getting away with using .text is because .text  
sections always seem to land on a 16 byte boundary.


I'm playing with yasm now to see if the problem can be corrected  
there... I suspect if I simply force the data section to land on an  
address that is properly aligned, then ld64 will continue doing the  
right thing and this will start working properly. Might take some time  
as I'm just now delving into the bowels of yasm :)

-DrD-



More information about the Xvid-devel mailing list