This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] parse and eval breakpoint conditions with correct language
>>>>> "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