Re: [PATCH] Fix symtab/23853: symlinked default symtab

[Pedro Alves <palves at redhat dot com>]

On 11/05/2018 09:19 PM, Keith Seitz wrote:
> This patch attempts to fix a bug dealing with setting breakpoints
> in default symtabs that are symlinks.  For example:
> 
> (gdb) list
> 11	   GNU General Public License for more details.
> 12
> 13	   You should have received a copy of the GNU General Public License
> 14	   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
> 15
> 16	static int
> 17	foo (void)
> 18	{
> 19	  return 0; /* break here  */
> 20	}
> (gdb)
> 21
> 22	int
> 23	main (void)
> 24	{
> 25	  return foo ();
> 26	}
> (gdb) b 19
> No line 19 in the current file.
> Make breakpoint pending on future shared library load? (y or [n])
> 
> The problem here is that when convert_sals_line_offset sets the default

s/convert_sals_line_offset/create_sals_line_offset/

> symtab, it immediately calls symtab_to_fullname, passing that fullname
> to collect_symtabs_from_filename.
> 
> When we iterate over the compunit_symtabs in iterate_over_some_symtabs,
> NAME is this the fullname from symtab_to_fullname while the symtab
> filename is the symlink name (gotten from debuginfo).
> compare_filenames_for_search is then called to ascertain a match between,
> e.g., "symlink.c" and "/path/to/realsource.c".
> The first comparison fails (compare_filenames_for_search returns early
> with a simple strlen comparison).
> 
> Later in iterate_over_some_symtabs, symtab_to_fullname would be called
> with the result of symtab_to_fullname, but only if the user has set

This sentence doesn't seem to make sense (symtab_to_fullname twice)?

I think you meant something like this:

  Later in iterate_over_some_symtabs, the passed-in fullname would be compared
  with the symtab's fullname but only if the user has set

> "basenames-may-differ."  This flag defaults to "off" because, as
> iterate_over_some_symtabs says, realpath is very expensive to use.
> 
> However, there seems little reason not to check the fullname if it is
> already known (non-NULL).  That's what this patch does.
> 

My first reaction was, why are we doing that, passing down the
fullname instead of the symtab's filename, especially considering
basenames_may_differ.  Pedantically looks odd at first sight.

I suppose I don't see a great reason to not chech fullname either,
so I guess that's fine.

Actually, if create_sals_line_offset has a default symtab handy, why
does it need to iterate over symtabs?  Couldn't it just use the
default directly?

> gdb/ChangeLog
> 
> 	PR symtab/23853
> 	* symtab.c (iterate_over_some_symtabs): If the symtab has a
> 	fullname, check whether it is a filename match, too.
> 
> gdb/testsuite/ChangeLog
> 
> 	PR symtab/23853
> 	* gdb.base/symlink-sourcefile.c: New file.
> 	* gdb.base/symlink-sourcefile.exp: New file.
> ---
>  gdb/ChangeLog                                 |  6 +++
>  gdb/symtab.c                                  |  4 +-
>  gdb/testsuite/ChangeLog                       |  6 +++
>  gdb/testsuite/gdb.base/symlink-sourcefile.c   | 26 +++++++++++
>  gdb/testsuite/gdb.base/symlink-sourcefile.exp | 44 +++++++++++++++++++
>  5 files changed, 85 insertions(+), 1 deletion(-)
>  create mode 100644 gdb/testsuite/gdb.base/symlink-sourcefile.c
>  create mode 100644 gdb/testsuite/gdb.base/symlink-sourcefile.exp
> 
> diff --git a/gdb/ChangeLog b/gdb/ChangeLog
> index bc77fe85c7..557c72b203 100644
> --- a/gdb/ChangeLog
> +++ b/gdb/ChangeLog
> @@ -1,3 +1,9 @@
> +YYYY-MM-DD  Keith Seitz  <keiths@redhat.com>
> +
> +	PR symtab/23853
> +	* symtab.c (iterate_over_some_symtabs): If the symtab has a
> +	fullname, check whether it is a filename match, too.
> +
>  2018-11-04  Tom Tromey  <tom@tromey.com>
>  
>  	* varobj.c (install_default_visualizer): Update.
> diff --git a/gdb/symtab.c b/gdb/symtab.c
> index 7649908d9c..5b39db6d33 100644
> --- a/gdb/symtab.c
> +++ b/gdb/symtab.c
> @@ -412,7 +412,9 @@ iterate_over_some_symtabs (const char *name,
>      {
>        ALL_COMPUNIT_FILETABS (cust, s)
>  	{
> -	  if (compare_filenames_for_search (s->filename, name))
> +	  if (compare_filenames_for_search (s->filename, name)
> +	      || (s->fullname != nullptr
> +		  && compare_filenames_for_search (s->fullname, name)))

This may use a comment.  Otherwise a reader is wondering why we're comparing
the fullname, when basenames_may_differ is false, which pedantically looks
odd at first sight.

Also, I'm looking at this wondering about redundant checks and
efficiency.

I.e., if s->fullname is not NULL and the new check fails above, then
this one below:

	  if (compare_filenames_for_search (symtab_to_fullname (s), name))
	    {

... is guaranteed to fail too, AFAICS.  That would suggest tweaking
that one to:

	  if (s->fullname == nullptr 
              || compare_filenames_for_search (symtab_to_fullname (s), name))
	    {

then.  Right?

I noticed that psym_map_symtabs_matching_filename uses the same
search algorithm, which looks like should be changed to match.
Maybe dw2_map_symtabs_matching_filename and 
skiplist_entry::do_skip_file_p too.  And others.  Not sure.
I just grepped for basenames_may_differ and found these.

> +
> +# Test GDB when source files are symlinks.

Please mention the specific case of the default symtab somewhere.
Either here, or at the gdb_breakpoint line below.  That's important
for the test, right?

> +standard_testfile
> +
> +set test "file symbolic link name"
> +set linksrc "link-${srcfile}"
> +set srcfilelink [standard_output_file $linksrc]
> +
> +
> +# Remove any existing symlink and build executable using the
> +# symlink.
> +remote_file host delete $srcfilelink
> +set status [remote_exec host \
> +		"ln -sf $srcdir/$subdir/$srcfile $srcfilelink"]
> +if {[lindex $status 0] != 0} {
> +    unsupported "$test (host does not support symbolic links)"
> +    return 0
> +}
> +
> +if {[prepare_for_testing $testfile $testfile $srcfilelink]} {
> +    return -1
> +}
> +
> +if {![runto_main]} {
> +    untested "could not run to main"
> +    return -1
> +}
> +
> +gdb_breakpoint [gdb_get_line_number "break here" $srcfile] message
> +gdb_continue_to_breakpoint "run to breakpoint marker"
>  
Thanks,
Pedro Alves