This is the mail archive of the gdb-patches@sourceware.org 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]

RFC: new struct breakpoint component cond_language...


Hello,

As mentioned in an earlier email, I think that there are a few areas
in the current GDB behavior where the ideal behavior still needs to
be defined.  This is only relevant when debugging a multi-language
application.

So, to recap, the situation is the following: the current language is
"auto; currently c", and the user is inserting a breakpoint inside
some code that is Ada. So far, there seems to be a consensus that,
because the language mode is "auto", the breakpoint should be parsed
using Ada, rather than the current language (C).

Breakpoints already store the language that was used to create it.
This is the language that was used to parse the linespec.  When
creating a breakpoint from the command-line, it is always the
current_language, even when the language mode is auto.

So, taking both of these elements into account, I deduce that
breakpoints should also store a condition_language which should be
used in order to parse our condition, because it can be different
from the breakpoint language.

Expression carry the language that was used to create them, but
breakpoint conditions are not always immediately parsed - so some
breakpoints have a condition, but no corresponding condition
expression. So, I don't think we have any choice but to add a new
language field. I propose cond_language (the expression is called
"cond" and the litteral expression is called "cond_string").

Once we have this condition language, we can move the logic for
computing the condition language out of parse.c into breakpoint.c,
and use that field as a parameter when calling the parse routines
(this is dependent on
http://www.sourceware.org/ml/gdb-patches/2010-05/msg00236.html).

Sounds reasonable?

-- 
Joel


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