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

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

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.