[lld] r198728 - [mach-o] properly extract atom content from subrange of section content

jalin.cwk at foxmail.com jalin.cwk at foxmail.com
Wed Aug 27 22:06:34 PDT 2014

Hello Nick,
    I'm Jalen, a student from SCUT, China. It's very fortunately for me to have the opportunity to contact you. 
    Before watch your the mail list(http://webcache.googleusercontent.com/search?q=cache:D_s11w9oq3IJ:unix.superglobalmegacorp.com/xnu/newsrc/osfmk/mach-o/loader.h.html+&cd=26&hl=zh-CN&ct=clnk&gl=cn), I'm confused with the lack of "size" of symbol table in the Mach-o file. And I found the solution in the "lld/trunk/lib/ReaderWriter/MachO/MachONormalizedFileToAtoms.cpp" you posted in that E-Mail, which note that"Mach-O symbol table does have size in it, so need to scan ahead to find symbol with next highest address." 
    But when I parse out the symbol table in a Mach-O (.dSYM) file (I got the symbol table from the symtab_command and the following nlists) and trying to calculate the size of one global symbol as the same way, I was confused again when I compared the symbol table from the output of dwarfdump (dwarfdump -ae). The end address of the symbol in the symbol table from the dwarfdump is different from the result my program's output. Is there some problem with the symbol table I parsed out? Or is there some other way to work out it? 

Some of the output from my program:
<start address> <section index>    <method>
0x0006d030        1                            ___arclite_objc_autoreleasePoolPop 
0x0006d048        1                            _patch_lazy_pointers 
0x0006d1f0         1                            ___arclite_objc_autoreleasePoolPush

The corresponding part of the output from dwarfdmp:
0x0014a37b: [0x0006d030 - 0x0006d046) __arclite_objc_autoreleasePoolPop 
0x0014a122: [0x0006d048 - 0x0006d1ee) patch_lazy_pointers 
0x0014a3a0: [0x0006d1f0 - 0x0006d212) __arclite_objc_autoreleasePoolPush

So if I use the way in the "MachONormalizedFileToAtoms.cpp" to calculate the end address of the symbol (look ahead to find symbol with next highest address), the result must be different from the output of dwarfdump. And do you know how dwarfdump calculate it?

The Mach-O file (dSYM) I tested above is in the appendix.

Thank you for reading and I'm sincerely looking forward to hear from you soon.

jalin.cwk at foxmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140828/8d6da470/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RqdApp
Type: application/octet-stream
Size: 6270683 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140828/8d6da470/attachment.obj>

More information about the llvm-commits mailing list