|
From: Philippe W. <phi...@sk...> - 2015-08-25 19:00:30
|
On Tue, 2015-08-25 at 11:34 +0200, Mark Wielaard wrote: > + -e '/warning: remote target does not support file transfer, attempting to access files from local filesystem./d' > > Makes all gdbserver_tests PASS again, except one gdbserver_tests/hgtls. > But that seems an unrelated issue. Shall we just go with a filter, or do > you want to look into supporting file transfers in vgdb first? Hello Mark, Thanks for looking at these failures, and for the filter. Ok to go with the filter, that is largely good enough for the following reasons: 1. implementing file transfer in valgrind gdbserver implies some non minor work (a few hundreds lines of code, I would say). 2. the typical use case of Valgrind gdbserver is to have Valgrind and GDB on the same host, so using gdbserver remote protocol to access files will just be significantly slower, in most cases, and GDB will automatically use the remote file access if V gdbserver would provide it. Of course, without remote file access, it means that for a 'real' remote valgrind (i.e. using vgdb via tcp/ip), that you must have a local copy of the executable and libraries, so that gdb can read them locally. For what concerns the hgtls failure: this is due to a regression in GDB, see bug 'regression in showing __thread so extern variable' https://sourceware.org/bugzilla/show_bug.cgi?id=18564 that has a small reproducer. If someone has a 'gdb bissect setup', this might help to find the regression origin. Philippe |