[gdbserver] Automatically add an ".exe" suffix on failure.

[Pedro Alves]

Hi,

I was running the testsuite against a local gdbserver on Cygwin, and noticed
that gdbserver as opposed to a native gdb, doesn't append the ".exe" suffix to
the executable name and retry if creating the inferior process failed.  When
building natively, an .exe suffix is appended to the executable filename if
there isn't one already.  Most the testcases don't specify it.  This
results in gdbserver trying to look for an executable called break for instance,
while there is only a break.exe.  This isn't noticeable when cross testing,
since (I think) that on that case the suffix isn't appended automatically.

(Gdb does the retrying in exec.c:exec_file_attach.)

Tested on a local gdbserver which doesn't look that bad compared to a native
test run.  Unfortunately the test results aren't 100% consistent across runs,
on both native and remote, to have a good comparison...

I had to hack win32-nat.c to be able to test against a local gdbserver on native
Cygwin, because currently, a Cygwin hosted gdb will isn't able to use the new
gdbserver dll support.  This happens because a Cygwin hosted gdb will always use
the current_target_so_ops set in win32-nat.c:init_win32_ops, even when remote
debugging.

The patch to use solib-target.c on native Cygwin would fix this too.  Daniel,
I'm going to work on rewriting it to not be so aggressive fetching the list of
sos from the target, by keeping a list of dlls on win32-nat.c like it is
currently.  The patch should turn up much smaller and safer.  Maybe it can then
go into 6.7 (?),  but I wouldn't mind if it didn't either.

Cheers,
Pedro Alves




-------------- next part --------------
A non-text attachment was scrubbed...
Name: gdbserver_exe_suffix.diff
Type: text/x-diff
Size: 4358 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20070811/db0c4c59/attachment.bin>