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

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

[vries at gcc dot gnu.org]

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

--- Comment #15 from Tom de Vries <vries at gcc dot gnu.org> ---
I've fixed the FAIL here by working around the issue in the test-case (
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=6b9374f1e07cb250736815ff8db263199416adc6
).

Leaving the PR open for the gdb issue.

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

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

[philippe.waroquiers at skynet dot be]

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

--- Comment #16 from philippe.waroquiers at skynet dot be ---
I evaluated the change to ask the question independently
of the fact that the current loaded file has symbols, i.e. removing
the following part of the condition :
  (have_full_symbols () || have_partial_symbols ())
to ask the "Load new symbol table" question.

This seems to be a significant change in behaviour that triggers
about 1200 new failures in the gdb testsuite.
The ratio (cost+risk)/benefit looks poor for this change.

Another possible way to fix this is to replace the value "ask"
by "load" (and explain in the doc that typically, a question is asked
before loading the new file):

  (gdb) h set exec-file-mismatch 
  Set exec-file-mismatch handling (load|warn|off).
  Specifies how to handle a mismatch between the current exec-file name
  loaded by GDB and the exec-file name automatically determined when attaching
  to a process:

   load - warn the user and load the determined exec-file.
   warn - warn the user, but do not change the exec-file.
   off  - do not check for mismatch.
  (gdb) 


WDYT ?

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

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

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at sourceware dot org

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

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

[brobecker at gnat dot com]

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

Joel Brobecker <brobecker at gnat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |brobecker at gnat dot com

--- Comment #17 from Joel Brobecker <brobecker at gnat dot com> ---
Philippe proposed we put this one on the list of issues we should consider
for the GDB 10.1 release.

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.

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 other
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 that 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.

Did I misunderstand what the test is doing? If I did, considering Philippe'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.

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

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

[vries at gcc dot gnu.org]

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

--- Comment #18 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Joel Brobecker from comment #17)
> Do we understand why GDB thought the executable as ld-2.26.so (the loader)?

I suspect that is due to the test-case.  It does things like:
...
set interp_system [section_get ${binfile} .interp]
set res [gdbserver_spawn "${interp_system} ${remote_binfile}"]
...

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

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

[philippe.waroquiers at skynet dot be]

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

--- 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.
> 
> 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.
>  
> 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 other
> 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 that
> 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.
> 
> Did I misunderstand what the test is doing? If I did, considering Philippe'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 
  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, process
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=0, readfds=0x0, writefds=0x0,
exceptfds=0x0, timeout=0x55bd26e491a0 <t>)
    at ../sysdeps/unix/sysv/linux/select.c:41
41      ../sysdeps/unix/sysv/linux/select.c: No such file or directory.
(gdb)

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

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

[brobecker at gnat dot com]

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.

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

[philippe.waroquiers at skynet dot be]

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

--- Comment #21 from philippe.waroquiers at skynet dot be ---
(In reply to Joel Brobecker from comment #20)
>   (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.
Looks a good idea.  I will prepare a patch and post it on gdb-patches,
referencing this PR.

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

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

[philippe.waroquiers at skynet dot be]

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

--- Comment #22 from philippe.waroquiers at skynet dot be ---
(In reply to philippe.waroquiers from comment #21)
> (In reply to Joel Brobecker from comment #20)
> >   (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.
> Looks a good idea.  I will prepare a patch and post it on gdb-patches,
> referencing this PR.

Submitted patch in :
https://sourceware.org/pipermail/gdb-patches/2020-June/169773.html

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

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #23 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Philippe Waroquiers
<philippe@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a8654e7d784980cb4596f685964200fcc1164c78

commit a8654e7d784980cb4596f685964200fcc1164c78
Author: Philippe Waroquiers <philippe.waroquiers@skynet.be>
Date:   Sun Jun 21 21:26:25 2020 +0200

    Fixes PR 25475: ensure exec-file-mismatch "ask" always asks in case of
mismatch.

    As explained in https://sourceware.org/bugzilla/show_bug.cgi?id=25475,
    when the currently loaded file has no debug symbol,
    symbol_file_add_with_addrs does not ask a confirmation to the user
    before loading the new symbol file.  The behaviour is not consistent
    when symbol_file_add_with_addrs is called due to exec-file-mismatch "ask"
    setting.

    The PR discusses several solutions/approaches.
    The preferred approach (suggested by Joel) is to ensure that GDB always
asks
    a confirmation when it loads a new symbol file due to exec-file-mismatch,
    using a new SYMFILE add-flag.

    I tested this manually.  If OK, we can remove the bypass introduced by Tom
    in 6b9374f1, in order to always answer to the 'load' question.

    gdb/ChangeLog
    2020-06-24  Philippe Waroquiers  <philippe.waroquiers@skynet.be>

            * symfile-add-flags.h: New flag SYMFILE_ALWAYS_CONFIRM.
            * exec.c (validate_exec_file): If from_tty, set both
            SYMFILE_VERBOSE (== from_tty) and SYMFILE_ALWAYS_CONFIRM.
            * symfile.c (symbol_file_add_with_addrs): if always_confirm
            and from_tty, unconditionally ask a confirmation.

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

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

[philippe.waroquiers at skynet dot be]

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

philippe.waroquiers at skynet dot be changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #24 from philippe.waroquiers at skynet dot be ---
fixed by a8654e7d784980cb4596f685964200fcc1164c78

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

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

[brobecker at gnat dot com]

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

--- Comment #25 from Joel Brobecker <brobecker at gnat dot com> ---
Well done, Philippe, and thank you!

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