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

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

[Zied Guermazi]

hi,

is it possible to know, at compile time, whether we are compiling gdb 
for an armv7 target ( e.g arm-linux, arm-none-eabi ... ) or not? for 
example a define that gets propagated to source/header files.

Kind Regards

Zied Guermazi

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

[Simon Marchi]

On 2021-03-21 10:21 p.m., Zied Guermazi wrote:
> hi,
> 
> is it possible to know, at compile time, whether we are compiling gdb for an armv7 target ( e.g arm-linux, arm-none-eabi ... ) or not? for example a define that gets propagated to source/header files.
> 
> Kind Regards
> 
> Zied Guermazi
> 
> 

Not really, since one GDB can be configured for multiple target
architectures (you can include all possible target architectures with
--enable-targets=all when running configure).

What are you trying to achieve?

Simon

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

[Zied Guermazi]

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?


On 22.03.21 03:26, Simon Marchi wrote:
>
> On 2021-03-21 10:21 p.m., Zied Guermazi wrote:
>> hi,
>>
>> is it possible to know, at compile time, whether we are compiling gdb for an armv7 target ( e.g arm-linux, arm-none-eabi ... ) or not? for example a define that gets propagated to source/header files.
>>
>> Kind Regards
>>
>> Zied Guermazi
>>
>>
> Not really, since one GDB can be configured for multiple target
> architectures (you can include all possible target architectures with
> --enable-targets=all when running configure).
>
> What are you trying to achieve?
>
> 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.

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

[Simon Marchi]

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

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

[Zied Guermazi]

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.

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

[Metzger, Markus T]

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

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

[Zied Guermazi]

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.

- Compression methods (BTRACE_INSN_AUX, BTRACE_INSN_ISA)

     advantage: less memory overhead

     disadvantages: requires traveling the vector to find the register 
value and match it with the instruction

- use additional bits in btrace_insn_flag

     advantages: no memory overhead

     disadvantages: encode architecture specific info.


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


Kind Regards

Zied Guermazi


On 22.03.21 09:29, Metzger, Markus T wrote:
> 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

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

[Simon Marchi]

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

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

[Zied Guermazi]

hi

On 22.03.21 16:06, Simon Marchi wrote:
>
> 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?
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.
>
> Simon
/Zied

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