Description of problem:
When include files are placed in subdirectories, and a binary is run
under gdb from a location other than the compilation directory, gdb
cannot find the source code corresponding to functions/symbols defined
in that header file
Version-Release number of selected component (if applicable):
all RHEL3 releases/updates
Steps to Reproduce:
1.untar the attached test case
2.type 'cd sandbox'
4.type 'cd ..'
5.type 'gdb sandbox/debug_test'
6.type list other
the symbol other is found, but the source file for it (other.h) is not
and is reported as 'No such file or directory'
the definition of the function other should be listed from the source
Created attachment 108041 [details]
testcase demonstrating bug
This is the testcase demonstrating the gdb bug
Created attachment 108043 [details]
patch to fix gdb file searching
This is a patch to fix the way gdb searches for files. I've tested it and it
seems to work well. I'm not sure its the best fix, as there are a few
alternatives. The problem stems from the fact that in open_source_file, as
part of the search algorithm, gdb attempts to open the needed source file in
$cdir/<symtab->dirname>/<symtab->filename>, but unfortunately:
1) nothing in gdb ever sets $cdir, and it should be set to the compilation
directory if one exists in the binary debug information
2) open_source_file is broken in the way it seems to parse the directory
information in this manner
I wasn't sure of the history behind cdir, and why nobody seems to use it, so I
opted instead in this patch to modify dwarf_decode_lines such that the
compilation directory was prepended to the symtab->dirname field. This allows
a different code path to be taken in open_source_file, and as a result the file
is properly found. I'm not 100% sure of all the repercussions of doing this,
but it seems to me to be reasonably safe since the C files seem to be handled
in this fashion.
A patch has been built into gdb version 6.1post-1.20040607.52.6 which fixes the
I just ran through a quick test w/ the customers reproducer and this does indeed
appear to be fixed in 6.1post-1.20040607.52.6. I'll provide this to the
customer for verification.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.