This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

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

[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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]