This is the mail archive of the
mailing list for the GDB project.
Re: Strange stack trace on Windows
- From: Roland Schwingel <roland dot schwingel at onevision dot de>
- To: Joel Brobecker <brobecker at adacore dot com>, gdb <gdb at sourceware dot org>
- Date: Wed, 18 Mar 2009 10:25:51 +0100
- Subject: Re: Strange stack trace on Windows
Joel Brobecker wrote on 17.03.2009 20:42:56:
> > 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.
First thank you for your patch and time! I really appreciate that!
I adapted your diff (hopefully correctly) to match the i386_frame_cache()
function from gdb's CVS head. Obviously is your i386-tdep.c quite
different to the one from CVS head. I think I did not made any mistake
in adding the comparison.
Unfortunately it does not work.
cache->pc is set from get_frame_func(this_frame).
current_pc is set from get_frame_pc(this_frame)
(BTW: In the current CVS head there is no current_pc anymore
in i386_frame_cache(). I added it on my own.)
In my tests both cache->pc and current_pc are ALWAYS identical.
Mabye it has something to do with your different i386-tdep.c?
Would it help when I create sample code and send it to you?
Again thank you for patch,