From: asmwarrior <asmwarrior@gmail.com>
To: asmwarrior <asmwarrior@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: windows gdb.exe, setting breakpoints before debugging cause extremely slow loading
Date: Thu, 22 Jul 2010 00:34:00 -0000 [thread overview]
Message-ID: <4C47923A.9070102@gmail.com> (raw)
In-Reply-To: <4C46FCDD.2000704@gmail.com>
On 3:59, asmwarrior wrote:
> Hi, all, I'm a windows gdb user, I have used both official MinGW
> gdb.exe and gdb.exe build myself.
>
> I found that when I set a breakpoint before loading or after loading
> has much different result.
> I use GDB.exe under Codeblocks, here is the debugger log when I try to
> debug something:
> ----------------------------------------------------------------------------
>
> Situation works badly:
>
> I just set breakpoint before I start "run" the debugee
>
> >>>>>>cb_gdb:
> > break
> "E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp:471"
> No source file named
> E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp.
> Breakpoint 1
> ("E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp:471)
> pending.
> >>>>>>cb_gdb:
> > run
>
> Now, it will take about 1 and a half minutes to start the debugee.
>
> ----------------------------------------------------------------------------
>
> But If I do *not* set any breakpoint before running, then ,the loading
> stage is quite fast(about 10 second), after that I can still set
> breakpoint and all the breakpoint works fine.
>
> Not only me find the problem, see the message posted in Codeblocks
> forum by One of Codeblocks developers Pecan:
> http://forums.codeblocks.org/index.php/topic,12951.msg87332.html#msg87332
>
> Does this a gdb bug?
>
> Thanks
>
> asmwarrior(ollydbg from codeblocks forum)
>
I personally think there is something wrong with "pending breakpoint"
when we load a shared dll library.
As my initial guess, When after loading some new shared libraries, gdb
need to check if the pending breakpoint can be set to the new libraries.
if Yes, then the these breakpoint can translated from "pending
breakpoint" to "real breakpoint".
return to my problem:
I guess there are some recursive search algorithm for pending
breakpoints after some new shared library debug information is loaded.
Can some one give me a direction that how does gdb treat with "pending
breakpoint" after loading some new shared libraries?
I have read the gdb source "breakpoint.c" there:
struct breakpoint *b
if b->loc is NULL, which means it is a pending breakpoint. So, where and
when will be this pointer member filled.
Thanks
asmwarrior
prev parent reply other threads:[~2010-07-22 0:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-21 13:57 asmwarrior
2010-07-22 0:34 ` asmwarrior [this message]
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=4C47923A.9070102@gmail.com \
--to=asmwarrior@gmail.com \
--cc=gdb@sourceware.org \
/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