This is the mail archive of the gdb@sources.redhat.com 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: gdb stack trace problems (Addendum)


On Mon, May 09, 2005 at 07:45:05AM +0300, Eli Zaretskii wrote:
>> Date: Sun, 8 May 2005 19:19:53 -0400
>> From: Christopher Faylor <me@cgf.cx>
>> 
>> What kind of windows-specific solution do you have in mind?  How would
>> you know what to unwind?  You could potentially figure out that you're
>> stuck in a system function but that doesn't mean that you know the
>> state of the stack.
>> 
>> If a function doesn't set up a frame pointer and there is no debugging
>> information available, how would one derive a stack frame?  I could
>> imagine a really complicated "search the stack" technique but I can't
>> see how it would ever be foolproof.
>
>Does the MSVC debugger manage to display a sensible backtrace in this
>case?  If it does not, we don't need to worry, I think.

Possibly.  They may have some separate debugging symbol files available
for system DLLs.  I'm not extremely interested in making gdb understand
native MSVC debugging format though.

>If it does, then perhaps teh frameless functions in system DLLs follow
>some pattern in their prologue that could help us?  Or perhaps they
>save stack-related info in some Windows-specific place?

I've never noticed anything special on the stack or in the assembly
language.  I'm not 100% sure that the system functions are written
in C.

cgf


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