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

["philippe.waroquiers at skynet dot be" <sourceware-bugzilla@sourceware.org>]

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.