As I noted in PR20569, several exec-related tests cause GDB to segv when 
sysroot translation fails on the executable pathname reported by 
gdbserver.  The immediate cause of the segv is that follow_exec is 
passing a NULL argument (the result of exec_file_find) to strlen, but as 
I looked at the code in more detail it seemed like follow_exec simply 
isn't prepared for the case where sysroot translation fails to locate 
the new executable, and there is no obvious recovery strategy.

I thought I could copy logic from the other caller of exec_file_find, 
exec_file_locate_attach, but I think it's doing the wrong thing there as 
well.  Plus, from reading the code I found other bugs in both callers of 
exec_file_find due to confusion between host and target pathnames.

The attached patch attempts to fix all the bugs.  In terms of the 
testcases that were formerly segv'ing, GDB now prints a warning but 
continues execution of the new program, so that the tests now mostly 
FAIL instead.  You could argue the FAILs are due to a legitimate problem 
with the test environment setting up the sysroot translation 
incorrectly, but I'm not sure continuing execution rather than leaving 
the target stopped is the most user-friendly fallback behavior, either. 
  E.g. the GDB manual suggests that you can set a breakpoint on main and 
GDB will stop on main of the newly exec'ed program, too, but it can't do 
that if it can't find the symbol information, and there's no way for the 
user to specify the executable file to GDB explicitly before it resumes 
execution.  But, seemed better not to complicate this 
already-too-complicated patch further by trying to address that in the 
first cut.

Comments?  Suggestions?  Etc.

-Sandra