From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8225 invoked by alias); 17 Nov 2003 22:39:28 -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 8208 invoked from network); 17 Nov 2003 22:39:27 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 17 Nov 2003 22:39:27 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 3C223481D5; Mon, 17 Nov 2003 14:39:26 -0800 (PST) Date: Mon, 17 Nov 2003 22:39:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFC] minimal symbols on mips-irix and overlapping CUs... Message-ID: <20031117223925.GA8608@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2003-11/txt/msg00368.txt.bz2 Hello, we have discovered a problem on mips-irix that had me wondering about GDB's assumptions regarding the symbol table. First, the symptoms: We have a small Ada program that uses nested procedures. The same can be reproduced with a C program if GCC is used (GCC provides nested procedures as an extension). Trying to get a backtrace off the nested procedure does not work. With our example, we get something like this: #0 main () #1 0x10013858 in main () #2 0x100139d0 in gdb_no_local_symbols () at gdb_no_local_symbols.adb:37 #3 0x10013574 in main (argc=1, argv=2147430180, envp=2147430188) at b~gdb_no_local_symbols.adb:204 While the expected backtrace was: #0 gdb_no_local_symbols.proch () at gdb_no_local_symbols.adb:28 #1 0x10013858 in gdb_no_local_symbols.procc () at gdb_no_local_symbols.adb:32 #2 0x100139d0 in gdb_no_local_symbols () at gdb_no_local_symbols.adb:37 #3 0x10013574 in main (argc=1, argv=2147430180, envp=2147430188) at b~gdb_no_local_symbols.adb:204 The problem, in my opinion, is two-fold: a. The IRIX linker does not include the LOCAL symbols into the symbol table. They are present in the object files, but are stripped from the executable symbol table. This concerns at least nested functions, and static functions as well. b. A recent version of the IRIX linker has introduced an extra asm CU (Compilation Unit) named "__sgi_ld_generated_code" which contains one function before CU gdb_local_symbol.adb, and 2 after. So the code range of gdb_local_symbol.adb is included in the code range of the linker CU. What happens after GDB stops on the breakpoint and tries to find the associated function name is the following: 1. In find_pc_sect_symtab(), we search all symtabs for one which code range includes the PC. We find the linker CU, which is the wrong one. But we acknowledge the fact that CUs can overlap, and therefore resort to find_pc_sect_psymtab() to find the correct CU. 2. In find_pc_sect_psymtab(): a. We first scan the minimal symbols, find "main". We did not find the right function because the linker did not include it into the symbol table. b. Then, we scan all the partial symtabs for the ones which code range include the given address. For all the qualifying ones, we check whether it contains a function which start address matches the minimal symbol address. If yes, then we have found the right symtab. Otherwise, we just return the first partial symtab we found. So in our case, we simply end up selecting the linker CU. The GDB later realizes that there is no function matching the given PC in the CU we selected, it falls back to using the minimal symbol table, and therefore ends up declaring that GDB stopped in function main(). In my opinion, (b) is not a problem, and GDB should be able to handle it as long as the symbol table is "complete" (ie as long as (a) does not apply). I am inclined to declare this a linker problem, but can this really be categorized as a linker problem? My general question is the following: Has GDB been designed to assume that the symbol table will always be complete? This has always been my feeling, but I'm wondering if it wasn't an unwarranted assumption. Maybe it's just a hole in find_pc_sect_psymtab() that needs correcting. For instance, I am contemplating the idea of tweaking GDB to automatically add new "virtual" minimal symbols after having built the psymbols using the following approach: Foreach non-type psymbol we found, check whether we have a minimal symbol at the same address. If not, then we have a missing msymbol, and I therefore add it. Opinions? Thanks, -- Joel