This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

GDB not able to debug files(dwarf2.0) loaded using add-symbol-file


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]