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

Zied Guermazi
2021-03-22T14:54:17Z

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