gdb/1727: gdb fails to find sources compiled with relative paths when symbols are loaded on demand (psymtab bug)

[set at users dot sf dot net]

>Number:         1727
>Category:       gdb
>Synopsis:       gdb fails to find sources compiled with relative paths when symbols are loaded on demand (psymtab bug)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 30 16:58:00 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator:     set@users.sf.net
>Release:        6.1.1
>Organization:
>Environment:
Debian GNU/Linux Woody
>Description:
That´s hard to explain. The problem is in the mechanism used to search for a source file.
The code searches in the current symtabs, if the file can´t be found there the code searces in the psymtabs table.
But the way used to search in the psymtabs is wrong.
The bug is in the use of source_full_path_of (source.c).
This function calls openp indicating try_cwd_first. It makes the search file if the psymtab file name have at least one dirseparator. It means that psymtabs for files compiled with relative paths will fail. The search for symtabs uses symtab_to_filename, it calls open_source_file which finally
calls openp without try_cwd_first (it works).
To workaround it I tried using "file xxxx -readnow", it doesn´t work (I filled a bug report for it), so then I tried with --readnow command line option it works, but if I recompile while inside gdb and symbols must be reloaded gdb does it ignoring the --readnow option (I also filled a bug report for it).
The result is that is quite hard for me to use gdb from a frontend I´m creating because gdb fails to find the sources for breakpoints.
>How-To-Repeat:

>Fix:
Modify source_full_path_of (source.c) to call openp without indicating try_cwd_first. But I don´t know which side effects could have this.
>Release-Note:
>Audit-Trail:
>Unformatted: