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

Simon Marchi via Gdb
2021-03-22T15:06:37Z

On 2021-03-22 10:53 a.m., Zied Guermazi wrote:
> 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.

The mapping symbols (if I understand correctly, $a and $t) are not in
the DWARF, they are ELF symbols. However, is it possible to record
execution when you don't event have and ELF file, just connect to a
target and record it? In that case, you might not even have ELF
symbols, so that's perhaps not sufficient.

There's also the case of self-modifying or JIT-ed code, where mapping
symbols from the ELF file are of no use. So I think it's better to just
always rely on CPSR.

> - use additional bits in btrace_insn_flag
>
> advantages: no memory overhead
>
> disadvantages: encode architecture specific info.

Since we already pay the cost of having space for flags, we might as
well use it. It sounds like a good solution for your current problem,
since there is very little info you need to keep (the execution mode).
That doesn't solve the problem for when you'll want to record data
though, a more flexible solution will be needed.

> 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

Is that 0x06 really what you want, it's a OR of arm and thumb2?

Simon