This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange stack trace on Windows


Hi...

Joel Brobecker wrote on 17.03.2009 16:08:35:
> > 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.
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).

> > 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...
Really so specific? I don't think so. Having dlls is quite common
on windows. The operating system itself is mostly a bunch of dlls. And if
one wants to use these functions he has to call them. As in my
example setbuf() from msvcrt.dll.

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

Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]