| Summary: | FAIL: gdb.base/fullname.exp: set breakpoint by full path before/after loading symbols - built relative | ||
|---|---|---|---|
| Product: | gdb | Reporter: | Tom de Vries <vries> |
| Component: | breakpoints | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jonah, tromey |
| Priority: | P2 | ||
| Version: | HEAD | ||
| Target Milestone: | 9.1 | ||
| Host: | Target: | ||
| Build: | Last reconfirmed: | ||
|
Description
Tom de Vries
2019-06-16 22:33:42 UTC
It works fine here. I wonder what the difference could be in our setups. (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. 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 Committed without test-case as mentioned in rationale, marking resolved-fixed. (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 (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. |