From: Paul Koning <pkoning@equallogic.com>
To: brobecker@gnat.com
Cc: jimb@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [RFA] parse and eval breakpoint conditions with correct language
Date: Thu, 11 Sep 2003 18:42:00 -0000 [thread overview]
Message-ID: <16224.49692.542476.869174@gargle.gargle.HOWL> (raw)
In-Reply-To: <20030911180920.GD945@gnat.com>
>>>>> "Joel" == Joel Brobecker <brobecker@gnat.com> writes:
Joel> Groumf! Our nightly regression test showed a small regression
Joel> which does not appear on my machine. We have an all-Ada program
Joel> which defines a function named Func1, and here is what the test
Joel> does:
Joel> (gdb) break *Func1'Address (gdb) run
Joel> (The first command says place a breakpoint at the first
Joel> instruction of Func1. What's important is that we use the
Joel> "break *address" syntax).
Joel> The first break command correctly uses the ada language to
Joel> parse the expression (Func1'Address). The fun starts after
Joel> "run":
Joel> (gdb) run Starting program: /[...]/main Error in re-setting
Joel> breakpoint 1: No symbol "Func1" in current context.
Joel> Program exited normally. Current language: auto; currently c
Joel> What happens is that the inferior is stopped twice during the
Joel> startup phase after notifications about new shared libraries
Joel> being loaded. GDB then re-parses all breakpoint expressions
Joel> and re-inserts them. During this phase, the block given to
Joel> parse_exp_1 is NULL, so GDB uses the current block (ie the
Joel> block corresponding to the current frame) to determine the
Joel> language. Since the current frame has nothing to do with the
Joel> breakpoint, we are sometimes unlucky enough to use the wrong
Joel> language to reparse the breakpoint. That's what happens to the
Joel> test above, and is dependent on how the target system is setup.
Warning, the following is not based on a really deep understanding of
how gdb internals work...
Could the same sort of trouble occur when evaluating watchpoint
expressions? The parsing should be done according to the language in
effect when the watchpoint is defined (either explicit, or from the
current block language given this patch) -- not the one that happens
to be in effect when gdb is checking for watch hits during execution.
Is that a non-issue or could you run into the same sort of problem as
what Joel reported?
paul
next prev parent reply other threads:[~2003-09-11 18:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-10 1:54 Joel Brobecker
2003-09-10 17:31 ` Jim Blandy
2003-09-11 18:09 ` Joel Brobecker
2003-09-11 18:42 ` Paul Koning [this message]
2003-09-11 19:30 ` Joel Brobecker
2003-09-12 1:33 ` Andrew Cagney
2003-09-12 5:46 ` Joel Brobecker
2003-09-15 3:09 ` Jim Blandy
2003-09-15 19:00 ` Joel Brobecker
2003-09-11 19:20 ` Andrew Cagney
2003-09-11 19:32 ` Joel Brobecker
2003-09-11 19:54 ` Daniel Jacobowitz
2003-09-11 22:20 ` Jim Blandy
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=16224.49692.542476.869174@gargle.gargle.HOWL \
--to=pkoning@equallogic.com \
--cc=brobecker@gnat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@redhat.com \
/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