Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Roland Schwingel <roland.schwingel@onevision.de>
Cc: gdb <gdb@sourceware.org>
Subject: Re: Strange stack trace on Windows
Date: Tue, 17 Mar 2009 13:19:00 -0000	[thread overview]
Message-ID: <20090317131949.GA32001@adacore.com> (raw)
In-Reply-To: <49BF903D.6090900@onevision.de>

> With the patch from Joel I get really good strack traces back in this case.

Glad to hear that you were able to put the patch to good use :)

> But there is mabye a sideeffect of this patch when stepping thru an  
> application.
[...]
> As soon as I type next on one of the setbuf() functions gdb steps  
> directly to the assembly code of setbuf not over it as I would like to
> have it...

I suspect that this is because we fail to detect that the caller of
setbuf if "function", most likely because the setbuf function does
not setup a frame. You can confirm this by requesting a backtrace
after you landed inside "setbuf".  If your "function" has disappeared
from the backtrace, you know.

As I explained back then, this patch is a compromise: You'll win some,
and lose some. But you can change a bit the compromise by deciding that
certain routines should be excluded from the heuristics. For instance,
you can expand i386_in_dll to not only check whether the PC is inside
a DLL, but also check the name of the function associated to that PC.
One possibility is to only match the name of the routines you know are
causing trouble. Another way it to exclude all frameless routines that
you know GDB can actually unwind from.

At AdaCore, we decided to stay away from that, because it's very hacky
and OS version dependent.

PS: It looks like I'll have to implement the same type of patch for
    x86_64-windows.

-- 
Joel


  reply	other threads:[~2009-03-17 13:19 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-17 11:58 Roland Schwingel
2009-03-17 13:19 ` Joel Brobecker [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-03-23 13:12 Roland Schwingel
2009-03-18  9:26 Roland Schwingel
2009-03-19 14:18 ` Joel Brobecker
2009-03-17 15:39 Roland Schwingel
2009-03-17 19:43 ` Joel Brobecker
2009-03-17 15:26 Roland Schwingel
2009-03-17 13:49 Roland Schwingel
2009-03-17 14:27 ` Pedro Alves
2009-03-17 15:08 ` Joel Brobecker
2007-09-29 22:01 Gordon Prieur
2007-09-30  3:00 ` Daniel Jacobowitz
2007-09-30 18:13 ` Eli Zaretskii
2007-10-01 14:03   ` Gordon Prieur
2007-10-01 14:39     ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090317131949.GA32001@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=roland.schwingel@onevision.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox