Re: Strange stack trace on Windows

[Joel Brobecker <brobecker@adacore.com>]

> This list could get quite very long. I already considered to do
> something like that, but just as some kind of last resort as the list
> could get  quite very long. It must contain quite every windows
> function. Or completely match dll names like msvcrt.dll

Right - this is one of the reasons why AdaCore decided not to go
that route. In all fairness, most of our uses debug Ada, and thus
do not face the same issue as you do, since they rarely write code
that contains calls to Windows functions. So the compromise does
not impact us as much as it impacts you.

> Wouldn't it be possible to also adjust gdb's stepping code to work with
> your patch? Or (also not really nice, but maybe cleaner) to
> only use your patch for stack dumping. For stepping rely on the
> "other" (means current) frame code.

Unfortunately, not. Everything is related: In order to determine whether
we stepped into a function during the "next", we do the equivalent of
a 2-frame backtrace.

However, thinking about this a little more, perhaps there is a way out
for the "next" case: Try checking the PC against the start address
of the function. If the PC is at the start address of your function,
then the function prologue hasn't had time to adjust the stack in such
a way that we can't unwind from it, and thus the normal processing
should work.

> It is quite painful to use gdb on windows for quite a while now.
> Windows, whether one may like it or not, is a major platform
> and gdb should also operate well here. I am fighting for a long time
> with these problems now.

As I hinted earlier, I think that this has to do with the fact that
you debug code that makes calls to functions that live inside DLLs.
This is a relatively specific condition...

> Isn't there a general solution thinkable?  GDB is cool piece of
> software. For me it is "THE" debugger but this problem transforms more
> and more into killer problem here.

Pedro answered exactly what I would have answered: The real proper
way to fix the problem is to teach GDB how to read the Windows "debug"
info. So far, no one has had enough interest in this project to see
it through.

-- 
Joel