Re: flag to know that we are compiling GDB for an arm target

[Zied Guermazi <zied.guermazi@trande.de>]

hi

I will put different solutions together with advantages disadvantages

- add a vector of registers to each instruction

     advantage: close to the logical model: a function is a set of 
instructions, an instruction changes a set of registers.

     disadvantage: consumes much memory (3 additional pointers, for an 
empty vector)

- extend the instruction class

     advantage: targets not needing the registers are not heavily impacted

     disadvantages: still an additional pointer is added

- Infer the ISA mode from mapping symbols

     advantages: no overhead in the data structure

     disadvantages: dwarf info are not always available.

- Compression methods (BTRACE_INSN_AUX, BTRACE_INSN_ISA)

     advantage: less memory overhead

     disadvantages: requires traveling the vector to find the register 
value and match it with the instruction

- use additional bits in btrace_insn_flag

     advantages: no memory overhead

     disadvantages: encode architecture specific info.


I will go for using additional bits (bit 1, bit 2 and bit 3) in 
btrace_insn_flag to encode the isa for armv7  as folowing

ocsd_isa_arm as  0x02

ocsd_isa_thumb2 as  0x04

ocsd_isa_tee as  0x06

ocsd_isa_jazelle as 0x08


Kind Regards

Zied Guermazi


On 22.03.21 09:29, Metzger, Markus T wrote:
> With class hierarchies, you'd end up allocating each object independently
> and adding a pointer to the overall cost.
>
> For calculating the target IP of any given recorded instruction, we'd just
> look at the next instruction in the trace, wouldn't we?
>
> Can we infer the ISA mode from mapping symbols?  Or we could annotate
> changes to the ISA mode in the trace.  Some time ago, Felix had proposed
> a new insn class BTRACE_INSN_AUX; instead of storing the PC, it would store
> an index into a string vector.  This could be generalized to store an index
> into some tagged auxiliary object vector.
>
> Or, more simply, add a new insn class BTRACE_INSN_ISA that stores an
> arch-specific ISA enum instead of the PC.
>
> We could further compress struct btrace_insn to store the iclass in 8b
> to make room for another 16b field.
>
> Or reserve some flags encoding space for arch-specific information
> like the ISA mode.
>
> Regards,
> Markus.
>
>> -----Original Message-----
>> From: Gdb <gdb-bounces@sourceware.org> On Behalf Of Zied Guermazi
>> Sent: Montag, 22. März 2021 05:00
>> To: Simon Marchi <simon.marchi@polymtl.ca>; gdb@sourceware.org
>> Subject: Re: flag to know that we are compiling GDB for an arm target
>>
>> Thanks simon,
>>
>> it is elegant to solve it during instantiation.
>>
>> /Zied
>>
>> On 22.03.21 04:40, Simon Marchi wrote:
>>> On 2021-03-21 10:46 p.m., Zied Guermazi wrote:
>>>> hi Simon,
>>>>
>>>> I am extending btrace for armv7 and armv8. In armv7, due to some limitations
>> in the debug HW, GDB requires the current program status register CPSR to know
>> in which ISA mode it is, so that it can set breakpoints properly and calculate the
>> "landing" address for next, nexti, step commands
>>>> When we use the traces in replay mode we need to know and provide the cpsr
>> at any instruction.
>>>> there is a data structure (btrace_insn in btrace.h) that was extended to holds
>> cpsr register and possibly other registers (paving the way for data tracing).
>> currently it is a vector of registers, that will be (currently) empty of all
>> architectures except ARMv7 (see the struct below). We have typically thousands
>> to millions instances of this structure.
>>>>
>>>> struct btrace_insn
>>>> {
>>>>     /* The address of this instruction.  */
>>>>     CORE_ADDR pc;
>>>>
>>>>     /* The size of this instruction in bytes.  */
>>>>     gdb_byte size;
>>>>
>>>>    /* A vector of registers.  */
>>>>     std::vector<record_btrace_reg_entry> registers;
>>>>
>>>>     /* The instruction class of this instruction.  */
>>>>     enum btrace_insn_class iclass;
>>>>
>>>>     /* A bit vector of BTRACE_INSN_FLAGS.  */
>>>>     btrace_insn_flags flags;
>>>> };
>>>>
>>>>
>>>> the empty vector was judged to be a big overhead for Intel PT for example. I
>> am looking for a way to inhibit it, when we are not building GDB for armv7.
>>>> do you have any proposal for solving such a situation?
>>> Bearing in mind that I don't know this problem in detail, it sounds like
>>> if making btrace_insn bigger isn't an option, then you'll want to have a
>>> specific subclass for ARM (btrace_insn_arm), that adds the extra data.
>>> However, since btrace_insn is used in a vector of objects in
>>> btrace_function, then maybe you'll also need a specific
>>> btrace_function_arm (btrace_function would keep using a vector of
>>> btrace_insn, btrace_function_arm would use a vector of btrace_insn_arm.
>>> Similarly, you might need a btrace_thread_info_arm, because
>>> btrace_thread_info contains a vector of btrace_function.  But then it's
>>> not clear how that would interface with struct thread_info, to be able
>>> to choose the right kind at runtime.  I suppose that would involve a
>>> class hierarchy with some virtual functions, where on Intel
>>> btrace_thread_info is instantiated, and on ARM btrace_thread_info_arm is
>>> instantiated.  Ideally, all without introducing too much virtual
>>> function calls on the fast path.
>>>
>>> Simon
>> --
>>
>> *Zied Guermazi*
>> founder
>>
>> Trande UG
>> Leuschnerstraße 2
>> 69469 Weinheim/Germany
>>
>> Mobile: +491722645127
>> mailto:zied.guermazi@trande.de
>>
>> *Trande UG*
>> Leuschnerstraße 2, D-69469 Weinheim; Telefon: +491722645127
>> Sitz der Gesellschaft: Weinheim- Registergericht: AG Mannheim HRB 736209
>> - Geschäftsführung: Zied Guermazi
>>
>> *Confidentiality Note*
>> This message is intended only for the use of the named recipient(s) and
>> may contain confidential and/or privileged information. If you are not
>> the intended recipient, please contact the sender and delete the
>> message. Any unauthorized use of the information contained in this
>> message is prohibited.
>>
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928