From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Mosberger Date: Fri, 11 Apr 2003 18:29:31 +0000 Subject: Re: [Linux-ia64] gdb problem unwinding abort in signal Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-ia64@vger.kernel.org >>>>> On Fri, 11 Apr 2003 13:17:38 -0500, Mario Smarduch said: Mario> When our application aborts in the signal handler (no Mario> altstack is setup) the stack backtrace discontinues at the Mario> signal handler. Mario> (gdb) where #0 0x20000000000a6342 in kill () at soinit.c:56 Mario> #1 0x20000000000a61f0 in raise (sig=6) at Mario> ../sysdeps/posix/raise.c:27 #2 0x20000000000a8a70 in abort () Mario> at ../sysdeps/generic/abort.c:88 #3 0x4000000000000910 in Mario> sig_report_and_die () Mario> Manually unwinding the stack shows the rp set to Mario> ia64_sigtramp(). The privilaged gate page simplifies allot of Mario> things, but it poses a problem to our software because we Mario> send events for all signals of importance, and count on the Mario> core dump to capture the full call trace prior to and Mario> including the signal - gdb displays this full backtrace on Mario> all other architectures we run on. Mario> If this is the problem how does one get around it besides Mario> manually unwinding the stack? There is a gdb patch in the works that will use libunwind for backtracing purposes. Unwinding across signal handlers will work just fine then (at least with reasonably recent kernels). An old (alpha-quality) snapshot of such a gdb is at: ftp://ftp.hpl.hp.com/pub/linux-ia64/ugdb-ia64-020531.tar.gz and someone from Red Hat is now working on updating the gdb patch for libunwind v0.9 (and hopefully on getting it into the official gdb tree). --david