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

[Michael Snyder <msnyder@vmware.com>]

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?