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

[Metzger, Markus T]

>>> 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

There is no real impact to those not using the functionality.


>>>
>>>      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.

That could be an additional insn class to supply register data.  We can
look into that when we're actually going to implement that.


>>> 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?
>that is not a big issue, I can mask the flags value with 0x0E and then
>compare against the value of the isa (the 3bits are handled as one
>flag). it will be one switch case.

Let's put the arch specific flags to one end of the value, e.g. bits 31:24.
We can grow downwards if we need more bits.

Wouldn't we want a simple enum for the ISA mode?

Regards,
Markus.
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