Hi, I've looked at the proposed manual page and I have a few comments (note that I haven't managed to use the backtrace() functions correctly yet, so I'm not a specialist):
- the description for backtrace() sounds a bit off; I'm not a native speaker of English, but "stores to buffer" should probably be "stores ... in buffer". Also, I don't think "most recently called functions" is accurate - you could use "the list of active function calls in the current thread", or "the function call backtrace". - there is a typo in the first paragraph of "RETURN VALUE" - s/greater greater/greater. - the glibc manual states a few more situations where the stack trace will not be valid besides frame pointer omission - function inlining can also make for non exact stack traces. - the last paragraph in the NOTES section should probably be "The names of the functions are not actually available unless you pass '-rdynamic' as an option to gcc/g++ when compiling". You might be right about -rdynamic, here's what the gcc manual has to say about this option: "Pass the flag -export-dynamic to the ELF linker, on targets that support it. This instructs the linker to add all symbols, not only used ones, to the dynamic symbol table. This option is needed for some uses of dlopen or to allow obtaining backtraces from within a program. " I will try to play with the functions myself, just to see if -rdynamic yields the expected results. Stefan. --- Justin Pryzby <[EMAIL PROTECTED]> wrote: > Package: manpages-dev > Version: 2.28-1 > Severity: wishlist > X-Reference: > file:///usr/share/doc/glibc-doc/html/libc_33.html#SEC669 > Y-Reference: > http://people.redhat.com/~drepper/tut1.ps > > Included is a manpage documenting backtrace(); it is > not presently > ready for inclusion; some issues remain. I'm > sending it for review > and for help.. > > You can view it with something like "nroff -man > backtrace.3 |less". > > The most important thing that needs fixing is > figuring out why the > backtrace doesn't work :) I don't know how to get > the function names > to resolve from their addresses. Apparently > -rdynamic does this, but > it doesn't work for me... > > Also needed: see also suggestions. > > .\" Copyright (C) 2006 Justin Pryzby > <[EMAIL PROTECTED]> > .\" > .\" Permission is hereby granted, free of charge, to > any person obtaining > .\" a copy of this software and associated > documentation files (the > .\" "Software"), to deal in the Software without > restriction, including > .\" without limitation the rights to use, copy, > modify, merge, publish, > .\" distribute, sublicense, and/or sell copies of > the Software, and to > .\" permit persons to whom the Software is furnished > to do so, subject to > .\" the following conditions: > .\" > .\" The above copyright notice and this permission > notice shall be > .\" included in all copies or substantial portions > of the Software. > .\" > .\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT > WARRANTY OF ANY KIND, > .\" EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO > THE WARRANTIES OF > .\" MERCHANTABILITY, FITNESS FOR A PARTICULAR > PURPOSE AND NONINFRINGEMENT. > .\" IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT > HOLDERS BE LIABLE FOR ANY > .\" CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN > ACTION OF CONTRACT, > .\" TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN > CONNECTION WITH THE > .\" SOFTWARE OR THE USE OR OTHER DEALINGS IN THE > SOFTWARE. > .\" > .\" References: > .\" glibc manual and source > .TH BACKTRACE 3 "2006-05-22" GNU > .SH NAME > backtrace, backtrace_symbols, backtrace_symbols_fd > \- support for application self-debugging > .SH SYNOPSIS > \fB#include <execinfo.h> > > \fBint backtrace (void **\fIbuffer\fP, int > \fPsize\fP); > .br > \fBchar **backtrace_symbols (void *const > *\fIbuffer\fP, int \fPsize\fP); > .br > \fBvoid backtrace_symbols_fd (void *const > *\fIbuffer\fP, int \fPsize\fP, int \fPfd\fP); > .SH DESCRIPTION > \fBbacktrace\fP() stores to \fI*buffer\fP the return > addresses of the > most-recently called functions. Up to \fIsize\fP > addresses are > stored. > > \fBbacktrace_symbols\fP() accepts in \fIbuffer\fP an > array of > \fIsize\fP return addresses, as generated by > \fBbacktrace\fP(), and > returns an array of strings describing the functions > containing those > addresses. > > \fBbacktrace_symbols_fd\fP() accepts the same > \fIbuffer\fP and > \fPsize\fP parameters as \fBbacktrace_symbols\fP(), > and writes to the > file descriptor \fIfd\fP the same descriptive > strings, separated by > newlines. > .SH "RETURN VALUE" > \fBbacktrace\fP() returns the number of addresses > stored, which is not > greater greater than \fIsize\fP. If it is less than > \fIsize\fP, then > the full stacktrace was stored; if it is equal to > \fIsize\fP, then the > stacktrace may have been truncated, in which case, > the addresses of > the least-recently called functions are not stored. > > \fBbacktrace_symbols\fP() returns an array of > \fIsize\fP strings, each > of which contains the function name and return > address. The array > (but not the string elements) is allocated with > \fBmalloc\fP(), and > should be freed when it is unused. \fBNULL\fP is > returned on error. > .\" TODO: offset?? > .SH NOTES > These functions make some assumptions about how a > function's return > address is stored on the stack. Omission of the > frame pointers (as > implied by any of \fBgcc\fP's non-zero optimization > levels) may > violate those assumptions. > > .\" FIXME > The names of the functions are not actually > available > unless you -rdynamic > .SH "CONFORMING TO" > These functions are GNU extensions, and should not > be used in programs > intended to be portable. > .SH SEE ALSO > .\" FIXME > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
