September 2004 - Darwin-dev

need help resolving symbols using twolevel hints table
by Mike Garey 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com If anyone has any advice or suggestions, please let me know. Thanks! Mike _______________________________________________ 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… I'm having difficulty understanding how to use the twolevel hints table to resolve undefined symbols. I'm not sure what exactly the itoc member of the twolevel hints structure represents. For example, if I have an executable image, which has an undefined symbol such as _printf, after I determine which library image it's located in (from the n_desc value of the nlist struct), do I then obtain the tocoff value from the dysymtab_command of this library, and add the itoc to this value, then read the memory found at this location into a dylib_table_of_contents struct, and then obtain the symbol_index member, which will indicate the index of the _printf symbol within the symbol table of the shared library? Or is this completely wrong? P.S. Sorry if this question has been answered in the lists before, but I can't seem to find the search option on lists.apple.com. _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Self compiled gdb doesn't work with Xcode
by Kevin Van Vechten 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi Mike, $ DSTROOT=/tmp/gdb-330.1.root $ mkdir $DSTROOT $ make installhdrs # if everything looks good in $DSTROOT ... $ ditto $DSTROOT / (Use pax or gnutar on pure-Darwin systems.) - Kevin On Sep 13, 2004, at 11:14 AM, Mike Garey 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… There may be an alternative way, but not necessarily an easier way. ;-) While building Mac OS X, the headers to every project are installed first, i.e. "make installhdrs". Some of the gdb headers are probably considered "private" and therefore not shipped on a developer CD. Doing the installhdrs for gdb before building will likely put these headers in a place where they can be found. I recommend installing into a temporary directory, inspecting it for sanity, then copying it to the base system: I'm using Xcode 1.5. I just grabbed the source for gdb-330.1, so I'll give it a try. Also wanted to know something else, when I try to compile the macsbug plugin, I get all sorts of errors because it can't find the header files (which are located in gdb-330.1/src, while the plugin directory is in gdb-330.1/macsbug). I fixed this last time by modifying the makefile and adding the relative paths to the include directories, but I'd like to know if there's an easier way, since I'm sure I'm just missing something pretty obvious here. Thanks, Mike This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rép : Using dead notification with mach ports
by Stéphane Letz 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com What do you mean by "which task it is associated with at creation"? Is there any problem with this approach? Thanks Stephane _______________________________________________ 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… What is important for a Mach semaphore is which task it is associated with at creation. If it is associated with the client task and the client goes away, then operations on that semaphore by other tasks will fail (with an appropriate error code). So, choosing which task to associate with is important for widely shared semaphores. In my case the server main thread (the one that handle the client request : like new_client.....) will create the semaphore and pass them to clients. then client will wait on their semaphore, and another thread of the server *or* another thread of another client will signal the semaphore. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Self compiled gdb doesn't work with Xcode
by Mike Garey 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Mike From: Kevin Van Vechten <kevin(a)opendarwin.org> To: "Mike Garey" <random50k(a)hotmail.com> CC: darwin-dev(a)lists.apple.com Subject: Re: Self compiled gdb doesn't work with Xcode Date: Sun, 12 Sep 2004 16:45:44 -0700 - Kevin On Sep 12, 2004, at 3:25 PM, Mike Garey wrote: I downloaded a copy of the gdb source from: _______________________________________________ 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… I'm using Xcode 1.5. I just grabbed the source for gdb-330.1, so I'll give it a try. Also wanted to know something else, when I try to compile the macsbug plugin, I get all sorts of errors because it can't find the header files (which are located in gdb-330.1/src, while the plugin directory is in gdb-330.1/macsbug). I fixed this last time by modifying the makefile and adding the relative paths to the include directories, but I'd like to know if there's an easier way, since I'm sure I'm just missing something pretty obvious here. Thanks, What version of Xcode are you working with? gdb-356 is the version that is available from the WWDC Tiger seed. You might have better luck building the version of gdb that corresponds to the version of Xcode that your are using. For example, gdb-330.1 corresponds to Xcode 1.5. http://www.opensource.apple.com/darwinsource/tarballs/other/gdb -356.tar.gz and compiled it myself, however, I've been unable to use it successfully from within Xcode. I simply replaced the copy of gdb from /usr/bin/gdb with the newly compiled version, and Xcode is able to launch the new gdb, but any breakpoints I set are never hit. I realize that the version of gdb which I was previously using (the one that ships with Panther), actually had a shell script in /usr/bin/gdb, while the newly compiled version does not. The version of this new gdb is: "GNU gdb 2004-03-03-cvs". If anyone has any advice on how to get this to work correctly with Xcode, please let me know. And also, is this the newest version of gdb available? I tried obtaining the cvs source from ":pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root", but it was older than the one available from the web site. Thanks in advance, Mike _________________________________________________________________ Take advantage of powerful junk e-mail filters built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht… Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rép : Using dead notification with mach ports
by Jim Magee 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com --Jim _______________________________________________ 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 Sep 13, 2004, at 1:30 PM, Stéphane Letz wrote: That's a lot of stuff to keep coordinated. I assume that you would consider having any one of these channels shut down prematurely as a sign of a failed client/server connection. If so, you have to request a dead-name notification on the semaphore and the callback port, and a no-senders notification on the private client->server port. But if you are careful with checking error codes (and not allowing the server to get hung up waiting for a non-responsive/dead client on the semaphore and callback operations) you could still get away with just the no-senders notification on the private client->server port. For the semaphore, I guess "semaphore_signal" called on the server side will return KERN_TERMINATED error code if the client has shut down prematurely. Will it be enough? Should be, as long as the client always allocates the semaphore and not the server. Hum... I am actually allocating all semaphores on the server side and returning them to the client like in the following RPC call : StephaneConnectToServer ( serverPort : mach_port_t; connectFlags : integer_t; clientPort : mach_port_t; out semaphorePort: semaphore_t; out serverPort: mach_port_make_send_t ); The reason is that I have to pass client semaphore to other clients (for inter-clients synchronization), thus when a new client register to the server, it will get its own semaphore and the semaphore of all already running clients. And all already running clients will be "notified" for the new client semaphore. When the system runs, only one client will be waiting on its private semaphore, but the server or other clients will possibly signal the semaphore. So I think all semaphores have to be allocated on the server side. What happens if the server use semaphore_signal in this case? What is important for a Mach semaphore is which task it is associated with at creation. If it is associated with the client task and the client goes away, then operations on that semaphore by other tasks will fail (with an appropriate error code). So, choosing which task to associate with is important for widely shared semaphores. But if I understand correctly what you explained about "dead-name" and "no-senders" notifications, everything allocated on the server side (the private client->server port and semaphores can be handled with the "no-senders" notification. You can never use a no-sender notification with a Mach semaphore. The kernel holds the receive right. Everyone else only has send rights - and you can't request a no-sender notification when you only hold a send right to a port (even though this is a semaphore port rather than a message queue port). Dead-name notifications (or just the error returns from trying to use a semaphore whose's associated task has gone away) are the way to go there. Well I am not using CFMachPort because I wanted to have the server do RPC on the call-back port. So I actually use the MIG generator to define RPC to be called by the server. And I use a "manually" allocated thread to handle the MIG generated message handling routine. Would using CFRunLoop and CFMachPort be a cleaner approach? If you can handle it all in your helper thread, and the number of clients needing this additional thread is small, then there is nothing wrong with your approach. But it's normally better to not create an additional threads in the clients if you can avoid it. If the callbacks cannot be completely handled in the additional thread, how do these additional threads signal the main thread? In that case, you're going to have to reflect the callback status over to the main thread anyway and it might have just been easier (and more efficient) to send it there directly. Do you mean i could handled notifications coming from the server (*in the form of MIG generated RPC*) in the main application thread if I use CFRunLoop and CFMachPort? Sure. How do you think all the other CFRunLoop sources work? A CFRunLoop is just a wrapper around a Mach portset. ;-) This email sent to site_archiver(a)lists.apple.com

1 0

Re: incomplete man pages....
by David Gatwood 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com It appears my man pages are incomplete, e.g. when I type "man system" I get 'no entry'. What's the best way to keep them up to date? David NAME system - pass a command to the shell LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include <stdlib.h> int system(const char *string); SEE ALSO sh(1), execve(2), fork(2), waitpid(2), popen(3) _______________________________________________ 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 Mon, 13 Sep 2004, at 12:56:11 -0400, Ken Wieschhoff <weesh(a)mindspring.com> wrote: Works for me. Those man pages might be installed by the developer tools installation. If you haven't installed a current dev tools suite, they're probably missing. SYSTEM(3) BSD Library Functions Manual SYSTEM(3) DESCRIPTION The system() function hands the argument string to the command inter- preter sh(1). The calling process waits for the shell to finish execut- ing the command, ignoring SIGINT and SIGQUIT, and blocking SIGCHLD. If string is a NULL pointer, system() will return non-zero if the command interpreter sh(1) is available, and zero if it is not. The system() function returns the exit status of the shell as returned by waitpid(2), or -1 if an error occurred when invoking fork(2) or waitpid(2). A return value of 127 means the execution of the shell failed. STANDARDS The system() function conforms to ISO/IEC 9899:1990 (``ISO C89'') and is expected to be IEEE Std 1003.2 (``POSIX.2'') compatible. BSD June 4, 1993 BSD This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rép : Using dead notification with mach ports
by Stéphane Letz 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Le 13 sept. 04, à 18:36, Jim Magee a écrit : Ok. I have to check carefully. Thanks On Sep 13, 2004, at 12:14 PM, Stéphane Letz wrote: You seem to have an overly complex situation here. You have a private client->server port, a call-back port, AND a shared semaphore. Well after thinking a little more, maybe using only *one* port and the shared semaphore for each client will be enough.... I mean the idea to have a "private" client->server port was to allow the server to get a notification related to a specific client and to cleanly destroy its internal client data structure. But if a call-back port is needed for server->client communication anyway, *and* if this port can be checked by the server for dead-name notification then the "private" client->server port seems not to be needed anymore. And *all* client->server MIG RPC can use the server global port (allocated and registered in the global namespace) Is this possible? It is certainly possible. But it is trickier (again, all depending on the protocol you have established between the client and server and vice-versa). You need to make sure clients don't spoof each other to the server (if you care about that at all) because of the common queue between all clients and the server. You have deal with the problem of "pending messages still in the main queue" from a client at the time you receive the dead-name notification for that client (how do you know when you receive them that they are from the dead client and not some new client whose identifying marks look similar?). That's a lot of stuff to keep coordinated. I assume that you would consider having any one of these channels shut down prematurely as a sign of a failed client/server connection. If so, you have to request a dead-name notification on the semaphore and the callback port, and a no-senders notification on the private client->server port. But if you are careful with checking error codes (and not allowing the server to get hung up waiting for a non-responsive/dead client on the semaphore and callback operations) you could still get away with just the no-senders notification on the private client->server port. For the semaphore, I guess "semaphore_signal" called on the server side will return KERN_TERMINATED error code if the client has shut down prematurely. Will it be enough? Should be, as long as the client always allocates the semaphore and not the server. Hum... I am actually allocating all semaphores on the server side and returning them to the client like in the following RPC call : StephaneConnectToServer ( serverPort : mach_port_t; connectFlags : integer_t; clientPort : mach_port_t; out semaphorePort: semaphore_t; out serverPort: mach_port_make_send_t ); The reason is that I have to pass client semaphore to other clients (for inter-clients synchronization), thus when a new client register to the server, it will get its own semaphore and the semaphore of all already running clients. And all already running clients will be "notified" for the new client semaphore. When the system runs, only one client will be waiting on its private semaphore, but the server or other clients will possibly signal the semaphore. So I think all semaphores have to be allocated on the server side. What happens if the server use semaphore_signal in this case? But if I understand correctly what you explained about "dead-name" and "no-senders" notifications, everything allocated on the server side (the private client->server port and semaphores can be handled with the "no-senders" notification. Well I am not using CFMachPort because I wanted to have the server do RPC on the call-back port. So I actually use the MIG generator to define RPC to be called by the server. And I use a "manually" allocated thread to handle the MIG generated message handling routine. Would using CFRunLoop and CFMachPort be a cleaner approach? If you can handle it all in your helper thread, and the number of clients needing this additional thread is small, then there is nothing wrong with your approach. But it's normally better to not create an additional threads in the clients if you can avoid it. If the callbacks cannot be completely handled in the additional thread, how do these additional threads signal the main thread? In that case, you're going to have to reflect the callback status over to the main thread anyway and it might have just been easier (and more efficient) to send it there directly. Do you mean i could handled notifications coming from the server (*in the form of MIG generated RPC*) in the main application thread if I use CFRunLoop and CFMachPort? Because you are already waiting for messages to arrive on the callback port in each client, no-senders notifications can be sent to those very same ports, and you are then guaranteed they are the last messages that are going to come on those ports. You can, for instance, send the dead-name notifications for the server's global port to that same callback port. But you can't be sure it will be the last message there. I don't think that it is a problem in my case : if a dead-name notification for the server's global port is received, there is no nothing more to do for the client. If you don't target the same port, then you have to add a second port and a portset to the client-side logic just like the server's. Stephane _______________________________________________ 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

incomplete man pages....
by Ken Wieschhoff 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thanks, ->Ken -- - -- Ken Wieschhoff (770)813-0231 *************************** _______________________________________________ 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… It appears my man pages are incomplete, e.g. when I type "man system" I get 'no entry'. What's the best way to keep them up to date? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rép : Using dead notification with mach ports (Modifié par Stéphane Letz)
by Jim Magee 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com --Jim _______________________________________________ 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 Sep 13, 2004, at 12:14 PM, Stéphane Letz wrote: You seem to have an overly complex situation here. You have a private client->server port, a call-back port, AND a shared semaphore. Well after thinking a little more, maybe using only *one* port and the shared semaphore for each client will be enough.... I mean the idea to have a "private" client->server port was to allow the server to get a notification related to a specific client and to cleanly destroy its internal client data structure. But if a call-back port is needed for server->client communication anyway, *and* if this port can be checked by the server for dead-name notification then the "private" client->server port seems not to be needed anymore. And *all* client->server MIG RPC can use the server global port (allocated and registered in the global namespace) Is this possible? It is certainly possible. But it is trickier (again, all depending on the protocol you have established between the client and server and vice-versa). You need to make sure clients don't spoof each other to the server (if you care about that at all) because of the common queue between all clients and the server. You have deal with the problem of "pending messages still in the main queue" from a client at the time you receive the dead-name notification for that client (how do you know when you receive them that they are from the dead client and not some new client whose identifying marks look similar?). That's a lot of stuff to keep coordinated. I assume that you would consider having any one of these channels shut down prematurely as a sign of a failed client/server connection. If so, you have to request a dead-name notification on the semaphore and the callback port, and a no-senders notification on the private client->server port. But if you are careful with checking error codes (and not allowing the server to get hung up waiting for a non-responsive/dead client on the semaphore and callback operations) you could still get away with just the no-senders notification on the private client->server port. For the semaphore, I guess "semaphore_signal" called on the server side will return KERN_TERMINATED error code if the client has shut down prematurely. Will it be enough? Should be, as long as the client always allocates the semaphore and not the server. For callback ports, I hope that using a timeout will be enough. Actually, you'll get back a difference error (invalid destination vs. timeout), but the same recovery logic should work in either case if you design your server state engine correctly. Another question : notification will allow the server to know when clients disappear abnormally. What happens in the contrary case? Can clients be notified if the server dappear? Sure. But this is usually trickier unless you own all the clients yourself. You can use a dead-name notification on the client->server private port or a no-senders notification on the server->client callback port. Again, the no-senders approach is usually the cleanest. Since you are likely to be using a CFRunLoop in the client, you probably are already creating a CFMachPort in the client to receive the callbacks from the server. Unfortunately, CFMachPort doesn't have any built in support for no-senders notifications (like the invalidation callback for dead-name notifications). Instead, you'll just have to request the notification manually and then handle the no-senders notification as part of you normal message callback handler. Well I am not using CFMachPort because I wanted to have the server do RPC on the call-back port. So I actually use the MIG generator to define RPC to be called by the server. And I use a "manually" allocated thread to handle the MIG generated message handling routine. Would using CFRunLoop and CFMachPort be a cleaner approach? If you can handle it all in your helper thread, and the number of clients needing this additional thread is small, then there is nothing wrong with your approach. But it's normally better to not create an additional threads in the clients if you can avoid it. If the callbacks cannot be completely handled in the additional thread, how do these additional threads signal the main thread? In that case, you're going to have to reflect the callback status over to the main thread anyway and it might have just been easier (and more efficient) to send it there directly. Why is the "no-senders approach" the cleanest in this case? Because you are already waiting for messages to arrive on the callback port in each client, no-senders notifications can be sent to those very same ports, and you are then guaranteed they are the last messages that are going to come on those ports. You can, for instance, send the dead-name notifications for the server's global port to that same callback port. But you can't be sure it will be the last message there. If you don't target the same port, then you have to add a second port and a portset to the client-side logic just like the server's. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Rép : Using dead notification with mach ports (Modifié par Stéphane Letz)
by Stéphane Letz 13 Sep '04

13 Sep '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com Is this possible? For callback ports, I hope that using a timeout will be enough. Thanks Stephane _______________________________________________ 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… You seem to have an overly complex situation here. You have a private client->server port, a call-back port, AND a shared semaphore. Well after thinking a little more, maybe using only *one* port and the shared semaphore for each client will be enough.... I mean the idea to have a "private" client->server port was to allow the server to get a notification related to a specific client and to cleanly destroy its internal client data structure. But if a call-back port is needed for server->client communication anyway, *and* if this port can be checked by the server for dead-name notification then the "private" client->server port seems not to be needed anymore. And *all* client->server MIG RPC can use the server global port (allocated and registered in the global namespace) That's a lot of stuff to keep coordinated. I assume that you would consider having any one of these channels shut down prematurely as a sign of a failed client/server connection. If so, you have to request a dead-name notification on the semaphore and the callback port, and a no-senders notification on the private client->server port. But if you are careful with checking error codes (and not allowing the server to get hung up waiting for a non-responsive/dead client on the semaphore and callback operations) you could still get away with just the no-senders notification on the private client->server port. For the semaphore, I guess "semaphore_signal" called on the server side will return KERN_TERMINATED error code if the client has shut down prematurely. Will it be enough? Another question : notification will allow the server to know when clients disappear abnormally. What happens in the contrary case? Can clients be notified if the server disappear? Sure. But this is usually trickier unless you own all the clients yourself. You can use a dead-name notification on the client->server private port or a no-senders notification on the server->client callback port. Again, the no-senders approach is usually the cleanest. Since you are likely to be using a CFRunLoop in the client, you probably are already creating a CFMachPort in the client to receive the callbacks from the server. Unfortunately, CFMachPort doesn't have any built in support for no-senders notifications (like the invalidation callback for dead-name notifications). Instead, you'll just have to request the notification manually and then handle the no-senders notification as part of you normal message callback handler. Well I am not using CFMachPort because I wanted to have the server do RPC on the call-back port. So I actually use the MIG generator to define RPC to be called by the server. And I use a "manually" allocated thread to handle the MIG generated message handling routine. Would using CFRunLoop and CFMachPort be a cleaner approach? Why is the "no-senders approach" the cleanest in this case? This email sent to site_archiver(a)lists.apple.com

1 0