From sacadmin Tue Mar 20 14:22:28 2007 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KLMSG1008234 for ; Tue, 20 Mar 2007 14:22:28 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2KLMRiu020419; Tue, 20 Mar 2007 14:22:27 -0700 (PDT) Message-ID: <46005062.5030108@Sun.COM> Date: Tue, 20 Mar 2007 14:21:38 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0b2 (X11/20070227) MIME-Version: 1.0 To: psarc@sac.sfbay.sun.com CC: Dan Price Subject: PSARC/2007/162 Backtrace() and friends for Solaris Content-Type: multipart/mixed; boundary="------------030008050206030502060500" Status: RO Content-Length: 5447 This is a multi-part message in MIME format. --------------030008050206030502060500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I sponsoring the attached case for myself. It times out on 3/28/2007. I'm requesting minor release binding. From the case: Several popular open source software programs use the glibc functions backtrace(), backtrace_symbols(), and backtrace_symbols_fd to generate symbolic stack traces when things go badly wrong. This case proposes to add these functions to libc. In addition, this cases exports a function unique to Solaris to produce a symbolic representation of a program counter. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts --------------030008050206030502060500 Content-Type: text/plain; name="backtrace.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="backtrace.txt" 1. Introduction 1.1. Project/Component Working Name: Backtrace() and friends for Solaris 1.2. Name of Document Author/Supplier: Author: Bart Smaalders 1.3 Date of This Document: March 19, 2007 4. Technical Description Several popular open source software programs use the glibc functions backtrace(), backtrace_symbols(), and backtrace_symbols_fd to generate symbolic stack traces when things go badly wrong. This case proposes to add these functions to libc. Minor release binding is requested. They are implemented using the walkcontext() and printstack() code the author added to libc in Solaris 9. These functions are added as Committed. The representation of the stack backtrace is volatile; it changes depending on information available in the symbol tables. SYNOPSIS Glibc-equiv. functions: int backtrace(void **buffer, int size); char **backtrace_symbols(void *const *buffer, int size); void backtrace_symbols_fd(void *const *buffer, int size, int fd); In addition, this cases exports a function unique to Solaris to produce a symbolic representation of a program counter: int addrtosymstr(uintptr_t addr, char *buffer, int len); DESCRIPTION The addrtosymstr function attempts to convert a PC into a symbolic representation of the form objname'funcname+0xoffset[0xPC] where the objname is the module in which the PC is located, the funcname is the name of the function and the offset is the offset from the beginning of the function. The objname, funcname and offset values are obtained from dladdr1(3C) and may not always be present. The resulting string is written to the user-supplied buffer. Should the length of the string be larger than the user-supplied buffer, only the portion of the string that will fit is written and null-terminated. This function is async signal safe. The backtrace() function uses walkcontext() to generate a stack backtrace for the calling thread and place it into the array specified by the buffer argument. Size specifies the maximum number of program counters that will be recorded. This function is provided for glibc compatibility. The backtrace_symbols() function translates the numerical program counter values previously recorded by a call to backtrace() in the buffer argument, and converts, where possible, each PC into a string indicating the module, function and offset of each call site. The number of symbols present in the array must be passed in via the size argument. The set of strings is returned in an array obtained from a call to malloc(); it is the responsiblity of the caller to pass the returned pointer to free(). Note that the individual strings must not be freed. Since malloc() is used to obtain the needed space, this function is NOT async- signal safe and cannot be used reliably from a signal handler. This function is provided for glibc compatibility. The backtrace_symbols_fd() function translates the numerical program counter values previously recorded by a call to backtrace() in the buffer argument, and converts, where possible, each PC into a string indicating the module, function and offset of each call site. These strings are written out to the file descriptor specified in the argument fd. This function is async signal safe. This function is provided for glibc compatibility. RETURN VALUES Addrtosymstr() returns the number of characters necessary to hold the entire string representation of the passed in address, irrespective of the size of the user-supplied buffer. Backtrace() returns the number of stack frames captured. Backtrace_symbols() returns a pointer to an array containing string representations of the calling sequence. USAGE The string representation generated by addrtosymstr() and displayed by by printstack(), backtrace_symbols() and backtrace_symbols_fd is unstable and will change depending on the information available in the modules that comprise the stack trace. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack --------------030008050206030502060500-- From sacadmin Tue Mar 20 14:39:15 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KLdFNc008663 for ; Tue, 20 Mar 2007 14:39:15 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-1.SFBay.Sun.COM [10.4.134.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2KLdFi9013086 for ; Tue, 20 Mar 2007 14:39:15 -0700 (PDT) Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2KLd9vE019430 for ; Tue, 20 Mar 2007 13:39:09 -0800 (PST) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JF800G011CNDZ00@d1-sfbay-09.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 20 Mar 2007 14:39:09 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JF80070R1H927T0@d1-sfbay-09.sun.com>; Tue, 20 Mar 2007 14:39:09 -0700 (PDT) Date: Tue, 20 Mar 2007 14:38:51 -0700 From: Ed Gould Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <46005062.5030108@Sun.COM> Sender: Ed.Gould@Sun.COM To: Bart Smaalders Cc: psarc@sac.sfbay.sun.com, Dan Price Message-id: <4600546B.1080301@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_v6KpJ/uuZw9gefMDxqaSkA)" References: <46005062.5030108@Sun.COM> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 1167 This is a multi-part message in MIME format. --Boundary_(ID_v6KpJ/uuZw9gefMDxqaSkA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Bart Smaalders wrote: > These functions are added as Committed. The representation of > the stack backtrace is volatile; it changes depending on > information available in the symbol tables. Is the backtrace usable only by humans? If it is, then perhaps it's not an interface. > Backtrace_symbols() returns a pointer to an array containing > string representations of the calling sequence. Doesn't sound thread safe. Is there no need for it to be? -- --Ed --Boundary_(ID_v6KpJ/uuZw9gefMDxqaSkA) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Solaris Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_v6KpJ/uuZw9gefMDxqaSkA)-- From sacadmin Tue Mar 20 14:41:13 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KLfDe6008785 for ; Tue, 20 Mar 2007 14:41:13 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2KLfDF9013937 for ; Tue, 20 Mar 2007 14:41:13 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2KLf8k2007552 for ; Tue, 20 Mar 2007 13:41:08 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JF800H011GZJD00@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 20 Mar 2007 14:41:08 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JF800MKO1KJDBCN@d1-sfbay-10.sun.com>; Tue, 20 Mar 2007 14:41:07 -0700 (PDT) Date: Tue, 20 Mar 2007 14:40:49 -0700 From: Ed Gould Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <46005062.5030108@Sun.COM> Sender: Ed.Gould@Sun.COM To: Bart Smaalders Cc: psarc@sac.sfbay.sun.com, Dan Price Message-id: <460054E1.8000301@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_9P1fV3E2Wqn5t09MM1HKhg)" References: <46005062.5030108@Sun.COM> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 882 This is a multi-part message in MIME format. --Boundary_(ID_9P1fV3E2Wqn5t09MM1HKhg) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Bart Smaalders wrote: > I sponsoring the attached case for myself. It times > out on 3/28/2007. I'm requesting minor release binding. Is there a reason this is not an open case? -- --Ed --Boundary_(ID_9P1fV3E2Wqn5t09MM1HKhg) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Solaris Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_9P1fV3E2Wqn5t09MM1HKhg)-- From sacadmin Tue Mar 20 14:43:27 2007 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KLhR0t009144 for ; Tue, 20 Mar 2007 14:43:27 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2KLhRgT021090; Tue, 20 Mar 2007 14:43:27 -0700 (PDT) Message-ID: <4600554D.4060504@Sun.COM> Date: Tue, 20 Mar 2007 14:42:37 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0b2 (X11/20070227) MIME-Version: 1.0 To: Ed Gould CC: psarc@sac.sfbay.sun.com, Dan Price Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris References: <46005062.5030108@Sun.COM> <4600546B.1080301@sun.com> In-Reply-To: <4600546B.1080301@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 773 Ed Gould wrote: > Bart Smaalders wrote: >> These functions are added as Committed. The representation of >> the stack backtrace is volatile; it changes depending on information >> available in the symbol tables. > > Is the backtrace usable only by humans? If it is, then perhaps it's not > an interface. > >> Backtrace_symbols() returns a pointer to an array containing >> string representations of the calling sequence. > > Doesn't sound thread safe. Is there no need for it to be? It's thread safe; due to its use of malloc it is not async signal safe. Use backtrace_symbols_fd from a signal handler. This is a lot like our printstack(fd). - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sacadmin Tue Mar 20 14:43:59 2007 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KLhxf1009178 for ; Tue, 20 Mar 2007 14:43:59 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2KLhw4a021100; Tue, 20 Mar 2007 14:43:58 -0700 (PDT) Message-ID: <4600556C.5070300@Sun.COM> Date: Tue, 20 Mar 2007 14:43:08 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0b2 (X11/20070227) MIME-Version: 1.0 To: Ed Gould CC: psarc@sac.sfbay.sun.com, Dan Price Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris References: <46005062.5030108@Sun.COM> <460054E1.8000301@sun.com> In-Reply-To: <460054E1.8000301@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 349 Ed Gould wrote: > Bart Smaalders wrote: >> I sponsoring the attached case for myself. It times >> out on 3/28/2007. I'm requesting minor release binding. > > Is there a reason this is not an open case? brain fart. How do I switch it? - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sacadmin Tue Mar 20 14:46:06 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KLk6DW009478 for ; Tue, 20 Mar 2007 14:46:06 -0700 (PDT) Received: from nwk-ea-fw-1.sun.com (nwkes-gis-mail-2.SFBay.Sun.COM [10.4.134.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l2KLk6nh027094 for ; Tue, 20 Mar 2007 14:46:06 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2KLk1v7008233 for ; Tue, 20 Mar 2007 13:46:01 -0800 (PST) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JF800L011QG0W00@d1-sfbay-10.sun.com> (original mail from Ed.Gould@Sun.COM) for psarc@sac.sfbay.sun.com; Tue, 20 Mar 2007 14:46:01 -0700 (PDT) Received: from [129.146.106.203] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JF800MUL1SOD75T@d1-sfbay-10.sun.com>; Tue, 20 Mar 2007 14:46:00 -0700 (PDT) Date: Tue, 20 Mar 2007 14:45:42 -0700 From: Ed Gould Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <4600556C.5070300@Sun.COM> Sender: Ed.Gould@Sun.COM To: Bart Smaalders Cc: psarc@sac.sfbay.sun.com, Dan Price Message-id: <46005606.5040006@sun.com> Organization: Sun Cluster Engineering - GDD MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_haYCuXQOHiuBKbujTiXrWQ)" References: <46005062.5030108@Sun.COM> <460054E1.8000301@sun.com> <4600556C.5070300@Sun.COM> User-Agent: Thunderbird 1.5 (X11/20060113) Status: RO Content-Length: 902 This is a multi-part message in MIME format. --Boundary_(ID_haYCuXQOHiuBKbujTiXrWQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Bart Smaalders wrote: >> Is there a reason this is not an open case? > > brain fart. > > How do I switch it? Change the "Exposure" entry in the IAM file to "open" and re-post to psarc-ext@sun.com. -- --Ed --Boundary_(ID_haYCuXQOHiuBKbujTiXrWQ) Content-type: text/x-vcard; name=ed.gould.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ed.gould.vcf begin:vcard fn:Ed Gould n:Gould;Ed org:Sun Microsystems, Inc.;Solaris Cluster adr;dom:M/S UMPK17-201;;17 Network Circle;Menlo Park;CA;94025 email;internet:ed.gould@sun.com title:File System Architect, PSARC Chair tel;work:+1.650.786.4937 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_haYCuXQOHiuBKbujTiXrWQ)-- From bart.smaalders@sun.com Tue Mar 20 14:48:39 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KLmcAR009667 for ; Tue, 20 Mar 2007 14:48:39 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2KLmYtN002353 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@Sun.COM>; Tue, 20 Mar 2007 21:48:37 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF800E011X0Q900@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 20 Mar 2007 14:48:36 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF800E9G1X0NW00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 20 Mar 2007 14:48:36 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2KLmaf3012052 for ; Tue, 20 Mar 2007 14:48:36 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2KLmash021281 for ; Tue, 20 Mar 2007 14:48:36 -0700 (PDT) Date: Tue, 20 Mar 2007 14:47:46 -0700 From: Bart Smaalders Subject: PSARC/2007/162 Backtrace() and friends for Solaris To: PSARC-EXT@sun.com Message-id: <46005682.3010508@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_SChLT3ia94kO26jvdB+gPw)" X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 5501 This is a multi-part message in MIME format. --Boundary_(ID_SChLT3ia94kO26jvdB+gPw) Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT I sponsoring the attached case for myself. It times out on 3/28/2007. I'm requesting minor release binding. From the case: Several popular open source software programs use the glibc functions backtrace(), backtrace_symbols(), and backtrace_symbols_fd to generate symbolic stack traces when things go badly wrong. This case proposes to add these functions to libc. In addition, this cases exports a function unique to Solaris to produce a symbolic representation of a program counter. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts --Boundary_(ID_SChLT3ia94kO26jvdB+gPw) Content-type: text/plain; name=backtrace.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=backtrace.txt 1. Introduction 1.1. Project/Component Working Name: Backtrace() and friends for Solaris 1.2. Name of Document Author/Supplier: Author: Bart Smaalders 1.3 Date of This Document: March 19, 2007 4. Technical Description Several popular open source software programs use the glibc functions backtrace(), backtrace_symbols(), and backtrace_symbols_fd to generate symbolic stack traces when things go badly wrong. This case proposes to add these functions to libc. Minor release binding is requested. They are implemented using the walkcontext() and printstack() code the author added to libc in Solaris 9. These functions are added as Committed. The representation of the stack backtrace is volatile; it changes depending on information available in the symbol tables. SYNOPSIS Glibc-equiv. functions: int backtrace(void **buffer, int size); char **backtrace_symbols(void *const *buffer, int size); void backtrace_symbols_fd(void *const *buffer, int size, int fd); In addition, this cases exports a function unique to Solaris to produce a symbolic representation of a program counter: int addrtosymstr(uintptr_t addr, char *buffer, int len); DESCRIPTION The addrtosymstr function attempts to convert a PC into a symbolic representation of the form objname'funcname+0xoffset[0xPC] where the objname is the module in which the PC is located, the funcname is the name of the function and the offset is the offset from the beginning of the function. The objname, funcname and offset values are obtained from dladdr1(3C) and may not always be present. The resulting string is written to the user-supplied buffer. Should the length of the string be larger than the user-supplied buffer, only the portion of the string that will fit is written and null-terminated. This function is async signal safe. The backtrace() function uses walkcontext() to generate a stack backtrace for the calling thread and place it into the array specified by the buffer argument. Size specifies the maximum number of program counters that will be recorded. This function is provided for glibc compatibility. The backtrace_symbols() function translates the numerical program counter values previously recorded by a call to backtrace() in the buffer argument, and converts, where possible, each PC into a string indicating the module, function and offset of each call site. The number of symbols present in the array must be passed in via the size argument. The set of strings is returned in an array obtained from a call to malloc(); it is the responsiblity of the caller to pass the returned pointer to free(). Note that the individual strings must not be freed. Since malloc() is used to obtain the needed space, this function is NOT async- signal safe and cannot be used reliably from a signal handler. This function is provided for glibc compatibility. The backtrace_symbols_fd() function translates the numerical program counter values previously recorded by a call to backtrace() in the buffer argument, and converts, where possible, each PC into a string indicating the module, function and offset of each call site. These strings are written out to the file descriptor specified in the argument fd. This function is async signal safe. This function is provided for glibc compatibility. RETURN VALUES Addrtosymstr() returns the number of characters necessary to hold the entire string representation of the passed in address, irrespective of the size of the user-supplied buffer. Backtrace() returns the number of stack frames captured. Backtrace_symbols() returns a pointer to an array containing string representations of the calling sequence. USAGE The string representation generated by addrtosymstr() and displayed by by printstack(), backtrace_symbols() and backtrace_symbols_fd is unstable and will change depending on the information available in the modules that comprise the stack trace. 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack --Boundary_(ID_SChLT3ia94kO26jvdB+gPw)-- From sacadmin Tue Mar 20 15:20:57 2007 Received: from jurassic-x4600.Eng.Sun.COM (cretaceous.SFBay.Sun.COM [129.146.17.59]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KMKuAe010842 for ; Tue, 20 Mar 2007 15:20:57 -0700 (PDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2KMKtVq927570; Tue, 20 Mar 2007 15:20:56 -0700 (PDT) Message-ID: <46005E43.9000706@sun.com> Date: Tue, 20 Mar 2007 12:20:51 -1000 From: Joseph Kowalski User-Agent: Thunderbird 1.5.0.5 (X11/20060925) MIME-Version: 1.0 To: Bart Smaalders CC: psarc@sac.sfbay.sun.com, Dan Price Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris References: <46005062.5030108@Sun.COM> In-Reply-To: <46005062.5030108@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1108 Bart Smaalders wrote: Nice stuff. A couple of nits... > These functions are added as Committed. The representation of > the stack backtrace is volatile; it changes depending on > information available in the symbol tables. > Rather than Volatile, how about "not an interface". This seems like one of the cases where it is useful to be explicit about this. > SYNOPSIS > > Glibc-equiv. functions: > > int backtrace(void **buffer, int size); > > char **backtrace_symbols(void *const *buffer, int size); > > void backtrace_symbols_fd(void *const *buffer, int size, int fd); > > In addition, this cases exports a function unique to Solaris to produce > a symbolic representation of a program counter: > > int addrtosymstr(uintptr_t addr, char *buffer, int len); > Are the "where these come from" comments to be included in our man page? Seems like a lot of work to do this for all of our interfaces. Many routines have noted things like this in either the DESCRIPTION, USAGE or NOTES sections. I'd rather see this information there, if it provides value. - jek3 From sacadmin Tue Mar 20 15:31:32 2007 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KMVVZG010886 for ; Tue, 20 Mar 2007 15:31:32 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2KMVTtY020821; Tue, 20 Mar 2007 18:31:29 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by thunk.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l2KMVP4w018979; Tue, 20 Mar 2007 18:31:25 -0400 (EDT) Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris From: Bill Sommerfeld To: Bart Smaalders Cc: psarc@sac.sfbay.sun.com, Dan Price In-Reply-To: <46005062.5030108@Sun.COM> References: <46005062.5030108@Sun.COM> Content-Type: text/plain Date: Tue, 20 Mar 2007 18:31:24 -0400 Message-Id: <1174429884.17563.59.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 928 On Tue, 2007-03-20 at 14:21 -0700, Bart Smaalders wrote: > Addrtosymstr() returns the number of characters necessary > to hold the entire string representation of the passed in > address, irrespective of the size of the user-supplied buffer. > > Backtrace() returns the number of stack frames captured. > > Backtrace_symbols() returns a pointer to an array containing > string representations of the calling sequence. This is a nit, but I assume you're actually documenting the behavior of addrtosymstr(), backtrace() and backtrace_symbols() rather than Addrtosymstr(), Backtrace() and Backtrace_symbols() here, and that the case title should say "backtrace() and friends" instead of "Backtrace() and friends" (I generally deal with the conflicting capitalization conventions of C and English by phrasing this sort of thing as: "The addrtosymstr() function returns the ..") - Bill From dwc@spartan.eng.sun.com Tue Mar 20 15:57:35 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KMvZNX011497 for ; Tue, 20 Mar 2007 15:57:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2KMvYvT001879; Tue, 20 Mar 2007 15:57:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF800H0953XZC00@nwk-avmta-2.sfbay.sun.com>; Tue, 20 Mar 2007 15:57:33 -0700 (PDT) Received: from spartan.SFBay.Sun.COM ([129.146.226.64]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF800E5W53XNWE0@nwk-avmta-2.sfbay.sun.com>; Tue, 20 Mar 2007 15:57:33 -0700 (PDT) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6) with ESMTP id l2KMvW4c020810; Tue, 20 Mar 2007 14:57:32 -0800 (PST) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.13.6+Sun/8.13.6/Submit) id l2KMvWEq020809; Tue, 20 Mar 2007 15:57:32 -0700 (PDT) Date: Tue, 20 Mar 2007 15:57:32 -0700 (PDT) From: Don Cragun Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris To: PSARC-EXT@sun.com, bart.smaalders@sun.com Message-id: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 636 > int backtrace(void **buffer, int size); > char **backtrace_symbols(void *const *buffer, int size); > void backtrace_symbols_fd(void *const *buffer, int size, int fd); > int addrtosymstr(uintptr_t addr, char *buffer, int len); Shouldn't the "int"s here that refer to buffer sizes be "size_t"s or "ssize_t"s instead? Or is there really an intent here to limit these buffer sizes to 32 bits on 64-bit architectures? Do any of these functions ever fail? I see no mention of error returns nor of errno settings. If would seem like attempts to backtrace through a corrupted stack could lead to failures. Cheers, Don From gsf@research.att.com Tue Mar 20 16:36:33 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KNaXOh012190 for ; Tue, 20 Mar 2007 16:36:33 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2KNaQSP001026; Tue, 20 Mar 2007 23:36:29 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF8005036WRSN00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Mar 2007 16:36:27 -0700 (PDT) Received: from sca-ea-mail-3.sun.com ([192.18.43.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF800M286WRWC40@nwk-avmta-1.sfbay.Sun.COM>; Tue, 20 Mar 2007 16:36:27 -0700 (PDT) Received: from relay23.sun.com (relay23.sun.com [192.12.251.54] (may be forged)) by sca-ea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2KNaQqx020607; Tue, 20 Mar 2007 23:36:27 +0000 (GMT) Received: from mms25es.sun.com ([150.143.232.94] [150.143.232.94]) by relay23.sun.com with ESMTP; Tue, 20 Mar 2007 23:36:26 +0000 (Z) Received: from mms24bas.mms.us.syntegra.com (mms24bas.mms.us.syntegra.com [192.12.251.70]) by mms25es.sun.com with ESMTP id BT-MMP-1499289; Tue, 20 Mar 2007 23:36:25 +0000 (Z) Received: from mail-red.research.att.com ([192.20.225.110] [192.20.225.110]) by relay24.sun.com with ESMTP; Tue, 20 Mar 2007 23:36:25 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-blue.research.att.com (Postfix) with ESMTP id AAE3B147A79; Tue, 20 Mar 2007 19:36:23 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id l2KNaNeP015134; Tue, 20 Mar 2007 19:36:23 -0400 Date: Tue, 20 Mar 2007 19:36:23 -0400 From: Glenn Fowler Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris To: bart.smaalders@sun.com, don.cragun@sun.com, PSARC-EXT@sun.com Message-id: <200703202336.l2KNaNeP015134@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2006-04-17 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> Status: RO Content-Length: 1285 outsider input (but, by coincidence, deeply imbedded with tracebacks for the last two weeks): its a mistake to have any traceback function call malloc(), since plugging memory leaks must be near the top of traceback requirements list backtrace() puts the info in a user buf,siz an appropriately renamed backtrace_symbols() should to the same with feedback when the buffer size is insufficient -- Glenn Fowler -- AT&T Research, Florham Park NJ -- On Tue, 20 Mar 2007 15:57:32 -0700 (PDT) Don Cragun wrote: > > int backtrace(void **buffer, int size); > > char **backtrace_symbols(void *const *buffer, int size); > > void backtrace_symbols_fd(void *const *buffer, int size, int fd); > > int addrtosymstr(uintptr_t addr, char *buffer, int len); > Shouldn't the "int"s here that refer to buffer sizes be "size_t"s or > "ssize_t"s instead? Or is there really an intent here to limit these > buffer sizes to 32 bits on 64-bit architectures? > Do any of these functions ever fail? I see no mention of error returns > nor of errno settings. If would seem like attempts to backtrace > through a corrupted stack could lead to failures. > Cheers, > Don > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org From bart.smaalders@sun.com Tue Mar 20 16:40:06 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KNe6CJ012474 for ; Tue, 20 Mar 2007 16:40:06 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2KNe2Xa002006 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@Sun.COM>; Tue, 20 Mar 2007 16:40:06 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF800K1972R7W00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 20 Mar 2007 16:40:03 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF800IVE72R4O10@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 20 Mar 2007 16:40:03 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2KNe2UP001112; Tue, 20 Mar 2007 16:40:02 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2KNe2mM024585; Tue, 20 Mar 2007 16:40:02 -0700 (PDT) Date: Tue, 20 Mar 2007 16:39:12 -0700 From: Bart Smaalders Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> To: Don Cragun Cc: PSARC-EXT@sun.com Message-id: <460070A0.4030503@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1502 Don Cragun wrote: >> int backtrace(void **buffer, int size); >> char **backtrace_symbols(void *const *buffer, int size); >> void backtrace_symbols_fd(void *const *buffer, int size, int fd); >> int addrtosymstr(uintptr_t addr, char *buffer, int len); > > Shouldn't the "int"s here that refer to buffer sizes be "size_t"s or > "ssize_t"s instead? Or is there really an intent here to limit these > buffer sizes to 32 bits on 64-bit architectures? The first three interfaces come from glibc; I'm copying them verbatim. I seriously doubt the restriction of having less than 2GB separate stack frames in a stack trace will prove limiting anytime soon. In the last interface the length of the returned string is limited by len; I expect 2GB should be adequate to represent the filename, library name and symbol + offsets for some time to come. > > Do any of these functions ever fail? I see no mention of error returns > nor of errno settings. If would seem like attempts to backtrace > through a corrupted stack could lead to failures. > > Cheers, > Don Errno isn't set to any useful value by these functions. Our implementation attempts to protect against corrupted stacks; there is no defined error semantics for these functions. Our addrtosymstr function does a best effort job of printing the address; at worstit simply prints the hex address in square brackets. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From bart.smaalders@Sun.COM Tue Mar 20 16:44:29 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KNiS3N012537 for ; Tue, 20 Mar 2007 16:44:29 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2KNiRpO003063 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@Sun.COM>; Tue, 20 Mar 2007 23:44:27 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF8006037A2JW00@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 20 Mar 2007 16:44:26 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF800M5Q7A2WL30@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Tue, 20 Mar 2007 16:44:26 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2KNiQYN001707; Tue, 20 Mar 2007 16:44:26 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2KNiPxg024783; Tue, 20 Mar 2007 16:44:26 -0700 (PDT) Date: Tue, 20 Mar 2007 16:43:35 -0700 From: Bart Smaalders Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <200703202336.l2KNaNeP015134@penguin.research.att.com> To: Glenn Fowler Cc: don.cragun@Sun.COM, PSARC-EXT@Sun.COM Message-id: <460071A7.6090103@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> <200703202336.l2KNaNeP015134@penguin.research.att.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 719 Glenn Fowler wrote: > outsider input (but, by coincidence, deeply imbedded with tracebacks > for the last two weeks): its a mistake to have any traceback > function call malloc(), since plugging memory leaks must be > near the top of traceback requirements list > > backtrace() puts the info in a user buf,siz > an appropriately renamed backtrace_symbols() should to the same > with feedback when the buffer size is insufficient > Do you think providing a Solaris-only version of this is useful? I've added addrtosymstr(), which allows the user to create whatever he wants with backtrace() pretty easily. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sacadmin Tue Mar 20 16:45:58 2007 Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2KNjw4h012551 for ; Tue, 20 Mar 2007 16:45:58 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2KNjw1K024837; Tue, 20 Mar 2007 16:45:58 -0700 (PDT) Message-ID: <46007203.1070504@Sun.COM> Date: Tue, 20 Mar 2007 16:45:07 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0b2 (X11/20070227) MIME-Version: 1.0 To: Joseph Kowalski CC: psarc@sac.sfbay.sun.com, Dan Price Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris References: <46005062.5030108@Sun.COM> <46005E43.9000706@sun.com> In-Reply-To: <46005E43.9000706@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1326 Joseph Kowalski wrote: > Bart Smaalders wrote: > > Nice stuff. A couple of nits... >> These functions are added as Committed. The representation of >> the stack backtrace is volatile; it changes depending on information >> available in the symbol tables. >> > Rather than Volatile, how about "not an interface". This seems like one of > the cases where it is useful to be explicit about this. Sure. >> SYNOPSIS >> >> Glibc-equiv. functions: >> >> int backtrace(void **buffer, int size); >> >> char **backtrace_symbols(void *const *buffer, int size); >> void backtrace_symbols_fd(void *const *buffer, int size, int >> fd); >> In addition, this cases exports a function unique to Solaris to >> produce a symbolic representation of a program counter: >> >> int addrtosymstr(uintptr_t addr, char *buffer, int len); >> > Are the "where these come from" comments to be included in our man page? > > Seems like a lot of work to do this for all of our interfaces. > > Many routines have noted things like this in either the DESCRIPTION, > USAGE or > NOTES sections. I'd rather see this information there, if it provides > value. > > - jek3 > Ok... I'll fix the man page. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sacadmin Tue Mar 20 19:56:09 2007 Received: from domus.sfbay.sun.com (domus.SFBay.Sun.COM [10.6.64.11]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2L2u99I015502 for ; Tue, 20 Mar 2007 19:56:09 -0700 (PDT) Received: from [192.9.61.51] (punchin-rotondo.SFBay.Sun.COM [192.9.61.51]) by domus.sfbay.sun.com (Trusted Solaris (8.11.7)/8.11.6) with ESMTP id l2L2u7T22139; Tue, 20 Mar 2007 19:56:07 -0700 (PDT) Message-ID: <46009EC3.8090704@sun.com> Date: Tue, 20 Mar 2007 19:56:03 -0700 From: Scott Rotondo User-Agent: Thunderbird 1.5.0.8 (X11/20061204) MIME-Version: 1.0 To: Bill Sommerfeld CC: Bart Smaalders , psarc@sac.sfbay.sun.com, Dan Price Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris References: <46005062.5030108@Sun.COM> <1174429884.17563.59.camel@thunk> In-Reply-To: <1174429884.17563.59.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 631 [I'll probably be sorry for continuing this particular tangent...] Bill Sommerfeld wrote: > (I generally deal with the conflicting capitalization conventions of C > and English by phrasing this sort of thing as: > > "The addrtosymstr() function returns the ..") > > - Bill I completely agree with this solution, as did another Bill (Safire) when explaining how to choose whether to use "who" or "whom": "When whom is correct, recast the sentence." ("On Language," New York Times, 4 October 1992). Nevertheless, if I *do* start a sentence with a function name (or UNIX command), I capitalize it like English. Scott From gsf@research.att.com Wed Mar 21 10:01:17 2007 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LH1Haa002593 for ; Wed, 21 Mar 2007 10:01:17 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LH1FID002621; Wed, 21 Mar 2007 10:01:16 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900403JA4FI00@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 11:01:16 -0600 (MDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900J45JA3SLF0@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 11:01:15 -0600 (MDT) Received: from relay21.sun.com (relay21.sun.com [192.12.251.14] (may be forged)) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2LH1E8m013471; Wed, 21 Mar 2007 17:01:15 +0000 (GMT) Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay21.sun.com with ESMTP; Wed, 21 Mar 2007 17:01:14 +0000 (Z) Received: from mms25bas.mms.us.syntegra.com (mms25bas.mms.us.syntegra.com [192.12.251.90]) by mms24es.sun.com with ESMTP id BT-MMP-1953852; Wed, 21 Mar 2007 17:01:14 +0000 (Z) Received: from mail-red.research.att.com ([192.20.225.110] [192.20.225.110]) by relay21.sun.com with ESMTP; Wed, 21 Mar 2007 17:01:14 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-green.research.att.com (Postfix) with ESMTP id 4BBAD8536; Wed, 21 Mar 2007 13:01:14 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id l2LH1ESv006521; Wed, 21 Mar 2007 13:01:14 -0400 Date: Wed, 21 Mar 2007 13:01:14 -0400 From: Glenn Fowler Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris To: bart.smaalders@sun.com, gsf@research.att.com Cc: don.cragun@sun.com, PSARC-EXT@sun.com Message-id: <200703211701.l2LH1ESv006521@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2006-04-17 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> <200703202336.l2KNaNeP015134@penguin.research.att.com> <460071A7.6090103@Sun.COM> Status: RO Content-Length: 1018 On Tue, 20 Mar 2007 16:43:35 -0700 Bart Smaalders wrote: > Glenn Fowler wrote: > > outsider input (but, by coincidence, deeply imbedded with tracebacks > > for the last two weeks): its a mistake to have any traceback > > function call malloc(), since plugging memory leaks must be > > near the top of traceback requirements list > > > > backtrace() puts the info in a user buf,siz > > an appropriately renamed backtrace_symbols() should to the same > > with feedback when the buffer size is insufficient > Do you think providing a Solaris-only version of this is > useful? I've added addrtosymstr(), which allows the > user to create whatever he wants with backtrace() pretty > easily. from a technical perspective provide a non-malloc api with proper error handling and then wrap the gnu api on top of that from political perspective gnu has grabbed the api does that trump providing a (possibly better) api? you have to pick the right moment to battle de-facto vs de-best this may not be one of those moments From bart.smaalders@Sun.COM Wed Mar 21 10:25:52 2007 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LHPqJu004326 for ; Wed, 21 Mar 2007 10:25:52 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LHPpqi029379 for <@sunmail3mpk.sfbay.sun.com:PSARC-EXT@Sun.COM>; Wed, 21 Mar 2007 10:25:52 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900101KF3VG00@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 10:25:51 -0700 (PDT) Received: from engmail3mpk.sfbay.Sun.COM ([129.146.11.26]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900L7TKF10G70@nwk-avmta-2.sfbay.sun.com> for PSARC-EXT@Sun.COM (ORCPT PSARC-EXT@Sun.COM); Wed, 21 Mar 2007 10:25:49 -0700 (PDT) Received: from zion.eng.sun.com (zion.SFBay.Sun.COM [129.146.17.75]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2LHPmx3002106; Wed, 21 Mar 2007 10:25:48 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l2LHPmGO004243; Wed, 21 Mar 2007 10:25:48 -0700 (PDT) Date: Wed, 21 Mar 2007 10:24:56 -0700 From: Bart Smaalders Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <200703211701.l2LH1ESv006521@penguin.research.att.com> To: Glenn Fowler Cc: don.cragun@Sun.COM, PSARC-EXT@Sun.COM Message-id: <46016A68.2020106@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> <200703202336.l2KNaNeP015134@penguin.research.att.com> <460071A7.6090103@Sun.COM> <200703211701.l2LH1ESv006521@penguin.research.att.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1664 Glenn Fowler wrote: > On Tue, 20 Mar 2007 16:43:35 -0700 Bart Smaalders wrote: >> Glenn Fowler wrote: >>> outsider input (but, by coincidence, deeply imbedded with tracebacks >>> for the last two weeks): its a mistake to have any traceback >>> function call malloc(), since plugging memory leaks must be >>> near the top of traceback requirements list >>> >>> backtrace() puts the info in a user buf,siz >>> an appropriately renamed backtrace_symbols() should to the same >>> with feedback when the buffer size is insufficient > >> Do you think providing a Solaris-only version of this is >> useful? I've added addrtosymstr(), which allows the >> user to create whatever he wants with backtrace() pretty >> easily. > > from a technical perspective provide a non-malloc api with > proper error handling and then wrap the gnu api on top of that > That's what we've done so far. The semantics of the api requires that the pointer returned from backtrace_symbols() be able to be passed to free(); it's documented that way. Given that malloc & friends are often interposed upon, I couldn't come up with a way of not using malloc. > from political perspective gnu has grabbed the api > does that trump providing a (possibly better) api? > you have to pick the right moment to battle de-facto vs de-best > this may not be one of those moments > Solaris already has better, simpler APIs; see walkcontext(3) and printstack(). I am proposing to add these (potential usage warts and all) to provide source compatibility for more open source applications. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From casper@holland.sun.com Wed Mar 21 10:33:30 2007 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LHXTD0004365 for ; Wed, 21 Mar 2007 10:33:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id l2LHXDQm010634 for <@sunmail2sca.sfbay.sun.com:PSARC-EXT@sun.com>; Thu, 22 Mar 2007 01:33:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900L0HKRQC900@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 21 Mar 2007 10:33:26 -0700 (PDT) Received: from dm-holland-01.uk.sun.com ([129.156.101.192]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900K40KROZ620@nwk-avmta-1.sfbay.Sun.COM> for PSARC-EXT@sun.com (ORCPT PSARC-EXT@sun.com); Wed, 21 Mar 2007 10:33:25 -0700 (PDT) Received: from vaticaan.holland.sun.com (vaticaan.Holland.Sun.COM [129.159.212.1]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l2LHXIQe011136; Wed, 21 Mar 2007 17:33:18 +0000 (GMT) Received: from holland (room101 [129.159.248.23]) by vaticaan.holland.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2LHXIcJ010130; Wed, 21 Mar 2007 18:33:18 +0100 (MET) Date: Wed, 21 Mar 2007 18:32:46 +0100 From: casper.dik@sun.com Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <46016A68.2020106@Sun.COM> Sender: casper@holland.sun.com To: Bart Smaalders Cc: Glenn Fowler , don.cragun@sun.com, PSARC-EXT@sun.com Message-id: <200703211733.l2LHXIcJ010130@vaticaan.holland.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> <200703202336.l2KNaNeP015134@penguin.research.att.com> <460071A7.6090103@Sun.COM> <200703211701.l2LH1ESv006521@penguin.research.att.com> <46016A68.2020106@Sun.COM> Status: RO Content-Length: 376 >That's what we've done so far. The semantics of the >api requires that the pointer returned from backtrace_symbols() >be able to be passed to free(); it's documented that way. >Given that malloc & friends are often interposed upon, >I couldn't come up with a way of not using malloc. So this function cannot be called from a signalhandler to provide a stacktrace? Casper From Paul.Jakma@sun.com Wed Mar 21 10:47:11 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LHlAQp004665 for ; Wed, 21 Mar 2007 10:47:11 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LHkdGl006413; Wed, 21 Mar 2007 17:47:07 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900M31LEIGU00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 10:47:06 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900KQILE3Z680@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 10:46:54 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2LHko0O021485; Wed, 21 Mar 2007 17:46:50 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JF900H01L88IK00@d1-emea-09.sun.com> (original mail from Paul.Jakma@Sun.COM); Wed, 21 Mar 2007 17:46:50 +0000 (GMT) Received: from melandri.lan ([62.6.163.68]) by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JF9003OYLDX5740@d1-emea-09.sun.com>; Wed, 21 Mar 2007 17:46:46 +0000 (GMT) Date: Wed, 21 Mar 2007 17:46:42 +0000 (GMT) From: Paul Jakma Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <200703211733.l2LHXIcJ010130@vaticaan.holland.sun.com> Sender: Paul.Jakma@sun.com To: Casper.Dik@sun.com Cc: Bart Smaalders , Glenn Fowler , don.cragun@sun.com, PSARC-EXT@sun.com Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> <200703202336.l2KNaNeP015134@penguin.research.att.com> <460071A7.6090103@Sun.COM> <200703211701.l2LH1ESv006521@penguin.research.att.com> <46016A68.2020106@Sun.COM> <200703211733.l2LHXIcJ010130@vaticaan.holland.sun.com> Status: RO Content-Length: 389 On Wed, 21 Mar 2007, Casper.Dik@Sun.COM wrote: > So this function cannot be called from a signalhandler > to provide a stacktrace? You'd use printstack() for that. ;) backtrace_symbols() can't be used either in such a case, you need to use backtrace_symbols_fd(). regards, -- Paul Jakma, Solaris Networking http://opensolaris.org/os/project/quagga tel: EMEA x19190 / +353 1 819 9190 From gsf@research.att.com Wed Mar 21 11:10:03 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LIA2Pf005417 for ; Wed, 21 Mar 2007 11:10:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LI9nS0014441; Wed, 21 Mar 2007 18:09:59 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900101MGLIU00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 11:09:57 -0700 (PDT) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF9000CSMGLL940@nwk-avmta-1.sfbay.Sun.COM>; Wed, 21 Mar 2007 11:09:57 -0700 (PDT) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l2LI9rS9026717; Wed, 21 Mar 2007 18:09:57 +0000 (GMT) Received: from mms23es.sun.com ([150.143.232.54] [150.143.232.54]) by relay24.sun.com with ESMTP; Wed, 21 Mar 2007 18:09:53 +0000 (Z) Received: from mms23bas.mms.us.syntegra.com (mms23bas.mms.us.syntegra.com [192.12.251.50]) by mms23es.sun.com with ESMTP id BT-MMP-109974; Wed, 21 Mar 2007 18:09:53 +0000 (Z) Received: from mail-red.research.att.com ([192.20.225.110] [192.20.225.110]) by relay23.sun.com with ESMTP; Wed, 21 Mar 2007 18:09:53 +0000 (Z) Received: from penguin.research.att.com (penguin.research.att.com [135.207.20.192]) by mail-blue.research.att.com (Postfix) with ESMTP id 23DB2147CB5; Wed, 21 Mar 2007 14:09:53 -0400 (EDT) Received: (from gsf@localhost) by penguin.research.att.com (8.13.1/8.12.10/Submit) id l2LI9rm5021823; Wed, 21 Mar 2007 14:09:53 -0400 Date: Wed, 21 Mar 2007 14:09:53 -0400 From: Glenn Fowler Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris To: bart.smaalders@sun.com, gsf@research.att.com Cc: don.cragun@sun.com, PSARC-EXT@sun.com Message-id: <200703211809.l2LI9rm5021823@penguin.research.att.com> Organization: AT&T Research MIME-version: 1.0 X-Mailer: mailx (AT&T/BSD) 9.9 2006-04-17 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> <200703202336.l2KNaNeP015134@penguin.research.att.com> <460071A7.6090103@Sun.COM> <200703211701.l2LH1ESv006521@penguin.research.att.com> <46016A68.2020106@Sun.COM> Status: RO Content-Length: 329 On Wed, 21 Mar 2007 10:24:56 -0700 Bart Smaalders wrote: > Glenn Fowler wrote: > Solaris already has better, simpler APIs; see > walkcontext(3) and printstack(). I am proposing to add these > (potential usage warts and all) to provide source compatibility > for more open source applications. thanks for the solaris pointers From jek3@sun.com Wed Mar 21 15:19:59 2007 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id l2LMJxof012442 for ; Wed, 21 Mar 2007 15:19:59 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id l2LMJmhu028415; Wed, 21 Mar 2007 22:19:55 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JF900F0LY145700@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 16:19:52 -0600 (MDT) Received: from jurassic-x4600.Eng.Sun.COM ([129.146.17.59]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JF900BYWY146GA0@brm-avmta-1.central.sun.com>; Wed, 21 Mar 2007 16:19:52 -0600 (MDT) Received: from [129.150.12.53] (vpn-129-150-12-53.SFBay.Sun.COM [129.150.12.53]) by jurassic-x4600.Eng.Sun.COM (8.14.0+Sun/8.14.0) with ESMTP id l2LMJjDZ423668; Wed, 21 Mar 2007 15:19:46 -0700 (PDT) Date: Wed, 21 Mar 2007 12:19:39 -1000 From: Joseph Kowalski Subject: Re: PSARC/2007/162 Backtrace() and friends for Solaris In-reply-to: <46016A68.2020106@Sun.COM> To: Bart Smaalders Cc: Glenn Fowler , don.cragun@sun.com, PSARC-EXT@sun.com Message-id: <4601AF7B.8080502@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200703202257.l2KMvWEq020809@spartan.SFBay.Sun.COM> <200703202336.l2KNaNeP015134@penguin.research.att.com> <460071A7.6090103@Sun.COM> <200703211701.l2LH1ESv006521@penguin.research.att.com> <46016A68.2020106@Sun.COM> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 465 Bart Smaalders wrote: > Solaris already has better, simpler APIs; see > walkcontext(3) and printstack(). I am proposing to add these > (potential usage warts and all) to provide source compatibility > for more open source applications. Ah! See the getopt_long man page for a routine with similar motivation. Perhaps similar disclaimers/structure are appropriate for this man page. (Yea, I know this isn't architecture. Consider it just a suggestion.) - jek3