Mach-O and section .data align issue

[nobody]

I have encountered an issue that;
Under Mach-O, "section .data" ignores align directive. (using nasm 2.5.1)

I guess that:
- if "align" is used at data section, pre-padding is required for Mach-O object file.

//

1)With meaningless sample asm code following, line 1: align directive is ignored:

section .data align=16
;align 16
hello db 'Hello World','$'
;align 16
const0 dw 1,2,3,4
;align 16
const1 dw 5,6,7,8

section .text
_start:
    mov eax, 1
    mov ebx, 2
    int 80h

;align 16
;   times 8 dw 0

$ nasm -fmacho -o a.o a.asm ; nm a.o
00000000 t _start
00000012 d const0
0000001a d const1
0000000c d hello

//

2)Uncomment line 2, 4, 6, "align=16", then each data is placed at every 16byte, but not aligned yet.

$ nasm -fmacho -o a.o a.asm ; nm a.o
00000000 t _start
0000001c d const0
0000002c d const1
0000000c d hello


3)Uncomment last two line, it finally align objects:
nasm -fmacho -o a.o a.asm ; nm a.o
00000000 t _start
00000030 d const0
00000040 d const1
00000020 d hello

//

[H. Peter Anvin]

Hello there,

We are sadly lacking a Mach-O maintainer at the moment.  We are pretty desperately looking (and one of our regular contributors even did a lot of work toward Mach-O64 support), but haven't found anyone willing and able to step up and finish the job.

[kakace]

Hello,
If I'm not mistaken, the offsets listed in the various cases are consistent with the exact location of the corresponding datas in the final object file. As far as I can tell, the "section .data align=16" directive tells the loader to align the datas in memory, and not to align the datas in the object file. Therefore, your datas come at offset $0C in the object file because that's the size of the ".text" section until you pad the ".text" section to make its length an even multiple of 16.
In any case, the data section is aligned to a 16-byte boundary at load time as expected (the data section header does contain the correct alignment value) so I can't see how this was an issue for you.

[kakace]

Update :
The real culprit seems to be the linker, and more precisely in the way it coalesces the sections. Experiments show that the value of the first symbol is appended right after the preceeding section, irrespective of its original offset. But then the following datas are aligned based on their respective offsets, as if it was assumed the section (in the original object file) is already aligned.
The output of "otool -dv" shows it all :

test1.o:
(__DATA,__data) section
0000000a          48 65 6c 6c 6f 20 57 6f 72 6c 64 24 90 90 90 90
0000001a          01 00 02 00 03 00 04 00 90 90 90 90 90 90 90 90
0000002a          05 00 06 00 07 00 08 00

Once linked with another (short) object file to build an executable, we get :
test:
(__DATA,__data) section
00002000   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00002010   00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00002020   48 65 6c 6c 6f 20 57 6f 72 6c 64 24 90 90 90 90
00002030   00 00 00 00 00 00 00 00 00 00 01 00 02 00 03 00
00002040   04 00 90 90 90 90 90 90 90 90 05 00 06 00 07 00
00002050   08 00

where the datas pointed to by "const0" and "const1" are now at offsets 0x2020+0x1A and 0x2020+0x2A respectively, instead of 0x2020+0x10 and 0x2020+0x20 as suggested by a quick look at test1.o. Ten padding bytes have been unexpectedly inserted, thus breaking the alignment.