This is the mail archive of the gdb-patches@sources.redhat.com 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: [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



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