[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