RFC: new struct breakpoint component cond_language...

RFC: new struct breakpoint component cond_language...

[Joel Brobecker]

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

Re: RFC: new struct breakpoint component cond_language...

[Stan Shebs]

Joel Brobecker wrote:
> 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.
>   

Tracepoints add an extra wrinkle to this concept - when connecting to a 
target that is currently running a trace, tracepoint conditions can be 
uploaded from the target, and in their original source form, and so have 
to be reparsed.  So to make this work in the multi-language case, it 
seems like the tracepoint download should include the language somehow.

But then I wonder - when uploading a tracepoint, we receive both the 
computed address and the source form of that address, so in theory we 
can always deduce the correct language by working back from the 
tracepoint address.  And if that's true, then wouldn't the language of 
the condition be expected to be the same as the language of the 
location?  Are tracepoints then just a special case in which the 
condition language does not need to be recorded?

Stan

Re: RFC: new struct breakpoint component cond_language...

[Michael Snyder]

Stan Shebs wrote:
> Joel Brobecker wrote:
>> 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.
>>   
> 
> Tracepoints add an extra wrinkle to this concept - when connecting to a 
> target that is currently running a trace, tracepoint conditions can be 
> uploaded from the target, and in their original source form, and so have 
> to be reparsed.  So to make this work in the multi-language case, it 
> seems like the tracepoint download should include the language somehow.
> 
> But then I wonder - when uploading a tracepoint, we receive both the 
> computed address and the source form of that address, so in theory we 
> can always deduce the correct language by working back from the 
> tracepoint address.  And if that's true, then wouldn't the language of 
> the condition be expected to be the same as the language of the 
> location?  Are tracepoints then just a special case in which the 
> condition language does not need to be recorded?

Hmmm... doesn't the breakpoint struct already record (as you mention)
the "source form" (ie. a string) of the address?  In which case, could
we not always derive the source language?

Oh, well, what if it's just a function name?  Is that enough?

Re: RFC: new struct breakpoint component cond_language...

[Joel Brobecker]

> Tracepoints add an extra wrinkle to this concept - when connecting
> to a target that is currently running a trace, tracepoint conditions
> can be uploaded from the target, and in their original source form,
> and so have to be reparsed.  So to make this work in the
> multi-language case, it seems like the tracepoint download should
> include the language somehow.

I am not very familiar with tracepoints, but I think I see what
is happening (disconnecting GDB from the target?). It seems to me
that, indeed, tracepoints need to download and upload the condition
language as well. In particular:

> But then I wonder - when uploading a tracepoint, we receive both the
> computed address and the source form of that address, so in theory
> we can always deduce the correct language by working back from the
> tracepoint address.

I do not think so; At the time when the user declares the tracepoint
condition, I am assuming that we check the language mode, and that if
it is not auto, then we use the current_language as the condition
language, regardless of the language of the source. As a result,
the condition language cannot be determined from the tracepoint address.

-- 
Joel

Re: RFC: new struct breakpoint component cond_language...

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

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

BTW, this is PR 9113, which I filed some years ago and then forgot :)

In that case, I was explicitly setting a c++-language condition on a
java breakpoint.  Then gdb reparsed the condition using java rather than
c++.

Tom