From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id C65F3388C031; Sun, 21 Jun 2020 17:26:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C65F3388C031 From: "brobecker at gnat dot com" 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 17:26:27 +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: brobecker at gnat dot com 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 17:26:27 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25475 --- Comment #20 from Joel Brobecker --- > * Following build-id mismatch, GDB loads the new exec file without asking > a question, as the current exec-file has no debug symbol. I had to dig into the code to understand the context better, so let me share that here: The question that we would expect if exec-file-mismatch is set to "ask" is actually the same question we already had before and get when loading a new executable in place of an existing one. More precisely, what I am seeing validate_exec_file do is: 1. generate a warning about the discrepancy; and then 2. if exec-file-mismatch is set to "ask", call symbol_file_add_main That explains why Philippe was looking at the "Load new symbol table" check in symbol_file_add_with_addrs. > 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. I think we should widen this discussion to a bigger audience, so I'd like to propose you guys move this to gdb-patches, and publish a link to the discussion here. Regarding option (1), I think the impact on the testsuite is a consideratio= n, but not necessarily a strong one. It might be strong if the failures it demonstrates provides an explanation to the current behavior. Otherwise, we should review this proposed change by asking ourselves whether it would make better sense to always ask the question or not. For me, option (2) would certainly be better than nothing, but wouldn't take away the fact that the current behavior is confusing. For option (3), changing it to "load" doesn't make sense to me, because then what it feels like to me is that "load" and "warn" are identifical. I have two alternative proposals: (4) Change exec-file-mismatch ask/load/off with an on/off switch This is option 3 changed to remove the "ask" option (5) Update symbol_file_add_with_addrs to accept an addition flag, which forces the question, and pass that flag when called from validate_exec_file and exec-file-mismatch is set to "ask" (but only if stdin is a tty, of course) Personally, I think it's nice that users have the opportunity to confirm if GDB detects a mismatch, so (5) has my preference. --=20 You are receiving this mail because: You are on the CC list for the bug.=