March 2009 - Darwin-dev - lists.apple.com

Re: How to find the architecture for a mach-o file?
by Axel Luttgens 25 Mar '09

25 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Le 25 mars 09 à 13:43, Karan, Cem (Civ, ARL/CISD) a écrit : dyld: Library not loaded: /usr/lib/libexpat.1.dylib Referenced from: /usr/local/bin/dot Reason: no suitable image found. Did find: /usr/lib/libexpat.1.dylib: mach-o, but wrong architecture <more lines like the above follow> Using otool -aSfh, I get the following: You already got some suggestions; anyway, here's another one: otool -hV -arch all /usr/lib/libexpat.1.dylib HTH, Axel _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Hi all, I'm currently trying to install expat on my machine to support graphviz (http://www.graphviz.org) but I keep running into an error where dot (part of graphviz) complains that it can't link with libexpat.dylib because of the following: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedface 7 3 0x00 6 11 1208 0x00100085 The problem is that I have no idea what the cputype and subtype numbers mean. Anybody with any ideas? In fact, any ideas on how to fix this problem? This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to find the architecture for a mach-o file?
by Chris Ridd 25 Mar '09

25 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 25 Mar 2009, at 12:43, Karan, Cem (Civ, ARL/CISD) wrote: Using otool -aSfh, I get the following: Does <mach/machine.h> help? Cheers, Chris _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedface 7 3 0x00 6 11 1208 0x00100085 The problem is that I have no idea what the cputype and subtype numbers mean. Anybody with any ideas? In fact, any ideas on how to fix this problem? This email sent to site_archiver(a)lists.apple.com

1 0

Re: How to find the architecture for a mach-o file?
by Jonas Maebe 25 Mar '09

25 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On 25 Mar 2009, at 13:43, Karan, Cem (Civ, ARL/CISD) wrote: Using otool -aSfh, I get the following: Jonas _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedface 7 3 0x00 6 11 1208 0x00100085 The problem is that I have no idea what the cputype and subtype numbers mean. Anybody with any ideas? $ file /usr/lib/libexpat.1.dylib /usr/lib/libexpat.1.dylib: Mach-O universal binary with 4 architectures /usr/lib/libexpat.1.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc /usr/lib/libexpat.1.dylib (for architecture ppc64): Mach-O 64-bit dynamically linked shared library ppc64 /usr/lib/libexpat.1.dylib (for architecture i386): Mach-O dynamically linked shared library i386 /usr/lib/libexpat.1.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64 In fact, any ideas on how to fix this problem? It depends on the cause, but if it does not contain all necessary architectures: probably reinstall (possibly by manually extracting it from some OS installer package, or copying it over from another machine). This email sent to site_archiver(a)lists.apple.com

1 0

How to find the architecture for a mach-o file?
by Karan, Cem (Civ, ARL/CISD) 25 Mar '09

25 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcmtRzwq2yrNOv0NT9q6rIjTE+O59A== Thread-topic: How to find the architecture for a mach-o file? Hi all, I'm currently trying to install expat on my machine to support graphviz (http://www.graphviz.org) but I keep running into an error where dot (part of graphviz) complains that it can't link with libexpat.dylib because of the following: dyld: Library not loaded: /usr/lib/libexpat.1.dylib Referenced from: /usr/local/bin/dot Reason: no suitable image found. Did find: /usr/lib/libexpat.1.dylib: mach-o, but wrong architecture <more lines like the above follow> Using otool -aSfh, I get the following: Mach header magic cputype cpusubtype caps filetype ncmds sizeofcmds flags 0xfeedface 7 3 0x00 6 11 1208 0x00100085 The problem is that I have no idea what the cputype and subtype numbers mean. Anybody with any ideas? In fact, any ideas on how to fix this problem? Thanks, Cem Karan _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: access / eaccess
by Stéphane Sudre 25 Mar '09

25 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 24, 2009, at 11:10 PM, Terry Lambert wrote: Thanks for the detailed answer. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Mar 24, 2009, at 4:48 AM, Stéphane Sudre wrote: Is there an equivalent to the eaccess function in Darwin? Generally, no, since it's not really a useful operation, which is why it's not part of the POSIX standard. It will also opt you out of directory services support for more than 16 groups [...] changing all the network file system protocols out there, and almost all of the filesystems themselves. The best policy is to try to do something, and if it fails, report the error. This email sent to site_archiver(a)lists.apple.com

1 0

Re: dladdr/backtrace_symbols return incorrect symbol names
by Steve Checkoway 25 Mar '09

25 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Mar 24, 2009, at 9:51 AM, Ethan Tira-Thompson wrote: Yeah. -- Steve Checkoway "Anyone who says that the solution is to educate the users hasn't ever met an actual user." -- Bruce Schneier _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com 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? 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...? I've posted code to this list (or maybe xcode-users or unix-porting) that pretty much does what Terry suggested in one of his replies: playing with LC_DYSYMTAB. It gets the address of noninlined static symbols as long as you don't strip the symbol names. smime.p7s

1 0

Re: dladdr/backtrace_symbols return incorrect symbol names
by David Elliott 25 Mar '09

25 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Ethan, -Dave On Mar 24, 2009, at 7:21 PM, Ethan Tira-Thompson wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… If the overhead of atos invocation is too high, why not popen atos once in "r+" mode with no address arguments? Using the bidirectional pipe write an address and a line feed then read a symbol and a linefeed as many times as you wish. This is described in its manpage as "interactive" mode. C. Open 'atos' source or publicize the "symbolication" framework so we can emulate/customize atos functionality. popen()'ing a call to atos is kind of ugly, but of bigger concern is that atos does some kind of preprocessing of the entire symbol table, and for a large project like ours this takes ~10 seconds per launch of atos. So even if we have to stick with calling out to atos, it would be more usable if atos could be set to only process what was needed for the trace at hand instead of running through the entire symbol table right off the bat. This email sent to site_archiver(a)lists.apple.com

1 0

Re: dladdr/backtrace_symbols return incorrect symbol names
by Ethan Tira-Thompson 24 Mar '09

24 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com OK, thanks for helping to nail down what's going on. I've submitted a bug to Apple, #6718509: ------------------------------------------------------------------- When symbols are locally linked, the dladdr function on which backtrace_symbols is based will return the nearest preceding *external* symbol, which is often misleading, and basically renders dladdr/backtrace_symbols useless due to unreliability. Solutions: A. On linux there is a -rdynamic option for gcc, specifically to address this symbol lookup issue: -rdynamic Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of "dlopen" or to allow obtaining backtraces from within a program. So we could use something similar for OS X to force the linkage of symbols in the executable to be stored such that dladdr can find them. B. Switch backtrace_symbols to use the 'atos' tool's codebase instead of using dladdr. Understandably dladdr is only concerned with dynamically loaded symbols, but it would be nice if backtrace_symbols was more generic and could handle local/static symbols as well. C. Open 'atos' source or publicize the "symbolication" framework so we can emulate/customize atos functionality. popen()'ing a call to atos is kind of ugly, but of bigger concern is that atos does some kind of preprocessing of the entire symbol table, and for a large project like ours this takes ~10 seconds per launch of atos. So even if we have to stick with calling out to atos, it would be more usable if atos could be set to only process what was needed for the trace at hand instead of running through the entire symbol table right off the bat. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… This email sent to site_archiver(a)lists.apple.com

1 0

Re: access / eaccess
by Terry Lambert 24 Mar '09

24 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com int eaccess(const char *path, int mode) { uid_t ruid, euid; gid_t rgid, egid; int rv; int done = 0; ruid = getuid(); euid = geteuid(); rgid = getgid(); egid = getegid(); if (!setregid(egid, rgid)) { if (!setreuid(euid, ruid)) { rv = access(path, mode); done = 1; setreuid(ruid, euid)); } setregid(rgid, egid); } /* fall back */ if (!done) rv = access(path, mode); return(rv); } -- Terry _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… On Mar 24, 2009, at 4:48 AM, Stéphane Sudre wrote: Is there an equivalent to the eaccess function in Darwin? Generally, no, since it's not really a useful operation, which is why it's not part of the POSIX standard. It will also opt you out of directory services support for more than 16 groups You can emulate it on Leopard or later -- assuming you use the POSIX compilation environment, which, since it supports POSIX saved IDs, allows toggling real/effective -- with: ...of course, this wouldn't be thread safe, but then neither is any operation that depends on switching IDs after successfully preflighting with an eaccess system call anyway, and preflighting won't guarantee against a future failure in any case, since rights can change between the time you start the preflight and the time you actually attempt the operation, given that access and subsequent operations can't really be made transactional without changing all the network file system protocols out there, and almost all of the filesystems themselves. The best policy is to try to do something, and if it fails, report the error. This email sent to site_archiver(a)lists.apple.com

1 0

Re: dladdr/backtrace_symbols return incorrect symbol names
by Terry Lambert 24 Mar '09

24 Mar '09

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)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(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.app… 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(a)lists.apple.com

1 0