This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 2/2] Compute traceframe usuage per tracepoint on demand.
- From: Pedro Alves <palves at redhat dot com>
- To: Yao Qi <yao at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 07 Jan 2013 15:56:45 +0000
- Subject: Re: [PATCH 2/2] Compute traceframe usuage per tracepoint on demand.
- References: <1355276266-23163-1-git-send-email-yao@codesourcery.com> <1355276266-23163-3-git-send-email-yao@codesourcery.com> <50CEE3CF.8070904@codesourcery.com> <50EAEC28.9040704@redhat.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