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 How reproducible: always Steps to Reproduce: 1.untar the attached test case 2.type 'cd sandbox' 3.type 'make' 4.type 'cd ..' 5.type 'gdb sandbox/debug_test' 6.type list other Actual results: the symbol other is found, but the source file for it (other.h) is not and is reported as 'No such file or directory' Expected results: the definition of the function other should be listed from the source in other.h Additional info:
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 problem.
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. http://rhn.redhat.com/errata/RHBA-2005-187.html