From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29348 invoked by alias); 1 Nov 2004 17:30:21 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 29331 invoked from network); 1 Nov 2004 17:30:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 1 Nov 2004 17:30:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1COg0V-0005Pl-Cb; Mon, 01 Nov 2004 12:30:15 -0500 Date: Mon, 01 Nov 2004 17:30:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Cc: Elena Zannoni Subject: [RFA/symtab] Handle weak functions as global Message-ID: <20041101173014.GA20449@nevyn.them.org> Mail-Followup-To: gdb-patches@sources.redhat.com, Elena Zannoni Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00018.txt.bz2 This patch is a one liner, but requires a bit of explanation. If you have a version of glibc available with debugging symbols (in both ld.so and libc.so), you can see the problem like this: - Compile a program which calls open (). - Run to main. - Set a breakpoint on open. - Continue - the breakpoint will not be hit. [Separate debug files will show the bug if you point GDB at the right directory; on Debian this is /usr/lib/debug, not sure where it is on RH systems.] What happens, in my setup at least, is that gdb searches first the executable, then libc.so.6, then ld.so for "open". It either finds a trampoline in the executable or nothing at all (depending on your version of binutils). Then, it finds open in libc.so.6, which has type mst_file_text. Then it finds open in ld.so, which also has a symbol named open, which also has type mst_file_text. We did not find any mst_text symbol, so we settle for returning the most recent mst_file_text symbol - which is the wrong one. There's two strange things here. The first is that we return the second file symbol instead of the first; it doesn't much matter, since we'll be wrong half the time anyway. The second is that the symbol in libc.so is marked as mst_file_text. This turned out to be because BSF_WEAK handling was added to elfread for non-code symbols, but not for code symbols; and open is a weak entry point to libc.so.6 for historical reasons. If we treat it as global, paralleling the non-code symbol handling, then GDB will resolve breakpoints on "open" reliably to libc.so.6 (assuming no other shared library defines it). This gives the debugger much better chances of finding the right symbol - any situation more complicated would require setting breakpoints at all functions named "open", which is a To-Do-Later issue. Is this patch OK? -- Daniel Jacobowitz 2004-11-01 Daniel Jacobowitz * elfread.c (elf_symtab_read): Treat weak functions as global. Index: elfread.c =================================================================== RCS file: /big/fsf/rsync/src-cvs/src/gdb/elfread.c,v retrieving revision 1.47 diff -u -p -r1.47 elfread.c --- elfread.c 23 Oct 2004 16:18:08 -0000 1.47 +++ elfread.c 1 Nov 2004 17:00:39 -0000 @@ -305,7 +305,7 @@ elf_symtab_read (struct objfile *objfile } else if (sym->section->flags & SEC_CODE) { - if (sym->flags & BSF_GLOBAL) + if (sym->flags & (BSF_GLOBAL | BSF_WEAK)) { ms_type = mst_text; }