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

Simon Marchi via Gdb
2021-03-22T03:40:22Z

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