From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12241 invoked by alias); 10 Oct 2002 18:46:53 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12234 invoked from network); 10 Oct 2002 18:46:52 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 10 Oct 2002 18:46:52 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17zjGW-0006mN-00 for ; Thu, 10 Oct 2002 14:46:36 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17ziLT-0004Fc-00 for ; Thu, 10 Oct 2002 14:47:39 -0400 Date: Thu, 10 Oct 2002 11:46:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: i386-linux signal backtraces broken Message-ID: <20021010184739.GA15971@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i X-SW-Source: 2002-10/txt/msg00096.txt.bz2 Right now, we have this: static int i386_linux_pc_in_sigtramp (CORE_ADDR pc, char *name) { if (name) return STREQ ("__restore", name) || STREQ ("__restore_rt", name); return (i386_linux_sigtramp_start (pc) != 0 || i386_linux_rt_sigtramp_start (pc) != 0); } There's only one problem here. On my desktop (Debian GNU/Linux, glibc 2.2.5), there are two copies of sigaction in a dynamically linked executable. One of them's in libc.so.6 and the other is in ld-linux.so.2. The only __restore symbol we find is in ld-linux.so.2; this seems to be because we leave a symbol table in ld-linux.so.2 (probably for the debugger's benefit, so that it can find _dl_debug_state) - but we strip libc.so.6. Unfortunately, the application gets the copy of __restore that is in libc.so.6. Which is right after a function whose name appears in the dynamic symbol table (sigaction). So it's considered to be part of sigaction, and NAME is "sigaction". If you statically link the application, everything works fine. We have two choices, that I see: - Call the code inspection functions always - Call the code inspection functions if the name is sigaction, taking advantage of the glibc implementation detail that sigaction is the only exported name for this function that I can see, and they are implemented right after it in the same file. Option (A) is a performance hit. Option (B) is, well, a little fragile. Thoughts? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer