From owner-freebsd-hackers Sun Jul 18 12: 3:10 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cygnus.rush.net (cygnus.rush.net [209.45.245.133]) by hub.freebsd.org (Postfix) with ESMTP id C87B914E27 for ; Sun, 18 Jul 1999 12:03:06 -0700 (PDT) (envelope-from bright@rush.net) Received: from localhost (bright@localhost) by cygnus.rush.net (8.9.3/8.9.3) with SMTP id PAA16627; Sun, 18 Jul 1999 15:13:04 -0400 (EDT) Date: Sun, 18 Jul 1999 14:13:02 -0500 (EST) From: Alfred Perlstein To: Dag-Erling Smorgrav Cc: hackers@FreeBSD.ORG Subject: Re: Determining the return address In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 18 Jul 1999, Dag-Erling Smorgrav wrote: > Alfred Perlstein writes: > > This looks like what you are doing is trying to grab the data on the > > stack before "log" which is the return address. > > Yes. It actually works :) > > > I doubt this is > > at all portable and may fail because of optimizations and ABI, such > > as archs that store the return address in a register... > > I know - I don't expect it to be portable. *slap* :) > > > gdb and glibc have some functions to assist in runtime backtraces, > > perhaps a look there may help? > > I found out about __builtin_return_address(0). what is that? a function? available on freebsd? > > > > BTW, is dladdr() signal-safe? > > not according to the sigaction man page. > > OK, is there any way I can find out that I am being called from a > signal handler, other than using a global variable? I want my logging > functions to be signal-safe - that's why I use writev(), and I've gone > to great lengths to ensure that log_makedate() (which uses > localtime_r() and strftime() to build a date string) and lvformat() (a > printf() clone with some additional goodies) are signal-safe. sigaltstack() ? If oss is non-zero, the current signal stack state is returned. The ss_flags field will contain the value SS_ONSTACK if the process is cur- rently on a signal stack and SS_DISABLE if the signal stack is currently disabled. by setting an alternate signal stack i think you can check if you are in a signal using this. this may not be the best way but it seems like a viable solution. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message