Re: [PATCH 2/2] Compute traceframe usuage per tracepoint on demand.

[Pedro Alves <palves at redhat dot com>]

On 01/07/2013 03:39 PM, Pedro Alves wrote:
> On 12/17/2012 09:20 AM, Yao Qi wrote:
>> It is incorrect for tracepoint with multiple locations, because multiple
>> tracepoints in GDBserver have the same tracepoint number, and
>> each tracepoint has its own traceframe usage.

>> On 12/12/2012 09:37 AM, Yao Qi wrote:
>>> Then, I thought that we may use pointer to
>>> 'struct tracepoint' instead of tracepoint num in 'struct traceframe',
>>> but comments of 'struct traceframe' tell me that I shouldn't do this,
>>> "This object should be as small as possible".  If we don't mind
>>> increasing 2 bytes (on 32-bit target) for each 'struct traceframe',
>>
>> Looks we have to go this way, in order to get the correct traceframe usage of each tracepoint in GDBserver.
> 
> To avoid the size penalty on 64-bit, another option would be
> for gdbserver to maintain an internal tracepoint number, unique
> for each location, and for traceframes to record that instead
> of gdb tracepoint number.

Actually, I just remembered that "tfind tracepoint" is
broken for multiple locations.  Notice:

(gdb) tfind tracepoint 1.1
Sending packet: $QTFrame:tdp:1#7d...Packet received: F-1
...
(gdb) tfind tracepoint 1.2
Sending packet: $QTFrame:tdp:1#7d...Packet received: F-1
...

"QTFrame:tdp:" only sends the tracepoint number, not the
address, so the remote side can't distinguish locations...

Doesn't strictly speak against doing the accounting in
add_traceframe_block, but, in order to fix that we will need
to change struct traceframe anyhow.

> 
> Did you try the other option of accounting for usage in
> add_traceframe_block?  I suspect it may be simple and not
> add much more than a few instructions.
> 
>> I'll post a new patch again.
> 
> I may have missed it.  Have you posted it?

-- 
Pedro Alves