Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Philippe Waroquiers <philippe.waroquiers@skynet.be>
To: Gary Benson <gbenson@redhat.com>
Cc: gdb-patches@sourceware.org, Pedro Alves <palves@redhat.com>,
	Joel Brobecker <brobecker@adacore.com>,
	Doug Evans <dje@google.com>, Don Breazeal <donb@codesourcery.com>
Subject: Re: [PATCH v3] Make only user-specified executable and symbol filenames sticky
Date: Mon, 08 Jun 2015 19:42:00 -0000	[thread overview]
Message-ID: <1433792516.6916.15.camel@hp> (raw)
In-Reply-To: <1433754079-10395-1-git-send-email-gbenson@redhat.com>

On Mon, 2015-06-08 at 10:01 +0100, Gary Benson wrote:

> This updated patch has been created against the latest gdb/master
> (80fb91378c91a8239817a5ab2b1c3e346109db25).  Could you please try
> your tests again?
First test with 'native' attach/detach/attach/detach/attach is
working ok.
However, the behaviour of the 3rd attach differs: a question
is asked, that is answered automatically as yes (for EOF).
So that is strange.
        GNU gdb (GDB) 7.9.50.20150608-cvs
        ...
        Type "apropos word" to search for commands related to "word".
        (gdb) atta 13286
        Attaching to process 13286
        Reading symbols from /bin/sleep...(no debugging symbols found)...done.
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f3c5bb06f20 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) detach
        Detaching from program: /bin/sleep, process 13286
        (gdb) atta 13320
        Attaching to program: /bin/sleep, process 13320
        Reading symbols from /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...done.
        Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
        [New LWP 13323]
        [New LWP 13322]
        [New LWP 13321]
        [Thread debugging using libthread_db enabled]
        Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f5f538e1da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13320
        (gdb) atta 13286
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13286
        Load new symbol table from "/bin/sleep"? (y or n) EOF [assumed Y]
        Reading symbols from /bin/sleep...(no debugging symbols found)...done.
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f3c5bb06f20 in nanosleep () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) 

2nd test is with Valgrind gdbsrv. Also working ok. However, here
we have a question (no EOF answer) asking to change or not the symbol file.
        GNU gdb (GDB) 7.9.50.20150608-cvs
        ...
        Type "apropos word" to search for commands related to "word".
        (gdb) tar rem | lvgdb
        Remote debugging using | lvgdb
        relaying data between gdb and process 13394
        warning: remote target does not support file transfer, attempting to access files from local filesystem.
        Reading symbols from /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00000000040012d0 in ?? () from /lib64/ld-linux-x86-64.so.2
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, Remote target
        Ending remote debugging.
        (gdb) tar rem | lvgdb --pid=13413
        Remote debugging using | lvgdb --pid=13413
        relaying data between gdb and process 13413
        Load new symbol table from "/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak"? (y or n) y
        Reading symbols from /home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00000000040012d0 in ?? () from /lib64/ld-linux-x86-64.so.2
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak, Remote target
        Ending remote debugging.
        (gdb) tar rem | lvgdb --pid=13394
        Remote debugging using | lvgdb --pid=13394
        relaying data between gdb and process 13394
        Load new symbol table from "/home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers"? (y or n) y
        Reading symbols from /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...done.
        Reading symbols from /home/philippe/valgrind/trunk_untouched/./.in_place/vgpreload_core-amd64-linux.so...done.
        Reading symbols from /home/philippe/valgrind/trunk_untouched/./.in_place/vgpreload_memcheck-amd64-linux.so...done.
        Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x0000000005145da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) tar rem | lvgdb --pid=13427
        A program is being debugged already.  Kill it? (y or n) n
        Program not killed.
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, Remote target
        Ending remote debugging.
        (gdb) tar rem | lvgdb --pid=13427
        Remote debugging using | lvgdb --pid=13427
        relaying data between gdb and process 13427
        Load new symbol table from "/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak"? (y or n) y
        Reading symbols from /home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00000000040012d0 in ?? () from /lib64/ld-linux-x86-64.so.2
        (gdb) 

3rd test with GDB gdbserver: there is still the problem of invalid
target.
        GNU gdb (GDB) 7.9.50.20150608-cvs
        ...
        Type "apropos word" to search for commands related to "word".
        (gdb) tar rem :1234
        Remote debugging using :1234
        Reading symbols from target:/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak...done.
        Reading symbols from target:/lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007ffff7ddb2d0 in ?? () from target:/lib64/ld-linux-x86-64.so.2
        (gdb) detach
        Detaching from program: target:/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak, process 13447
        Ending remote debugging.
        (gdb) tar rem :1235
        `target:/home/philippe/valgrind/trunk_untouched/memcheck/tests/trivialleak' has disappeared; keeping its symbols.
        Remote debugging using :1235
        Load new symbol table from "target:/home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers"? (y or n) y
        Reading symbols from target:/home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers...Can't read symbols from target:/home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers: Invalid argument
        (gdb) 

Test 4 is the same as test 1, but with gdb started with a filename as argument.
GDB gives a warning that the exec+sym file does not match the target one.
        gdb ./gdbserver_tests/sleepers 
        ...
        Type "apropos word" to search for commands related to "word"...
        Reading symbols from ./gdbserver_tests/sleepers...done.
        (gdb) atta 13474
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13474
        Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
        [New LWP 13477]
        [New LWP 13476]
        [New LWP 13475]
        [Thread debugging using libthread_db enabled]
        Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007fec5b318da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13474
        (gdb) atta 13484
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13484
        warning: Process 13484 has executable file /bin/sleep, but executable file is currently set to /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers
        warning: Process 13484 has symbol file /bin/sleep, but symbol file is currently set to /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f1d71fdef20 in ?? ()
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13484
        (gdb) atta 13474
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13474
        Reading symbols from /lib/x86_64-linux-gnu/libpthread.so.0...(no debugging symbols found)...done.
        [New LWP 13477]
        [New LWP 13476]
        [New LWP 13475]
        [Thread debugging using libthread_db enabled]
        Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
        Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007fec5b318da3 in select () from /lib/x86_64-linux-gnu/libc.so.6
        (gdb) detach
        Detaching from program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13474
        (gdb) atta 13484
        Attaching to program: /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, process 13484
        warning: Process 13484 has executable file /bin/sleep, but executable file is currently set to /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers
        warning: Process 13484 has symbol file /bin/sleep, but symbol file is currently set to /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007f1d71fdef20 in ?? ()
        (gdb) file /bin/sleep
        A program is being debugged already.
        Are you sure you want to change the file? (y or n) y
        Load new symbol table from "/bin/sleep"? (y or n) y
        Reading symbols from /bin/sleep...(no debugging symbols found)...done.
        (gdb) detach
        Detaching from program: /bin/sleep, process 13484
        (gdb) atta 13474     
        Attaching to program: /bin/sleep, process 13474
        warning: Process 13474 has executable file /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, but executable file is currently set to /bin/sleep
        warning: Process 13474 has symbol file /home/philippe/valgrind/trunk_untouched/gdbserver_tests/sleepers, but symbol file is currently set to /bin/sleep
        Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
        0x00007fec5b318da3 in ?? ()
        (gdb) 
        


So, in summary, this patch version is better but there are still some
strange behaviours.

In terms of behaviour, it is somewhat surprising to sometimes have a question,
sometimes not. IMO, it would be better to always ask a question when the currently loaded
file does not match the target file (native attach or remote target), even when
the file was supplied by the user.

Philippe



  reply	other threads:[~2015-06-08 19:42 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-02  9:48 qXfer:exec-file:read and non multiprocess target Philippe Waroquiers
2015-05-05 11:02 ` Gary Benson
2015-05-05 20:45   ` Philippe Waroquiers
2015-05-06 10:31     ` Gary Benson
2015-05-06 17:10       ` [PATCH] Locate executables on remote stubs without multiprocess extensions Gary Benson
2015-05-06 17:15         ` Eli Zaretskii
2015-05-06 17:16         ` Gary Benson
2015-05-11 14:37           ` Pedro Alves
2015-05-12 11:03             ` Gary Benson
2015-05-05 15:14 ` qXfer:exec-file:read and non multiprocess target Gary Benson
2015-05-06 10:26   ` [PATCH] Make only user-specified executable filenames sticky Gary Benson
2015-05-06 12:19     ` Pedro Alves
2015-05-06 14:21       ` Pedro Alves
2015-05-06 15:20       ` Gary Benson
2015-05-11 13:57         ` Pedro Alves
2015-05-06 14:46     ` Philippe Waroquiers
2015-05-06 15:41       ` Gary Benson
2015-05-11 13:58         ` Pedro Alves
2015-05-11 20:25       ` Doug Evans
2015-05-11 17:14     ` Don Breazeal
2015-06-05  9:37       ` Gary Benson
2015-06-05 14:54         ` Don Breazeal
2015-07-03 11:14           ` Gary Benson
2015-07-06 12:53             ` Joel Brobecker
2015-07-17 21:48             ` Joel Brobecker
2015-05-11 20:23     ` Doug Evans
2015-05-12 10:36       ` Pedro Alves
2015-05-12 11:13         ` Gary Benson
2015-05-12 11:16           ` Pedro Alves
2015-05-12 13:48             ` Gary Benson
2015-05-12 14:08               ` Pedro Alves
2015-05-12 15:49         ` Doug Evans
2015-05-13  7:55           ` Gary Benson
2015-05-13  9:12             ` Pedro Alves
2015-06-03 17:23               ` Joel Brobecker
2015-06-05 11:22                 ` [PATCH v2] Make only user-specified executable and symbol " Gary Benson
2015-06-07 11:40                   ` Philippe Waroquiers
2015-06-08  9:01                     ` [PATCH v3] " Gary Benson
2015-06-08 19:42                       ` Philippe Waroquiers [this message]
2015-07-03 11:01                         ` Gary Benson
2015-07-03 15:44                       ` Pedro Alves
2015-07-06 13:01                         ` Pedro Alves
2015-06-07 12:03                   ` [PATCH v2] " Philippe Waroquiers
2015-06-07 12:13                   ` Philippe Waroquiers
2015-05-13  8:06           ` [PATCH] Make only user-specified executable " Pedro Alves
2015-05-12 16:03         ` Doug Evans
2015-05-13  8:39           ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1433792516.6916.15.camel@hp \
    --to=philippe.waroquiers@skynet.be \
    --cc=brobecker@adacore.com \
    --cc=dje@google.com \
    --cc=donb@codesourcery.com \
    --cc=gbenson@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox