[PATCH 0/4] Save target description in tfile.

Marcin Kościelnicki koriakin@0x04.net
Fri Feb 12 01:49:00 GMT 2016


On 11/02/16 18:36, Yao Qi wrote:
> Marcin Kościelnicki <koriakin@0x04.net> writes:
>
>> 1. target.xml is read from the target.
>> 2. Includes are processed, resulting in a single in-memory XML file
>>     containing all the data.
>> 3. The resulting file is stored in tfile header by prefixing every line
>>     with "tdesc ".  We may insert a spurious newline at the end of file
>>     with this encoding, but that won't matter for XML.
>> 4. When tfile is read, the XML is stored in an allocated buffer, and
>>     xfer for TARGET_OBJECT_AVAILABLE_FEATURES is implemented, reading
>>     from it.
>> 5. target_find_description is called to force reading it.
>
> The target description is a global state in trace file, so it doesn't
> work tracepoints have different target descriptions, for example in
> multi-inferior case, one is x86 and the other one is x86_64 (and arm vs
> aarch64 too), and we have tracepoints set in two processes.
>
> I know tracepoint doesn't support multi-inferior/multi-process, but we
> may support that in the future.  Since we are changing tracepoint file
> format, we'd better think about this a little bit.  Can we save multiple
> target descriptions in trace file, and associate the tracepoints to the
> right target description in trace file?
>
Well, that'd require rethinking the whole format - there's already the 
'R' line, which is also global and specifies register packet size, which 
is probably different for every target (it's effectively a very poor 
kind of tdesc).  There's also no way of assigning the tracepoints to 
inferiors, or for that matter to say what executable is running in what 
inferior (target tfile just picks the current one loaded in gdb).

In effect, we'd have to prefix every single line with the inferior id 
(or otherwise include it), and the result is probably no better than 
just bundling several tfile files eg. in a zip (I don't think we have 
support for merging trace buffers from several sources anyhow).



More information about the Gdb-patches mailing list