January 2006 - Darwin-dev - lists.apple.com

Re: MoreBacktrace for i386?
by Andrew Pinski 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 20, 2006, at 12:50 PM, Eric Albert wrote: -- Pinski _______________________________________________ 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… Mac OS X doesn't support DWARF yet and the compiler doesn't omit frame pointers (though you can write asm functions which omit them), so for now regular backtracing code will work fine in nearly all cases. Unfortunately, MoreBacktrace should handle all cases, not nearly all, so it'll take a little bit longer before it's ready. Actually the compiler does emit enough dwarf2 to do this as you only need the information from -fasynchronous-unwind-tables which is the same information that is used for undwinding from exceptions. This email sent to site_archiver(a)lists.apple.com

1 0

Re: MoreBacktrace for i386?
by Eric Albert 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 20, 2006, at 8:31 AM, Andrew Pinski wrote: On Jan 20, 2006, at 10:06 AM, Pete Gontier wrote: circa 1/19/06 4:29 AM, "Stefan Haller" <haller(a)ableton.com> wrote: circa 1/19/06 9:38 PM, Quinn wrote: I've been working on this all week. It's much more challenging than I thought it would be. No ETA as of yet. -Eric _______________________________________________ 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 wondering if or when we can expect the MoreBacktrace stuff from the MoreIsBetter sample code to be ported to i386? It might be better at this point to use dwarf2 eh tables to get a backtrace than it is from x86's stack frame because if you don't have a frame pointer, stack frames are "messed" up. Mac OS X doesn't support DWARF yet and the compiler doesn't omit frame pointers (though you can write asm functions which omit them), so for now regular backtracing code will work fine in nearly all cases. Unfortunately, MoreBacktrace should handle all cases, not nearly all, so it'll take a little bit longer before it's ready. This email sent to site_archiver(a)lists.apple.com

1 0

Re: MoreBacktrace for i386?
by Andrew Pinski 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 20, 2006, at 10:06 AM, Pete Gontier wrote: circa 1/19/06 4:29 AM, "Stefan Haller" <haller(a)ableton.com> wrote: circa 1/19/06 9:38 PM, Quinn wrote: I've been working on this all week. It's much more challenging than I thought it would be. No ETA as of yet. -- Pinski _______________________________________________ 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 wondering if or when we can expect the MoreBacktrace stuff from the MoreIsBetter sample code to be ported to i386? It might be better at this point to use dwarf2 eh tables to get a backtrace than it is from x86's stack frame because if you don't have a frame pointer, stack frames are "messed" up. This email sent to site_archiver(a)lists.apple.com

1 0

Loading a shared library directly from inside of a ZIP file
by Martin Knapp-Cordes 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Hi, Is there a 'public' interface (with a different name) that will replace the interface: void *dlopen(const char *filename, int flag); by say: void *dlopen_new(int fd, void *start, size_t length, int flag); This is motivated by the mmap interface: void * mmap(void *start, size_t length, int prot , int flags, int fd, off_t offset); The idea is that you are given a triplet: (name,offset,length) where name is file descriptor for the ZIP file (int fd), and the offset (void *start) is the start of the shared library in the ZIP file, and length (size_t length) is the length of the shared library. Note that dlopen() under the hood does a mmap. If there isn't, is the only recourse, to 'hack' the source or are there some other ideas or published solutions. The solution of making a copy into the filesystem first and using the old interface is NOT acceptable. Sincerely, Martin Knapp-Cordes --------------------------------------------------------------- | Martin Knapp-Cordes martin(a)mathworks.com | | The MathWorks, Inc. http://www.mathworks.com | | 3 Apple Hill Drive Natick, MA 01760 | | Tel: (508) 647-7321 Fax: (508) 647-7015 | --------------------------------------------------------------- _______________________________________________ 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: MoreBacktrace for i386?
by Pete Gontier 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Thread-index: AcYd0xJcUQOd6onGEdq8NQAwZeF9Qg== Thread-topic: MoreBacktrace for i386? User-agent: Microsoft-Entourage/11.2.0.050811 circa 1/19/06 4:29 AM, "Stefan Haller" <haller(a)ableton.com> wrote: > I'm wondering if or when we can expect the MoreBacktrace stuff from the > MoreIsBetter sample code to be ported to i386? circa 1/19/06 9:38 PM, Quinn wrote: > I've been working on this all week. It's much more challenging than I > thought it would be. No ETA as of yet. Pete Gontier <http://www.m-audio.com/> _______________________________________________ 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: IONotificationPortRef cleanup
by Jim Magee 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 10, 2006, at 2:44 PM, Steve Checkoway wrote: --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 Jan 10, 2006, at 2:35 PM, Chris Sarcone wrote: To be completely clear about this, these leaked ports are not reclaimed when the application exits? Mach will clean them up for you at task termination. However, whenever you don't need the resource, you should do the proper thing to release it. Thank you for the clarification. It seems to me that the example should be changed to simply _exit(2) since the ports will be cleaned up. The problem is that someone will copy the example into a library routine and replace the _exit() with a return. Then they wonder why they leak - since Apple provided the example and it should have managed its resources. This email sent to site_archiver(a)lists.apple.com

1 0

Re: intercepting system calls?
by wadeslists＠mac.com 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Wade Tregaskis ICQ: 40056898 AIM, Yahoo & Skype: wadetregaskis MSN: wjtregaskis(a)students.latrobe.edu.au iChat & email: wadetregaskis(a)mac.com Jabber: wadetregaskis(a)jabber.org Google Talk: wadetregaskis(a)gmail.com http://homepage.mac.com/wadetregaskis/ -- Sed quis custodiet ipsos custodes? _______________________________________________ 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'd like to catch the system calls that an process is making, so I can examine the system call and optionally handle it myself. Under Linux and Solaris, I can use ptrace() with the PTRACE_SYSCALL command, which will let the process run until it enters or exits a system call. Is systrace <http://www.citi.umich.edu/u/provos/systrace/> suitable for your purposes? It hasn't been updated for the recent MacOS X kernels, as far as I know, but it did work up until at least Jaguar. If nothing else, it's probably a good starting point for how-to. This email sent to site_archiver(a)lists.apple.com

1 0

Re: intercepting system calls?
by Shawn Erickson 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com On Jan 19, 2006, at 9:02 PM, Erik Paulson wrote: Hi - Doing what you asking to do is really really frowned upon by Apple. What are you trying to achieve? Just for research? -Shawn _______________________________________________ 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'd like to catch the system calls that an process is making, so I can examine the system call and optionally handle it myself. Under Linux and Solaris, I can use ptrace() with the PTRACE_SYSCALL command, which will let the process run until it enters or exits a system call. Is there an equivalent for Darwin? Using a KEXT to patch the system call table is really not an option... This email sent to site_archiver(a)lists.apple.com

1 0

intercepting system calls?
by Erik Paulson 20 Jan '06

20 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com User-agent: Mutt/1.4.2.1i Hi - I'd like to catch the system calls that an process is making, so I can examine the system call and optionally handle it myself. Under Linux and Solaris, I can use ptrace() with the PTRACE_SYSCALL command, which will let the process run until it enters or exits a system call. Is there an equivalent for Darwin? Using a KEXT to patch the system call table is really not an option... Thanks! -Erik _______________________________________________ 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

MoreBacktrace for i386?
by haller＠ableton.com 19 Jan '06

19 Jan '06

site_archiver(a)lists.apple.com Delivered-To: darwin-dev(a)lists.apple.com Organization: Ableton User-agent: MacSOUP/2.7 (Mac OS X version 10.4.3) I'm wondering if or when we can expect the MoreBacktrace stuff from the MoreIsBetter sample code to be ported to i386? -- Stefan Haller Ableton http://www.ableton.com/ _______________________________________________ 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