Created attachment 11952 [details] small testcase for reproducing the issue Hello, there seems to be an regression when it comes to resolving paths for setting breakpoints. I can reproduce the issue on 8.3.50.20190629-git and 8.3.50.20190813-git, while 8.2.1 and 8.3 are not affected. I set this to critical as this makes gdb practically unusable with IDEs. Unpack to /tmp/testcase Build and start gdb cd /tmp/testcase/build make gdb testcase try setting an absolute breakpoint (gdb) b /tmp/testcase/libUniverse.c:5 No source file named /tmp/testcase/libUniverse.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) b /tmp/testcase/testcase.c:5 No source file named /tmp/testcase/testcase.c. Make breakpoint pending on future shared library load? (y or [n]) n What does work: (gdb) b /tmp/testcase/build/../libUniverse.c:5 Breakpoint 1 at 0x117b: file ../libUniverse.c, line 5.
I wrote a new test that passes in older GDBs and fails in current master at: https://sourceware.org/ml/gdb-patches/2019-08/msg00421.html
AFAICT this has been fixed by the change in Bug 24687
I'm still having an issue. Using gdb with Eclipse CDT, the breakpoint is set (by the Eclipse GUI) properly only if it is in the initial file (containing main). If it is in another source file I get a'<PENDING> address. e.g. I have a source file (test.c) containing the main entry point and another (test2.c). I set a break point in both files... (and looking with the 'Debugger Console' (gdb) info break Num Type Disp Enb Address What 2 breakpoint keep y 0x0000000000401134 in main at ../src/test.c:18 3 breakpoint keep y <PENDING> /home/michael/eclipse-workspace/test/src/test2.c:9 (gdb) GNU gdb (GDB) Fedora 8.3.50.20190824-27.fc31 (also tried with ... GNU gdb (GDB) Fedora 9.0.50.20191119-2.fc31 with similar results) The Eclipse folks say that this is a gdb issue.... I can set the breakpoint with the command line (although it curiously sets 2 additional breakpoints)... (gdb) break test2.c:8 Breakpoint 4 at 0x401150: file ../src/test2.c, line 8. (gdb) info break Num Type Disp Enb Address What 2 breakpoint keep y 0x0000000000401134 in main at ../src/test.c:18 3 breakpoint keep y <PENDING> /home/michael/eclipse-workspace/test/src/test2.c:9 4 breakpoint keep y 0x0000000000401150 in externalProc at ../src/test2.c:8 5 breakpoint keep y 0x0000000000401150 in externalProc at ../src/test2.c:8 (gdb)
> I'm still having an issue. Hi Michael, this is because the GDB in Fedora 31 is not a released GDB, but rather one from GDB sources that didn't include the now fixed regression. Therefore this bug report belongs with Fedora I believe. I reached out to the GDB maintainer, sergiodj, and he was looking for someone to test. Can you do that on Fedora? I'll email you the conversation and you can pick it up from there. Also, if you can confirm that the fix [1] is in fc31's gdb then you may be running into a different problem and I would like to work with you to resolve it. The alternative in the meantime is to do what was done in [2] and compile your own gdb. BTW Matthew, are you related to Michael Katzmann, the submitter of the bug in CDT[2]? If not that is a random coincidence. [1] https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/82 [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=558519#c2
Hi Johnah, Ha - this is what Sergio said ... Thanks for the heads up, Michael. I can't look at this right now; can you comment on the upstream bug, please? It would be good to know if Jonah can confirm this issue, since he works with CDT. AFAIK Sergio did fix the initial issue (I'm using the 'testing' RPM version). On Fri, Jan 31, 2020 at 3:37 PM jonah at kichwacoders dot com < sourceware-bugzilla@sourceware.org> wrote: > https://sourceware.org/bugzilla/show_bug.cgi?id=24915 > > --- Comment #4 from Jonah Graham <jonah at kichwacoders dot com> --- > > I'm still having an issue. > > Hi Michael, this is because the GDB in Fedora 31 is not a released GDB, but > rather one from GDB sources that didn't include the now fixed regression. > Therefore this bug report belongs with Fedora I believe. > > I reached out to the GDB maintainer, sergiodj, and he was looking for > someone > to test. Can you do that on Fedora? I'll email you the conversation and > you can > pick it up from there. > > Also, if you can confirm that the fix [1] is in fc31's gdb then you may be > running into a different problem and I would like to work with you to > resolve > it. > > The alternative in the meantime is to do what was done in [2] and compile > your > own gdb. > > BTW Matthew, are you related to Michael Katzmann, the submitter of the bug > in > CDT[2]? If not that is a random coincidence. > > [1] https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/82 > [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=558519#c2 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
Created attachment 12243 [details] attachment-100819-0.html This was the bugzilla from Fedora .. https://bugzilla.redhat.com/show_bug.cgi?id=1785768 On Fri, Jan 31, 2020 at 3:43 PM Michael Katzmann <vk2bea@gmail.com> wrote: > Hi Johnah, > Ha - this is what Sergio said ... Thanks for the heads up, Michael. I > can't look at this right now; can you comment on the upstream bug, please? > It would be good to know if Jonah can confirm this issue, since he works > with CDT. > > AFAIK Sergio did fix the initial issue (I'm using the 'testing' RPM > version). > > On Fri, Jan 31, 2020 at 3:37 PM jonah at kichwacoders dot com < > sourceware-bugzilla@sourceware.org> wrote: > >> https://sourceware.org/bugzilla/show_bug.cgi?id=24915 >> >> --- Comment #4 from Jonah Graham <jonah at kichwacoders dot com> --- >> > I'm still having an issue. >> >> Hi Michael, this is because the GDB in Fedora 31 is not a released GDB, >> but >> rather one from GDB sources that didn't include the now fixed regression. >> Therefore this bug report belongs with Fedora I believe. >> >> I reached out to the GDB maintainer, sergiodj, and he was looking for >> someone >> to test. Can you do that on Fedora? I'll email you the conversation and >> you can >> pick it up from there. >> >> Also, if you can confirm that the fix [1] is in fc31's gdb then you may be >> running into a different problem and I would like to work with you to >> resolve >> it. >> >> The alternative in the meantime is to do what was done in [2] and compile >> your >> own gdb. >> >> BTW Matthew, are you related to Michael Katzmann, the submitter of the >> bug in >> CDT[2]? If not that is a random coincidence. >> >> [1] https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/82 >> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=558519#c2 >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > > > > -- > |\ _,,,---,,_ Michael Katzmann > /,`.-'`' -. ;-;;,_ NV3Z / VK2BEA / G4NYV > |,4- ) )-,_. ,\ ( `'-' > '---''(_/--' `-'\_) vk2bea@gmail.com > >
OK I just compiled and tried ... GNU gdb (GDB) 10.0.50.20200131-git and also see this issue. So no, the problem is not resolved.
(In reply to Michael Katzmann from comment #7) > OK I just compiled and tried ... > > GNU gdb (GDB) 10.0.50.20200131-git > > and also see this issue. So no, the problem is not resolved. I will try to reproduce using GDB from source and CDT. Once I have reproduced (or not) then we'll have a better idea of where to go next. Thanks Michael for your effort so far on this!
Michael, Can you please provide the MI traces of the failure? See https://wiki.eclipse.org/CDT/User/NewIn92#Hide_gdb_traces_by_default for how to turn on MI traces if not on already. Thanks!
427,171 3-environment-cd /home/michael/eclipse-workspace/test 427,172 3^done 427,172 (gdb) 427,172 4-gdb-set breakpoint pending on 427,172 4^done 427,172 (gdb) 427,173 5-gdb-set detach-on-fork on 427,173 5^done 427,173 (gdb) 427,173 6-enable-pretty-printing 427,173 6^done 427,173 (gdb) 427,173 7-gdb-set python print-stack none 427,173 7^done 427,173 (gdb) 427,174 8-gdb-set print object on 427,174 8^done 427,174 (gdb) 427,178 9-gdb-set print sevenbit-strings on 427,178 9^done 427,178 (gdb) 427,179 10-gdb-set host-charset UTF-8 427,179 10^done 427,179 (gdb) 427,179 11-gdb-set target-charset UTF-8 427,179 11^done 427,179 (gdb) 427,179 12-gdb-set target-wide-charset UTF-32 427,180 12^done 427,180 (gdb) 427,180 13-gdb-set dprintf-style call 427,180 13^done 427,180 (gdb) 427,180 14source .gdbinit 427,180 &"source .gdbinit\n" 427,180 &".gdbinit: No such file or directory.\n" 427,181 14^error,msg=".gdbinit: No such file or directory." 427,181 (gdb) 427,181 15-gdb-set target-async on 427,181 15^done 427,181 (gdb) 427,181 16-gdb-set record full stop-at-limit off 427,182 16^done 427,182 (gdb) 427,182 17-list-thread-groups 427,182 17^done,groups=[{id="i1",type="process"}] 427,182 (gdb) 427,183 18-gdb-set auto-solib-add on 427,183 18^done 427,183 (gdb) 427,184 19-file-exec-and-symbols --thread-group i1 /home/michael/eclipse-workspace/test/Debug/test 427,186 19^done 427,186 (gdb) 427,186 20-gdb-show --thread-group i1 language 427,186 20^done,value="auto" 427,186 (gdb) 427,187 21-gdb-set --thread-group i1 language c 427,187 21^done 427,187 (gdb) 427,187 22-interpreter-exec --thread-group i1 console "p/x (char)-1" 427,187 ~"$1 = 0xff\n" 427,187 22^done 427,187 (gdb) 427,188 23-data-evaluate-expression --thread-group i1 "sizeof (void*)" 427,188 23^done,value="8" 427,188 (gdb) 427,188 24-gdb-set --thread-group i1 language auto 427,188 24^done 427,188 (gdb) 427,188 25-interpreter-exec --thread-group i1 console "show endian" 427,188 ~"The target endianness is set automatically (currently little endian)\n" 427,188 25^done 427,189 (gdb) 427,190 26-break-insert -f /home/michael/eclipse-workspace/test/src/test.c:18 427,190 27-break-insert -f /home/michael/eclipse-workspace/test/src/test2.c:9 427,190 26^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401134"\ ,func="main",file="../src/test.c",fullname="/home/michael/eclipse-workspace/test/Debug/../src/test.c\ ",line="18",thread-groups=["i1"],times="0",original-location="/home/michael/eclipse-workspace/test/s\ rc/test.c:18"} 427,190 (gdb) 427,190 &"No source file named /home/michael/eclipse-workspace/test/src/test2.c.\n" 427,190 27^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending=\ "/home/michael/eclipse-workspace/test/src/test2.c:9",times="0",original-location="/home/michael/ecli\ pse-workspace/test/src/test2.c:9"} 427,190 (gdb) 427,194 28-break-insert -t -f main 427,194 28^done,bkpt={number="3",type="breakpoint",disp="del",enabled="y",addr="0x000000000040112a",\ func="main",file="../src/test.c",fullname="/home/michael/eclipse-workspace/test/Debug/../src/test.c"\ ,line="17",thread-groups=["i1"],times="0",original-location="main"} 427,195 (gdb) 427,195 29-inferior-tty-set --thread-group i1 /dev/pts/2 427,195 29^done 427,195 (gdb) 427,204 30-exec-run --thread-group i1 427,205 =thread-group-started,id="i1",pid="421842" 427,205 =thread-created,id="1",group-id="i1" 427,211 =library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",h\ ost-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ff\ ff7fd3110",to="0x00007ffff7ff2bb4"}] 427,212 31-list-thread-groups 427,220 &"warning: the debug information found in \"/usr/lib/debug//lib64/ld-2.30.so.debug\" does no\ t match \"/lib64/ld-linux-x86-64.so.2\" (CRC mismatch).\n" 427,220 &"\n" 427,223 &"warning: the debug information found in \"/usr/lib/debug//usr/lib64/ld-2.30.so.debug\" doe\ s not match \"/lib64/ld-linux-x86-64.so.2\" (CRC mismatch).\n" 427,223 &"\n" 427,273 30^running 427,273 *running,thread-id="all" 427,274 (gdb) 427,274 31^done,groups=[{id="i1",type="process",pid="421842",executable="/home/michael/eclipse-works\ pace/test/Debug/test",cores=["4"]}] 427,274 (gdb) 427,274 =library-loaded,id="/lib64/libc.so.6",target-name="/lib64/libc.so.6",host-name="/lib64/libc.\ so.6",symbols-loaded="0",thread-group="i1",ranges=[{from="0x00007ffff7ddb6b0",to="0x00007ffff7f28bbf\ "}] 427,492 =breakpoint-modified,bkpt={number="3",type="breakpoint",disp="del",enabled="y",addr="0x00000\ 0000040112a",func="main",file="../src/test.c",fullname="/home/michael/eclipse-workspace/test/Debug/.\ ./src/test.c",line="17",thread-groups=["i1"],times="1",original-location="main"} 427,493 ~"\n" 427,493 ~"Temporary breakpoint 3, main () at ../src/test.c:17\n" 427,493 ~"17\t\tputs(\"!!!Hello World!!!\"); /* prints !!!Hello World!!! */\n" 427,493 *stopped,reason="breakpoint-hit",disp="del",bkptno="3",frame={addr="0x000000000040112a",func\ ="main",args=[],file="../src/test.c",fullname="/home/michael/eclipse-workspace/test/Debug/../src/tes\ t.c",line="17",arch="i386:x86-64"},thread-id="1",stopped-threads="all",core="4" 427,493 =breakpoint-deleted,id="3" 427,496 32-list-thread-groups 427,497 32^done,groups=[{id="i1",type="process",pid="421842",executable="/home/michael/eclipse-works\ pace/test/Debug/test",cores=["4"]}] 427,497 (gdb) 427,523 33-list-thread-groups i1 427,523 33^done,threads=[{id="1",target-id="process 421842",name="test",frame={level="0",addr="0x000\ 000000040112a",func="main",args=[],file="../src/test.c",fullname="/home/michael/eclipse-workspace/te\ st/Debug/../src/test.c",line="17",arch="i386:x86-64"},state="stopped",core="4"}] 427,523 (gdb) 427,528 34-stack-info-depth --thread 1 11 427,530 34^done,depth="1" 427,530 (gdb) 427,536 35-stack-select-frame --thread 1 0 427,536 35^done 427,536 (gdb) 427,539 36-thread-info 1 427,539 36^done,threads=[{id="1",target-id="process 421842",name="test",frame={level="0",addr="0x000\ 000000040112a",func="main",args=[],file="../src/test.c",fullname="/home/michael/eclipse-workspace/te\ st/Debug/../src/test.c",line="17",arch="i386:x86-64"},state="stopped",core="4"}] 427,539 37-list-thread-groups 427,539 (gdb) 427,539 37^done,groups=[{id="i1",type="process",pid="421842",executable="/home/michael/eclipse-works\ pace/test/Debug/test",cores=["4"]}] 427,539 (gdb) 427,557 38-stack-list-locals --thread 1 --frame 0 1 427,557 38^done,locals=[] 427,558 (gdb)
Yes, I can reproduce this exactly. In fact you can see the problem in the break insert for main from your MI script: 427,194 28-break-insert -t -f main 427,194 28^done,bkpt={number="3",type="breakpoint",disp="del",enabled="y",addr="0x000000000040112a",\ func="main",file="../src/test.c",fullname="/home/michael/eclipse-workspace/test/Debug/../src/test.c"\ ,line="17",thread-groups=["i1"],times="0",original-location="main"} fullname should be the canonical absolute path to the file, as it was in gdb 8.2 (trace from my test on gdb 8.2): 249,391 27-break-insert -t -f main 249,391 27^done,bkpt={number="2",type="breakpoint",disp="del",enabled="y",addr="0x00000000000005fe",\ func="main",file="../src/main.c",fullname="/tmp/x/dasdad/main/src/main.c",line="6",thread-groups=["i\ 1"],times="0",original-location="main"} As you can see here the fullname is the canonical absolute path. What I don't get is why it resolves sometimes (from your trace again): 427,190 26-break-insert -f /home/michael/eclipse-workspace/test/src/test.c:18 427,190 26^done,bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x0000000000401134"\ ,func="main",file="../src/test.c",fullname="/home/michael/eclipse-workspace/test/Debug/../src/test.c\ ",line="18",thread-groups=["i1"],times="0",original-location="/home/michael/eclipse-workspace/test/s\ rc/test.c:18"} In this case the breakpoint has resolved, but the fullname is wrong.
I'll try to bisect it to see where this problem was introduced.
(In reply to Jonah Graham from comment #11) > Yes, I can reproduce this exactly. > Glad it 'not just me' 8-) Actually both the break points in main work (the first is just the default first line in the program and the second was the explicit one I added. What fails is the breakpoint in the second file 'test2.c' 427,190 (gdb) 427,190 &"No source file named /home/michael/eclipse-workspace/test/src/test2.c.\n" 427,190 27^done,bkpt={number="2",type="breakpoint",disp="keep",enabled="y",addr="<PENDING>",pending=\ "/home/michael/eclipse-workspace/test/src/test2.c:9",times="0",original-location="/home/michael/ecli\ pse-workspace/test/src/test2.c:9"}
(In reply to Michael Katzmann from comment #13) > (In reply to Jonah Graham from comment #11) > > Yes, I can reproduce this exactly. > > > > Glad it 'not just me' 8-) > > Actually both the break points in main work (the first is just the default > first line in the program and the second was the explicit one I added. They work - but "by accident" the response from GDB is incorrect for the function breakpoint (or at least different than it has been for years)
I have a workaround* - if you do "set basenames-may-differ on" then GDB does extra work to canonicalize names. Of course in this case the basenames don't differ! The problem is indeed caused by https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a0c1ffedcf1988bc13fc5b6d57d3b74a17b60299 - what I don't understand is why the fix done in Bug 24687 fixes it in some cases, but not others. * In CDT set the GDB Command file (in launch configuration) to file containing "set basenames-may-differ on" - AFAICT if GDB has already looked up a given file then it is too late and the workaround does not work, so the init file way allows it to be run before the breakpoints are inserted.
(In reply to Jonah Graham from comment #15) > I have a workaround* - if you do "set basenames-may-differ on" then GDB does > extra work to canonicalize names. Of course in this case the basenames don't > differ! > Great ...thanks Jonah, that works for me.
The current code in GDB requires IDEs or similar to know the path the user compiled that file with to be able to insert breakpoints. This is a change from GDB 8 and before. Here is a trace of a session showing the problem using symlinks - the same thing happens when using .. in paths (trace for that below): $ pwd /scratch/gdb/test $ cat src/main.c int main(void) { extern int main2(void); return main2(); } $ cat src/main2.c int main2(void) { return 0; } $ ln -s src src_link $ cd src_link $ gcc -g -o main main.c main2.c $ cd ../src $ gdb main # Running stock GDB on Ubuntu GNU gdb (Ubuntu 8.2-0ubuntu1~18.04) 8.2 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from main...done. (gdb) b /scratch/gdb/test/src/main.c:1 # Breakpoint inserts successfully for both files Breakpoint 1 at 0x5fe: file main.c, line 3. (gdb) b /scratch/gdb/test/src/main2.c:1 # Breakpoint inserts successfully for both files Breakpoint 2 at 0x609: file main2.c, line 2. (gdb) quit $ /scratch/gdb/build-gdb-9/gdb/gdb main # Running gdb-9-branch HEAD GNU gdb (GDB) 9.0.90.20200201-git Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from main... (gdb) b /scratch/gdb/test/src/main.c:1 # Breakpoint inserts successfully for this file Breakpoint 1 at 0x5fe: file main.c, line 3. (gdb) b /scratch/gdb/test/src/main2.c:1 # Breakpoint FAILs/pending No source file named /scratch/gdb/test/src/main2.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) b /scratch/gdb/test/src_link/main2.c:1 # Insert breakpoint on compilation path works Breakpoint 2 at 0x609: file main2.c, line 2. (gdb) del 2 (gdb) b /scratch/gdb/test/src/main2.c:1 # And then it works on this path # - this command is same as a few lines up Breakpoint 3 at 0x609: file main2.c, line 2. ### And here is with .. in the compilation path: $ pwd /scratch/gdb/test/src $ gcc -o main -g ../src/main.c ../src/main2.c $ gdb --quiet -ex 'b /scratch/gdb/test/src/main2.c:1' -ex 'quit' main Reading symbols from main...done. Breakpoint 1 at 0x609: file ../src/main2.c, line 2. $ /scratch/gdb/build-gdb-9/gdb/gdb --quiet main Reading symbols from main... (gdb) b /scratch/gdb/test/src/main2.c:1 ## Breakpoint fails here No source file named /scratch/gdb/test/src/main2.c. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) b main2.c:1 Breakpoint 1 at 0x609: file ../src/main2.c, line 2. (gdb) b /scratch/gdb/test/src/main2.c:1 ## same command works here Note: breakpoint 1 also set at pc 0x609. Breakpoint 2 at 0x609: file ../src/main2.c, line 2. (gdb) quit $
I posted my plea for consideration on https://sourceware.org/ml/gdb-patches/2020-02/msg00005.html
Accepted as blocking for the GDB 9.1 release, so setting the Target Milestone accordingly.
The gdb-9-branch branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=76f5096cd444948843f5bf65eee33c32881d6332 commit 76f5096cd444948843f5bf65eee33c32881d6332 Author: Tom Tromey <tromey@adacore.com> Date: Wed Feb 5 10:53:44 2020 +0100 Revert basenames_may_differ patch Commit a0c1ffedc regressed certain cases coming from Eclipse. See PR breakpoints/24915. This patch reverts the commit for the gdb 9 release. gdb/ChangeLog 2020-02-07 Tom Tromey <tromey@adacore.com> PR breakpoints/24915: * source.c (find_and_open_source): Do not check basenames_may_differ. gdb/testsuite/ChangeLog 2020-02-07 Tom Tromey <tromey@adacore.com> PR breakpoints/24915: * gdb.base/annotate-symlink.exp: Use setup_xfail. Change-Id: Iadbf42f35eb40c95ad32b2108ae25d8f199998bd
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5abbbe1d13e03496af5564b997f3c3a2e79b4d73 commit 5abbbe1d13e03496af5564b997f3c3a2e79b4d73 Author: Tom Tromey <tromey@adacore.com> Date: Wed Feb 5 10:53:44 2020 +0100 Revert basenames_may_differ patch Commit a0c1ffedc regressed certain cases coming from Eclipse. See PR breakpoints/24915. gdb/ChangeLog 2020-02-07 Tom Tromey <tromey@adacore.com> PR breakpoints/24915: * source.c (find_and_open_source): Do not check basenames_may_differ. gdb/testsuite/ChangeLog 2020-02-07 Tom Tromey <tromey@adacore.com> PR breakpoints/24915: * gdb.base/annotate-symlink.exp: Use setup_xfail. Change-Id: Iadbf42f35eb40c95ad32b2108ae25d8f199998bd
Fixed. I filed a follow-up bug, see bug#25518.