Re: Windows DLL support update.

[Pedro Alves <pedro_alves@portugalmail.pt>]

Pedro Alves wrote:
> 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.
> 


And I forgot to say the reason I did this now.  This is one
way to enable a Cygwin hosted gdb to take advantage of the
new gdbserver dll support.  Currently win32-nat.c has one of
those beauties:

   /* FIXME: Don't do this here.  *_gdbarch_init() should set so_ops. */
   current_target_so_ops = &win32_so_ops;

... target remote then always uses win32_so_ops, which, of course,
is broken ...

If this patch is too late for 6.7, I'd like to at least have that
fixed.

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
> 
>