Re: Strange stack trace on Windows

[Joel Brobecker <brobecker@adacore.com>]

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

> That sounds interesting... :-)
> Could you outline that a bit more? Where and how can I do that?
> (I am digging in gdb's source only for a few days now).

You can try the attached patch. What it does is that it matches
the "current_pc" with the start address of the associated function
(if any). If they are identical, then we're at the beginning of
the function.   In that case, we know that the function will appear
frameless since the frame hasn't been setup, but we also know how to
unwind properly from it.  I can't test the patch right now, so let
me know how it goes.

> Hmm.. Are so few people using gdb on windows? I think there should be
> way more interest in getting gdb to deal right with MS debugging
> format in order to get also debugging with frameless functions right.

Not sure. I suspect that most people don't debug programs using
threads, and so don't need AdaCore's patch. And if you don't install
the patch, then the "next" problem goes away.

-- 
Joel

[-- Attachment #2: unwind.diff --]
[-- Type: text/x-diff, Size: 546 bytes --]

diff --git a/gdb/i386-tdep.c b/gdb/i386-tdep.c
index 0d77fab..073721e 100644
--- a/gdb/i386-tdep.c
+++ b/gdb/i386-tdep.c
@@ -1561,7 +1561,8 @@ i386_frame_cache (struct frame_info *this_frame, void **this_cache)
 	 functions this might work too.  */
 
       current_pc = get_frame_pc (this_frame);
-      if (i386_in_dll (current_pc)
+      if (current_pc == cache->pc
+          && i386_in_dll (current_pc)
           && !i386_function_has_frame (current_pc))
         {
           /* Functions in DLL for which do not seem to create a standard