[PATCH 2/2] Compute traceframe usuage per tracepoint on demand.
Pedro Alves
palves@redhat.com
Mon Jan 7 15:56:00 GMT 2013
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
More information about the Gdb-patches
mailing list