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,

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,

Roland


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