September 2004 - Darwin-dev

Re: mach-o __TEXT segment layed out backwards?
by Bob Campbell 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Bob, First thanks for the reply. I am not really sure that "backwards" is the correct term. In an application (or dylib) the loader commands are included in the __TEXT segment, and then padded to have some space for some post link operations to update various tables (like two-level namespaces etc). When you look at the "sections" with in the __TEXT segment, it looks like there is a hole at the beginning of the __TEXT segment, but that space is really used for the loader commands. (It is possible I am not understanding why you think there are backwards so if my assumptions are incorrect, please clearify and I will try to explain). In my test hello world type program the last section went all the way to the last byte of the segment. From that I assumed that the __TEXT segment was for some reason layed out from end to start. The thing that made it somewhat confusing is that there is space between the end of the loader commands and the start of the __text section. I looked at a different executable and the last section didn't end at the last byte of the segment, so obviously my original assumption was wrong and the space between the loader commands and the __TEXT segment is as you say padding. Can you (or someone else) explain some more about what that space is used for? In the few executables I've looked at they were always zero filled. I am not completely sure what you mean by "__text ptrs", my understanding is that the loader can run relocations on the __TEXT segment, but really causes problems in that it forces the __TEXT segment to become write able and prevents swapping from the original image (I made that mistake 6 or so years ago and Kevin Enderby correctly slapped my hand). It is for this reason that the literal pointers end up in the __DATA segment. By ptrs I meant the offsets to the __DATA segment, sorry for the bad terminology. My intent for all this is to pop in some code into executables and frameworks/bundles that runs on load (or very soon afterwards). It seems to me like the way to do this would be either write my own dyld (which seems very hard) or add/modify the __mod_init_func section and pop in the code (after setting any offsets based on the symbol tables) in some blank space in a segment (which seems less hard and I figured __TEXT would be ideal). At 5:58 PM -0500 9/15/04, Paul Haddad wrote: On Wed, 15 Sep 2004 13:58:39 -0700, Bob Campbell <bobc(a)metrowerks.com> wrote: The only references to the padding is in the linker man page (man ld) and in the linker sources. It is partly for the case where the system libraries change, it allows a process to fix up paths in existing binaries (even those which are non-pick and can't be moved in memory). See -headerpad <value> and -headerpad_max_install_names. I have never really thought about how to do that, and I am not sure it is a good idea. -- Message Classification [x] General Business Information ___________________________________________________________________ Bob Campbell bobc(a)metrowerks.com 408.991.7490 _______________________________________________ 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: RAID-1 possible for multi-filesystem disk?
by howarth＠bromo.msbb.uc.edu 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: Darwin-dev(a)lists.apple.com John, I don't believe Linux is using lvm to do this. The raid is setup at install time. You use DiskDruid to first partition each disk into identically sized partitions and then create md devices which are set to a specific RAID type (RAID-1 for example) and contain particular partitions as the submirrors. I have also done something very similar under Solaris 9. One can take a Solaris 9 drive and replace the existing partitions with mirrors and submirrors on an existing installation. If I even had that level of flexiblity from MacOS X I would be happy. Jack _______________________________________________ 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: mach-o __TEXT segment layed out backwards?
by Paul Haddad 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Bob, First thanks for the reply. On Wed, 15 Sep 2004 13:58:39 -0700, Bob Campbell <bobc(a)metrowerks.com> wrote: > I am not really sure that "backwards" is the correct term. In an > application (or dylib) the loader commands are included in the __TEXT > segment, and then padded to have some space for some post link > operations to update various tables (like two-level namespaces etc). > > When you look at the "sections" with in the __TEXT segment, it looks > like there is a hole at the beginning of the __TEXT segment, but that > space is really used for the loader commands. > > (It is possible I am not understanding why you think there are > backwards so if my assumptions are incorrect, please clearify and I > will try to explain). In my test hello world type program the last section went all the way to the last byte of the segment. From that I assumed that the __TEXT segment was for some reason layed out from end to start. The thing that made it somewhat confusing is that there is space between the end of the loader commands and the start of the __text section. I looked at a different executable and the last section didn't end at the last byte of the segment, so obviously my original assumption was wrong and the space between the loader commands and the __TEXT segment is as you say padding. Can you (or someone else) explain some more about what that space is used for? In the few executables I've looked at they were always zero filled. > I am not completely sure what you mean by "__text ptrs", my > understanding is that the loader can run relocations on the __TEXT > segment, but really causes problems in that it forces the __TEXT > segment to become write able and prevents swapping from the original > image (I made that mistake 6 or so years ago and Kevin Enderby > correctly slapped my hand). It is for this reason that the literal > pointers end up in the __DATA segment. By ptrs I meant the offsets to the __DATA segment, sorry for the bad terminology. My intent for all this is to pop in some code into executables and frameworks/bundles that runs on load (or very soon afterwards). It seems to me like the way to do this would be either write my own dyld (which seems very hard) or add/modify the __mod_init_func section and pop in the code (after setting any offsets based on the symbol tables) in some blank space in a segment (which seems less hard and I figured __TEXT would be ideal). I'm guessing someone else out there has tried to do this and maybe can provide some hints? _______________________________________________ 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: incomplete man pages....
by Martin Costabel 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 Sean McBride wrote: OK, but there are lots of files there. :) I don't know anything about the workings of 'man', which files do I need? I see there is /usr/share/ man in the pax archive, do I just need those files? -- Martin _______________________________________________ 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… [] The relevant files are all in /usr/share/man, yes. But there being thousands of them, it is hard to say which ones might have been updated in the meantime. You could run Gary Kerbaugh's pkgdiff script http://www.chemistry.ucsc.edu/%7Ewgscott/xtal/pkgdiff.html to compare your package installation receipts in /Library/Receipts with what you have on your disk. This email sent to site_archiver(a)lists.apple.com

1 0

Re: mach-o __TEXT segment layed out backwards?
by Bob Campbell 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Date: Wed, 15 Sep 2004 10:36:56 -0500 From: Paul Haddad <paul.haddad(a)gmail.com> Subject: mach-o __TEXT segment layed out backwards? To: darwin-dev(a)lists.apple.com Message-ID: <944074f304091508363060a449(a)mail.gmail.com> Content-Type: text/plain; charset=US-ASCII Hi All, I've been looking around mach-o executables and I noticed that the __TEXT segment seems to be layed out backwards, i.e. the last section ends at the end of the segment and the other sections go backwards from that. Also on a related note is it possible to relocate the __text section post link? Well obviously it can be moved, but all the data/function pointers will be screwed up so I guess the better question is after link and after relocation can the __text ptrs be fixed? At 12:11 PM -0700 9/15/04, <darwin-dev-request(a)lists.apple.com> wrote: Can someone explain to me why this is? I am not really sure that "backwards" is the correct term. In an application (or dylib) the loader commands are included in the __TEXT segment, and then padded to have some space for some post link operations to update various tables (like two-level namespaces etc). When you look at the "sections" with in the __TEXT segment, it looks like there is a hole at the beginning of the __TEXT segment, but that space is really used for the loader commands. (It is possible I am not understanding why you think there are backwards so if my assumptions are incorrect, please clearify and I will try to explain). After linking most all of the relocations are removed so that you can't move things around (unless you effectively disassemble everything and figure out what all of the relocations would have been). In the PIC case you can move everything, but you must maintain the relative offsets between all sections. (I.e. it moves as one whole piece and references from __TEXT to __DATA are relative to the __TEXT segment). I am not completely sure what you mean by "__text ptrs", my understanding is that the loader can run relocations on the __TEXT segment, but really causes problems in that it forces the __TEXT segment to become write able and prevents swapping from the original image (I made that mistake 6 or so years ago and Kevin Enderby correctly slapped my hand). It is for this reason that the literal pointers end up in the __DATA segment. -- Message Classification [x] General Business Information ___________________________________________________________________ Bob Campbell bobc(a)metrowerks.com 408.991.7490 _______________________________________________ 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: incomplete man pages....
by Sean McBride 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Martin Costabel (costabel(a)wanadoo.fr) on Wed, Sep 15, 2004 16:09 said: >Not really. Many of the files from BSD.pkg have been updated in the >meantime, up to the latest security update. You don't want to downgrade >/usr/sbin/sshd or /usr/sbin/krb5kdc, for example. Makes sense. Might some of the man pages have been updated since 10.3.5 though? Might I not overwrite updated ones if i copy the 10.3.0 ones? >Just extract the man >pages from BSD.pkg/Contents/Archive.pax.gz, using /bin/pax or some other >tool. OK, but there are lots of files there. :) I don't know anything about the workings of 'man', which files do I need? I see there is /usr/share/ man in the pax archive, do I just need those files? Thanks! _______________________________________________ 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: incomplete man pages....
by Martin Costabel 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 Sean McBride wrote: Well, I tried (re)installing the "BSD SDK" from XCode 1.5 and that did not help. Some googling seems to suggest it is the BSD.pkg on the Reading this thread would have been sufficient :-) Panther install disk that needs to be reinstalled, but I am very hesitant to do so since I'm running 10.3.5 and the CD is 10.3.0. -- Martin _______________________________________________ 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… [] Is it safe to do so? Not really. Many of the files from BSD.pkg have been updated in the meantime, up to the latest security update. You don't want to downgrade /usr/sbin/sshd or /usr/sbin/krb5kdc, for example. Just extract the man pages from BSD.pkg/Contents/Archive.pax.gz, using /bin/pax or some other tool. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Using MIG RPC between 2 threads inside a process
by Jim Magee 15 Sep '04

15 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 15, 2004, at 4:12 AM, Stéphane Letz wrote: I had to hack the MIG generated files to avoid names conflict (the same RPC call that is usually compiled on server and client side independently is now compiled on the server side). You can use the "ServerPrefix" flag in the MIG .defs IDL file to avoid the name conflict (see <mach/exc.defs>). Even if it seems to work correctly, I was wondering if is is correct to use MIG RPC system like that or if another light inter-thread communication system should be used. Something involving pthread synchronizers (mutexes and condition variables) will be more efficient. But if one of the threads is already committed to using Mach IPC anyway, this is a good way to "mesh in" with what it is already expecting. This email sent to site_archiver(a)lists.apple.com

1 0

Re: incomplete man pages....
by Sean McBride 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Eric Albert (ejalbert(a)apple.com) on Tue, Sep 14, 2004 01:47 said: >I'm pretty sure the most common cause for the missing man page issue is >a missing BSD SDK. Reinstall that package and they should show up. Well, I tried (re)installing the "BSD SDK" from XCode 1.5 and that did not help. Some googling seems to suggest it is the BSD.pkg on the Panther install disk that needs to be reinstalled, but I am very hesitant to do so since I'm running 10.3.5 and the CD is 10.3.0. Is it safe to do so? _______________________________________________ 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

mach-o __TEXT segment layed out backwards?
by Paul Haddad 15 Sep '04

15 Sep '04

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi All, I've been looking around mach-o executables and I noticed that the __TEXT segment seems to be layed out backwards, i.e. the last section ends at the end of the segment and the other sections go backwards from that. Can someone explain to me why this is? Also on a related note is it possible to relocate the __text section post link? Well obviously it can be moved, but all the data/function pointers will be screwed up so I guess the better question is after link and after relocation can the __text ptrs be fixed? --- Paul _______________________________________________ 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