diff mbox

Help, --target_board=native-stdio-gdbserver is unusable

Message ID 047d7b11194bfccb32051eba3541@google.com
State New
Headers show

Commit Message

Doug Evans Sept. 2, 2015, 2:13 a.m. UTC 
Hi.

Has anyone tried running the testsuite with native-stdio-gdbserver
now that we're auto-fetching files from the inferior?

With 7.9 the following completes in 2:39 minutes.
With trunk it completes in 21:09.

make check RUNTESTFLAGS="--target_board=native-stdio-gdbserver  
gdb.trace/*.exp"

Also, looking through gdb.log I'm seeing the same files
apparently being fetched multiple times.

E.g.,

Reading /foo/lib64/libm.so.6 from remote target...
Reading /foo/lib64/libc.so.6 from remote target...
Reading /foo/lib64/libm-2.19.so.debug from remote target...
Reading /foo/lib64/.debug/libm-2.19.so.debug from remote target...
Reading /foo/lib64/.debug/libm-2.19.so.debug from remote target...
Reading /foo/lib64/libc-2.19.so.debug from remote target...
Reading /foo/lib64/.debug/libc-2.19.so.debug from remote target...
Reading /foo/lib64/.debug/libc-2.19.so.debug from remote target...

Note that foo.so.debug is read once and then
.debug/foo.so.debug is read twice.

I haven't tried any other gdbserver combinations.
I suspect all of them have the same issue w.r.t. slowness.

How about something like this?
Or have people thought of solving this a different way?


[I'd clean that up and add a comment before committing it.]

It'd also be nice to have a test that explicitly
exercises the fetching of remote files in gdb.server/foo.exp,
even with native-stdio-gdbserver.

Another thing I noticed.
The usability of "set debug remote 1" has vastly dropped.
Can we not print the contents of files that are fetched,
unless "set debug remote 2" or some such?
That may be hard, I haven't looked at whether the code
can easily know the received data is for a fetched file,
but it's really bad. We've got to do something.

Cheers.

Comments

Yao Qi Sept. 2, 2015, 11:06 a.m. UTC | #1 
Doug Evans <dje@google.com> writes:

> I haven't tried any other gdbserver combinations.
> I suspect all of them have the same issue w.r.t. slowness.

Yes, I think so.  We need to fix it in native-extended-gdbserver.exp,
native-gdbserver.exp, and native-stdio-gdbserver.exp.

>
> How about something like this?
> Or have people thought of solving this a different way?

I am using this in my board files for arm and aarch64 testing.

set_board_info gdb_init_commands [list "set sysroot /"]
diff mbox

Patch

diff --git a/gdb/testsuite/boards/native-stdio-gdbserver.exp  
b/gdb/testsuite/boards/native-stdio-gdbserver.exp
index 2ec2a47..c6f2027 100644
--- a/gdb/testsuite/boards/native-stdio-gdbserver.exp
+++ b/gdb/testsuite/boards/native-stdio-gdbserver.exp
@@ -58,6 +58,8 @@  proc ${board}_spawn { board cmd } {

      verbose -log "${board}_spawn: $board $cmd"

+    gdb_test_no_output "set sysroot"
+
      # Save the command to start gdbserver for later retrieval by
      # ${board}_get_remote_address.
      global stdio_gdbserver_command