From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 09F0D383E832; Sun, 21 Jun 2020 11:21:52 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 09F0D383E832 From: "philippe.waroquiers at skynet dot be" To: gdb-prs@sourceware.org Subject: [Bug gdb/25475] FAIL: gdb.server/solib-list.exp: non-stop 0/1: target remote (got interactive prompt) Date: Sun, 21 Jun 2020 11:21:51 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: philippe.waroquiers at skynet dot be X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Jun 2020 11:21:52 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25475 --- Comment #19 from philippe.waroquiers at skynet dot be --- (In reply to Joel Brobecker from comment #17) > Philippe proposed we put this one on the list of issues we should consider > for the GDB 10.1 release. >=20 > At the moment, I am confused about the relationship between the problem > being reported, the portion of code being discussed, and the CLI change > proposal. >=20=20 > Do we understand why GDB thought the executable as ld-2.26.so (the loader= )? > I have a suspicion that this is the important question, is it not. In oth= er > words, yes, you guys probably found a bug where GDB is not asking > confirmation when it should, but isn't the crux of the matter the fact th= at > GDB thinks > the executable is now ld-2.26.so, which of course doesn't match the > executable > it was given. If GDB thought instead that the executable was still > `solib-list', > I assume that we wouldn't get better an error about matching executables. >=20 > Did I misunderstand what the test is doing? If I did, considering Philipp= e's > results on his experiment, my knee-jerk reaction is that this is the kind= of > change that we should consider carefully before putting it in a release. > The bug itself seems relatively minor. I think we have 2 (unrelated) aspects: * In this test, GDB determines that the exec file is ld-2.26.so I think this is normal: the test explicitly tells to start=20 this "loader" exec file. See a.o. comment: # Unset last_loaded_file because we want GDBserver spawn # ${interp_system} not ${last_loaded_file}. * Following build-id mismatch, GDB loads the new exec file without asking a question, as the current exec-file has no debug symbol. This can be reproduced with "normal" exec files not using gdbserver. See log below. So, this bug is only about the fact that exec-file-mismatch "ask" setting indicates it will ask a question, but no question is asked when the current exec file has no debug info. So, we have various ways to handle this bug: * modify GDB to always ask a question, even when current exec file has no debug info. That made a lot of tests fail, so not attractive. * keep current behaviour, but just clarify in the doc and help that "ask" asks a question only when current exec file has debug info. * replace in the 'exec-file-mismatch' setting "ask" by "load" and similarly change the doc to explain that a question is asked if the current exec file has debug info, otherwise the new file is loaded unconditionally. Philippe (gdb) atta 16623 <<<<<<<<<<<<<<<< this runs stripped_sleepers, <<<<<<<<<<<<<<<< build-id differs from sleepers used by second attach Attaching to process 16623 ... (gdb) detach Detaching from program: /home/philippe/gdb/littleprogs/stripped_sleepers, process 16623 [Inferior 1 (process 16623) detached] (gdb) atta 358 Attaching to program: /home/philippe/gdb/littleprogs/stripped_sleepers, pro= cess 358 [New LWP 360] [New LWP 361] [New LWP 362] warning: Mismatch between current exec-file /home/philippe/gdb/littleprogs/stripped_sleepers and automatically determined exec-file /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers exec-file-mismatch handling is currently "ask" <<<<<<<<<<<<<<<<<<< No question here, GDB just loads the sleepers exec file Reading symbols from /home/philippe/valgrind/git/trunk_untouched/gdbserver_tests/sleepers... [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f1bd4c88037 in __GI___select (nfds=3D0, readfds=3D0x0, writefds=3D0x= 0, exceptfds=3D0x0, timeout=3D0x55bd26e491a0 ) at ../sysdeps/unix/sysv/linux/select.c:41 41 ../sysdeps/unix/sysv/linux/select.c: No such file or directory. (gdb) --=20 You are receiving this mail because: You are on the CC list for the bug.=