Help, --target_board=native-stdio-gdbserver is unusable
Commit Message
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
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 /"]
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