Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: RFC: new struct breakpoint component cond_language...
Date: Mon, 10 May 2010 21:54:00 -0000	[thread overview]
Message-ID: <20100510215421.GJ2957@adacore.com> (raw)

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


             reply	other threads:[~2010-05-10 21:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10 21:54 Joel Brobecker [this message]
2010-05-10 23:25 ` Stan Shebs
2010-05-10 23:28   ` Michael Snyder
2010-05-11  7:46   ` Joel Brobecker
2010-05-17 15:49 ` Tom Tromey

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=20100510215421.GJ2957@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@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