Re: need help resolving symbols using twolevel hints table
Re: need help resolving symbols using twolevel hints table
- Subject: Re: need help resolving symbols using twolevel hints table
- From: Bob Campbell <email@hidden>
- Date: Tue, 14 Sep 2004 11:02:40 -0700
Message: 4
Date: Tue, 14 Sep 2004 00:29:19 -0400
From: "Mike Garey" <email@hidden>
Subject: Re: need help resolving symbols using twolevel hints table
To: email@hidden
Message-ID: <email@hidden>
Content-Type: text/plain; format=flowed
Thanks for the reply Bob, however, I'm still confused as to how you arrived
at symbol number 4347 from printf having an itoc of 1854. I was thinking
that perhaps the tocoff of libSystem + 1854 should equal 4347, but that's
not the case.
My thinking is that it should, but you and I may have different
system libraries. My libSystem.dylib is:
otool -L /usr/lib/libSystem.dylib
/usr/lib/libSystem.dylib:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 71.1.1)
/usr/lib/system/libmathCommon.A.dylib (compatibility version
1.0.0, current version 47.1.0)
I've been reading the dyld sources, and it looks like they
simply use the itoc as an initial starting position from which to begin a
binary search. Although I'm unsure of how they perform a binary search on
what seems like an unsorted list of symbols (because the symbol tables for
mach-o images are not sorted), and if dyld was to sort its internal symbol
list, I can't see how having the itoc would help, as it seems that the itoc
is an index into the unsorted symbol table as it appears in the original
mach-o image.
Actually the symbols are sorted in a very specific way:
local symbols
sorted by module then by address
external defined symbols
sorted by module then by name
undefined symbols (aka imported)
sorted by name
Note if the mach-o file is not a dylib (or is linked in single module
mode) then all of the symbols are treated as if they are in a single
module so they are only sorted by address.
Also the DYSYMTAB contains indexes to the start and number of entries
in each of these three groups.
Actually it is possible that the local symbols are not normally
sorted at all, it might be an artifact of the way I generate the
symbol table.
So anyways, is this itoc value, 1854, simply a suggesting starting point,
and the value 4347 was found by performing a linear search from this index
value?
At index 1854 in the LC_DYSYMTAB is an entry which has the number
4347 which is an index into the n_list in the LC_SYMTAB:
dysymtab_command.tocoff -> dylib_table_of_contents[1854].symbol_index == 4347
symtab_command.symoff -> n_list[4347]
Also, another strange thing I noticed.. When using otool -Hv on a few
different binaries, some show the itoc for printf to be 1854, while some
others show the itoc to be 1855.. Any idea why this would happen? I guess
maybe it depends on when the binary was built?
It might be the difference between the standard libSystem dylib vs
libSystem_debug dylib (or _profile, or as you indicated being
originally build against a different binary).
Also I wrote my own Mach-O disassembler 7 years ago, which I use
instead of Mach-O (it ships with the Metrowerks tools), so I am not
up on all of the options to otool (I use it once in a while), but I
sometimes wish otool would print more info (like the index of the
entry when dumping the TOC) and it might be that I just am not
finding the right option.
Also the TOC is in my linker sources is sorted by name (no module) so
using the itoc index from the linked application provide a good hint
from which to start a binary search looking for the right value.
--
Message Classification
[x] General Business Information
___________________________________________________________________
Bob Campbell email@hidden 408.991.7490
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden