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

Michael Snyder
2010-05-10T23:28:02Z

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?