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

["Metzger, Markus T" <markus.t.metzger@intel.com>]

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