Windows DLL support update.

Pedro Alves pedro_alves@portugalmail.pt
Tue Aug 14 00:24:00 GMT 2007


Hi all,

Here is the new version of the patch that converts native win32
debugging to use the new solib-target.c.  The biggest difference
compared to the latest version Daniel posted is that this
version maintains the list of loaded dlls separately from
solib-target.c, similarly to what is done in current cvs.  The
previous versions always queried the target for the dll list
and maintained no private list.  At the time it sounded like a
good idea, since, well, if Windows already maintains the list, we
might as well just read it.  It turns out that this wasn't perfect
because it still required us to keep at least the last loaded dll
(last_loaded_dll_valid mechanism in the previous version),
because when a dll (un)load event occurs, the loader hasn't
completely finished the load, and the dll isn't reported on
the lists.  This version is now similar to what current
gdbserver is doing.

I've kept this version of the patch to a minimum, by removing the
fixes of formatting violations, typos and dead code removals
from the patch.

The patch could be easily be split further.  Probably the writebuf
fix in corelow.c and the infcmd.c hunks could go in on their own.
The xml and objstack changes could also go in separately, but
they don't have any other users yet.  Daniel, you've written
most of the changes outside of win32-nat.c, I'll leave that decision
to you.  If you want me to do that, just say so.

I've ran the testsuite on Windows XP several times against an
unpatched current cvs, against a gdb patched with the
previous patch, and with this patch.  I've carefully compared
the results (1), of all the runs and didn't see any regression.
I did see one consistent improvement in unload.exp

-FAIL: gdb.base/unload.exp: continuing to end of program
-FAIL: gdb.base/unload.exp: rerun to shared library breakpoint
-FAIL: gdb.base/unload.exp: continuing to end of program second time (the
program is no longer running)
+PASS: gdb.base/unload.exp: continuing to end of program
+PASS: gdb.base/unload.exp: rerun to shared library breakpoint
+PASS: gdb.base/unload.exp: continuing to end of program second time

I didn't really took the time to see why these tests
failed before.

(1) Test results aren't stable.  I always have to repeat a few,
because they usually fail UNTESTED due to several reasons, like
the compile step failing because the output binfile is still
loaded by the previous test (Windows only), or, eg:
     (...)
     -PASS: gdb.cp/maint.exp: maint cp first_component foo<
     -PASS: gdb.cp/maint.exp: maint cp first_component foo(
     -PASS: gdb.cp/maint.exp: maint cp first_component bool operator<<char>
     -PASS: gdb.cp/maint.exp: maint cp namespace
     +ERROR: Process no longer exists
     +UNRESOLVED: gdb.cp/maint.exp: maint cp first_component operator  ->
     +ERROR: Couldn't send maint cp first_component foo() to GDB.
     +UNRESOLVED: gdb.cp/maint.exp: maint cp first_component foo()
     +ERROR: Couldn't send maint cp first_component foo(int) to GDB.
     +UNRESOLVED: gdb.cp/maint.exp: maint cp first_component foo(int)
     (...)

This should also fix the problem Joel reported at:
[win32] wrong solib from/to addresses
http://sourceware.org/ml/gdb-patches/2007-06/msg00210.html

... but I have no Vista to test on.

Cheers,
Pedro Alves

P.S.

The testresults (c, c++) look somewhat (1 above) like this with gcc+gdb patches
to overcome the '__main emitted in main breaks run_to_main' problem.

# of expected passes            9441
# of unexpected failures        177
# of unexpected successes       1
# of expected failures          47
# of known failures             30
# of unresolved testcases       21
# of untested testcases         16
# of unsupported tests          32




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


More information about the Gdb-patches mailing list