[PATCH] [MachO] MachOWriter generates bad indirect symbol tables when sections are split

[Kuperstein, Michael M]

Hi,

I just ran into a bug in the MachOWriter, and I'm not 100% certain what the fix should look like.
The basic scenario is an .s file which has a split .non_lazy_symbol_pointer section, e.g. something like this:

.non_lazy_symbol_pointer
L_foo$non_lazy_ptr:
     .indirect_symbol _foo
     .long 0
.section __IMPORT,__jump_table, symbol_stubs,self_modifying_code,5
L_func:
    .indirect_symbol _func
    .byte 0x00, 0x00, 0x00, 0x00, 0x00
L_bar$non_lazy_ptr:
     .indirect_symbol _bar
     .long 0

The three symbols are collected into the IndirectSymbols list of the MCAssembler, in their original order (foo, func, bar).
When a MachO object file is generated, two sections are created, one of type S_NON_LAZY_SYMBOL_POINTERS and one of type S_SYMBOL_STUBS. 
Each of the section descriptors contains an index into the indirect symbol table which signifies the start of the (sequential!) list of symbols that belong to this section. This index is determined based on the first (in IndirectSymbols) symbol that belongs to this section. The symbols are then emitted into the object in their order in IndirectSymbols. So for the snippet above, the result will be:

Indirect symbol table:
[foo, func, bar]

S_NON_LAZY_SYMBOL_POINTERS: Symbols start at index 0, and it has 2 symbols. (So the symbols for this section are "foo, func" instead of "foo, bar")
S_SYMBOL_STUBS: Symbols start at index 1, and it has 1 symbol. (So the only symbol for this section is - correctly - "func")

I'm attaching a patch that generates the right output, but is clearly not the right thing to do, design-wise. 
Can anyone familiar with MC/MachO advise regarding a better fix? 

)This patch also breaks some MachO tests that expect a very specific structure from the output object files, I'll fix them with the final patch)

Thanks,
   Michael 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: macho.patch
Type: application/octet-stream
Size: 1406 bytes
Desc: macho.patch
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130130/dc01b950/attachment.obj>