site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Nope. You'd have to declare the functions non-static. Yep. See above. Not a public API, as has been explained. Feel free to file a bug requesting that it be made public. -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Mar 24, 2009, at 9:51 AM, Ethan Tira-Thompson wrote: On Mar 24, 2009, at 2:59 AM, Terry Lambert wrote: Personally, I'd popen atos. Yeah, for my own code that's what I'm going to wind up doing. For reference, I've realized that atos's ~10 second CPU burn only occurs for the first lookup (must be doing some kind of preprocessing of the entire symbol table). So if I keep the atos process running, then subsequent lookups are quite fast... Regardless, calling out to atos seems like a hack (and is non- portable), I'd rather dladdr worked reliably. I'm still trying to determine whether this dladdr behavior warrants a bug report. dladdr() is a runtime function. The non-hacky way to do this is to use the symbolication framework, if you are an Apple employee, since it is not a public API, or to use a tool which is linked against the symbolication ramework, like atos. Alternately, you can get the object file names via _dyld_image_count() and iterate the count calling _syld_get_image_name(), and then grovel the LC_DYSYMTAB yourself, using your own knowledge of Mac-o internals. It's clear what is happening is dladdr is skipping all of the 't' (local text section?) symbols, and only returning the 'T' (external text section?) symbols. Spot checking the correctly returned symbols suggests they are all 'T' symbols. I'm guessing the 't' symbols are static-linked in the executable, and 'T' symbols are dynamically loaded from a build directory somewhere, and thus dladdr is only reporting the 'T' symbols as it ignores static linkage. Does that sound right? The 'T' symbols are external text section symbols, while the 't' symbols are local (non-external, and therefore non-externally linkable or callable) text section symbols. The dl* functions are interfaces to the dynamic linker, and are expected to be used to provide runtime linkage. Since you can't do runtime linkage of the symbols in question, they aren't visible to the dl* routines. One option is to not declare them static. The other option is to look them up in the LC_DYSMTAB or use a tool that can do that lookup for you, instead of a library routine that illegal to link to. If so, how can I force all my symbols to be external/dynamic? I suppose I could link everything into a .dylib and then have just main() be in the actual executable, but perhaps there's an easier way if I only care about development builds. Smells like ZeroLink. Alternatively, I suppose I could figure out what nm is using and emulate that in my code... sounds even more hairy than popen atos though, probably a bunch of manual mach-o parsing...? Finally, it's fair that dladdr only handles dynamic symbols, but perhaps the root issue to take up with Apple is that backtrace_symbols should be based on something more generic that handles static symbols as well, instead of basing it on dladdr. They should be able to make backtrace_symbols interface with atos's codebase instead. This email sent to site_archiver@lists.apple.com