From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4789 invoked by alias); 22 Dec 2006 04:21:29 -0000 Received: (qmail 4774 invoked by uid 22791); 22 Dec 2006 04:21:27 -0000 X-Spam-Check-By: sourceware.org Received: from ug-out-1314.google.com (HELO ug-out-1314.google.com) (66.249.92.169) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Dec 2006 04:21:23 +0000 Received: by ug-out-1314.google.com with SMTP id 75so2703498ugb for ; Thu, 21 Dec 2006 20:21:20 -0800 (PST) Received: by 10.78.136.9 with SMTP id j9mr76107hud.1166761280719; Thu, 21 Dec 2006 20:21:20 -0800 (PST) Received: by 10.78.122.9 with HTTP; Thu, 21 Dec 2006 20:21:20 -0800 (PST) Message-ID: Date: Fri, 22 Dec 2006 04:21:00 -0000 From: "Sandeep Joshi" To: gdb@sourceware.org Subject: GDB not able to debug files(dwarf2.0) loaded using add-symbol-file MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-12/txt/msg00185.txt.bz2 PROBLEM : ---------------- When we use add-symbol-file option to debug more than one executables, the sources are not shown correctly. This happens if we build with dwarf2.0 debug format. Although GDB is able the debug correctly, it doesn't show correct sources. HOW : ------- I have tried to remotely debug an application running on arm board using the add-symbol-file command. We have a gdb stub on the target which gets control on bootup. We have changed the trap handler and using a specific undefined instruction(Hard Breakpoint) to pass control to stub on target. After trap initialization, we have put Hard Breakpoint in the kernel code. Below are the steps : 1) reboot the board. GDB specific undefined instruction is hit and the stub waits for GDB to connect. 2) start gdb on the host and connect to target. 3) load vmlinux for kernel debugging 4) give 'continue' command so that the kernel is loaded and we get the prompt. 5) put a Hard Breakpoint in the executable and run it. The hard breakpoint is hit and gdb on the host has control. 6) use add-symbol-file command to load the application symbol table. WHY : ------- The problem is in the way GDB performs symbol lookup using PC. In function 'find_pc_sect_psymtab' gdb is not performing symbol lookup in all the objfiles. If it finds the PC in the range of any partial symtab, it tries to find the partial symtab that contains a symbol whose address is closest to the PC address in that object file only and returns that partial symbol table. Now if the user puts a breakpoint in the file loaded using add-symbol-file, then in function 'find_pc_sect_psymtab' the PC Address might in the range of some psymtab in the first objfile (vmlinux) and the best match in that file is returned. This is happening because the code range of partial symtabs often overlap, mostly if the functions are reordered. SOLUTION : ---------------- Function 'find_pc_sect_psymtab' has to be modified to traverse all objfiles before returning the best match. Below is the patch for the same. This patch was made with insight-weekly-6.30.50.20051128.tar.bz2. Kindly review the patch and let me know if it can be added to gdb distribution. diff -ru -P src_original/gdb/symtab.c src/gdb/symtab.c --- src_original/gdb/symtab.c 2006-12-21 17:51:24.000000000 +0530 +++ src/gdb/symtab.c 2006-12-21 17:32:48.000000000 +0530 @@ -717,6 +717,11 @@ struct partial_symtab *pst; struct objfile *objfile; struct minimal_symbol *msymbol; + struct partial_symtab *tpst; + struct partial_symtab *best_pst = NULL; + struct partial_symbol *best_psym = NULL; + int match_found_in_prev_objfile = 0; + /* If we know that this is not a text address, return failure. This is necessary because we loop based on texthigh and textlow, which do @@ -730,13 +735,18 @@ || msymbol->type == mst_file_bss)) return NULL; - ALL_PSYMTABS (objfile, pst) + ALL_OBJFILES (objfile) { + ALL_OBJFILE_PSYMTABS (objfile, pst) + { if (pc >= pst->textlow && pc < pst->texthigh) { - struct partial_symtab *tpst; - struct partial_symtab *best_pst = pst; - struct partial_symbol *best_psym = NULL; + if(!match_found_in_prev_objfile) + { + best_pst = pst; + best_psym = NULL; + match_found_in_prev_objfile = 1; + } /* An objfile that has its functions reordered might have many partial symbol tables containing the PC, but @@ -793,10 +803,17 @@ } } - return (best_pst); - } + /* all partial symtabs in the current objfile traversed, + look for psymtabs of next objfile, if any. */ + break; + } + } } - return (NULL); + + if(best_pst) + return (best_pst); + else + return (NULL); } /* Find which partial symtab contains PC. Return 0 if none. REFERENCES ---------------------- Below are some references which were of great help while investigating this problem. Thanks to all. http://www.cygwin.com/ml/gdb-patches/2001-10/msg00304.html http://sourceware.org/ml/gdb-patches/2006-12/msg00005.html http://www.informatik.uni-frankfurt.de/doc/texi/gdbint_11.html Thanks and Regards Sandeep Joshi