[Bug gdb/25475] FAIL: gdb.server/solib-list.exp: non-stop 0/1: target remote (got interactive prompt)

["brobecker at gnat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25475

--- Comment #20 from Joel Brobecker <brobecker at gnat dot com> ---
> * 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 consideration,
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.