Bug 24687 - FAIL: gdb.base/fullname.exp: set breakpoint by full path before/after loading symbols - built relative
Summary: FAIL: gdb.base/fullname.exp: set breakpoint by full path before/after loading...
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: breakpoints (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: 9.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-16 22:33 UTC by Tom de Vries
Modified: 2019-11-02 06:16 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2019-06-16 22:33:42 UTC
This FAILs start at "Only compute realpath when basenames_may_differ is set":
...
FAIL: gdb.base/fullname.exp: set breakpoint by full path before loading symbols - built relative
FAIL: gdb.base/fullname.exp: set breakpoint by full path after loading symbols - built relative
...

First failure in more detail:
...
(gdb) file /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/fullname/fullname^M
Reading symbols from /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/fullname/fullname...^M
(gdb) break /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/fullname/tmp-fullname.c:21^M
No source file named /data/gdb_versions/devel/build/gdb/testsuite/outputs/gdb.base/fullname/tmp-fullname.c.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.base/fullname.exp: set breakpoint by full path before loading symbols - built relative
...
Comment 1 Tom Tromey 2019-06-17 16:18:28 UTC
It works fine here.
I wonder what the difference could be in our setups.
Comment 2 Tom de Vries 2019-06-17 20:46:51 UTC
(In reply to Tom Tromey from comment #1)
> It works fine here.
> I wonder what the difference could be in our setups.

I think I figured it out.

I've got this symlink:
...
$ ls -la /home/vries/gdb_versions
lrwxrwxrwx 1 vries users 18 26 jun  2018 /home/vries/gdb_versions -> /data/gdb_versions
...

When I run:
...
$ pwd
/home/vries/gdb_versions/devel
$ ( cd build/gdb/; make check RUNTESTFLAGS=gdb.base/fullname.exp )
...
I see the FAILs.

But when I do:
...
$ cd $(pwd -P)
$ pwd
/data/gdb_versions/devel
$ ( cd build/gdb/; make check RUNTESTFLAGS=gdb.base/fullname.exp )
...
the FAILs are gone.
Comment 4 Sourceware Commits 2019-10-23 07:34:26 UTC
The master branch has been updated by Tom de Vries <vries@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7e785608ce2afae4b3f611f0e4d46cb9633ef937

commit 7e785608ce2afae4b3f611f0e4d46cb9633ef937
Author: Tom de Vries <tdevries@suse.de>
Date:   Wed Oct 23 09:33:46 2019 +0200

    [gdb/breakpoints] Fix fullname.exp when run from symlink dir
    
    I run into this error with gdb.base/fullname.exp:
    ...
    (gdb) file /data/gdb_versions/devel/build/gdb/testsuite/outputs/\
      gdb.base/fullname/fullname
    Reading symbols from /data/gdb_versions/devel/build/gdb/testsuite/outputs/\
      gdb.base/fullname/fullname...
    (gdb) break /data/gdb_versions/devel/build/gdb/testsuite/\
      outputs/gdb.base/fullname/tmp-fullname.c:21
    No source file named /data/gdb_versions/devel/build/gdb/testsuite/outputs/\
      gdb.base/fullname/tmp-fullname.c.
    Make breakpoint pending on future shared library load? (y or [n]) n
    (gdb) FAIL: gdb.base/fullname.exp: set breakpoint by full path before loading symbols - built relative
    ...
    
    The FAIL is due to this comparison in iterate_over_some_symtabs failing:
    ...
    481                   if (FILENAME_CMP (real_path, fullname) == 0)
    (gdb) p real_path
    $2 = 0x1a201f0 "/data/gdb_versions/devel/build/gdb/testsuite/outputs/\
      gdb.base/fullname/tmp-fullname.c"
    (gdb) p fullname
    $3 = 0x1a1de80 "/home/vries/gdb_versions/devel/build/gdb/testsuite/outputs/\
      gdb.base/fullname/tmp-fullname.c"
    ...
    
    The difference in pathnames is due to having a symlink dir:
    ...
    $ ls -la /home/vries/gdb_versions
    lrwxrwxrwx 1 vries users 18 26 jun  2018 /home/vries/gdb_versions -> /data/gdb_versions
    ...
    and the test passses when eliminating it:
    ...
    $ ( cd $(pwd -P); make check RUNTESTFLAGS=gdb.base/fullname.exp )
    ...
    
    The FAIL is a regression from commit a0c1ffedcf1 "Only compute realpath when
    basenames_may_differ is set".  Before, find_and_open_source was returning a
    real-path, resulting in variable 'fullname' being the same as varible
    'real_path' in the comparison listed above.  But after, that's no longer the
    case.
    
    Fix the FAIL by applying gdb_realpath on the fullname variable before the
    comparison.
    
    Tested on x86_64-linux.
    
    I wasn't able to write a test-case.  The FAIL starts at:
    ...
    $ cd build/gdb
    $ mv testsuite testsuite.bla
    $ ln -s testsuite.bla testsuite
    ...
    but already this doesn't trigger it anymore:
    ...
    $ cd build/gdb/outputs
    $ mv outputs outputs.bla
    $ ln -s outputs.bla outputs
    ...
    
    gdb/ChangeLog:
    
    2019-10-23  Tom de Vries  <tdevries@suse.de>
    
    	PR breakpoints/24687
    	* symtab.c (iterate_over_some_symtabs): Apply gdb_realpath on fullname.
    
    Change-Id: I1ace62a234458781e958980f3b425edf1490df27
Comment 5 Tom de Vries 2019-10-23 07:36:18 UTC
Committed without test-case as mentioned in rationale, marking resolved-fixed.
Comment 6 Jonah Graham 2019-11-01 20:47:02 UTC
(In reply to Tom de Vries from comment #5)
> Committed without test-case as mentioned in rationale, marking
> resolved-fixed.

Thank you for this AFAICT this fully resolves Bug 24915 as well. I did create a testcase for that bug that would be great to add to the suite if possible?

The entry on gdb-patches: https://sourceware.org/ml/gdb-patches/2019-08/msg00421.html
Comment 7 Tom de Vries 2019-11-02 06:16:59 UTC
(In reply to Jonah Graham from comment #6)
> (In reply to Tom de Vries from comment #5)
> > Committed without test-case as mentioned in rationale, marking
> > resolved-fixed.
> 
> Thank you for this AFAICT this fully resolves Bug 24915 as well.

Hi,

That's great news, thanks.

> I did
> create a testcase for that bug that would be great to add to the suite if
> possible?
> 
> The entry on gdb-patches:
> https://sourceware.org/ml/gdb-patches/2019-08/msg00421.html

Unfortunately I cannot approve that, and this request may go lost due to lingering in a closed PR.

I propose you reply to your message on gdb-patches, explaining that you'd like the patch committed, and take it from there.