public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Zied Guermazi <zied.guermazi@trande.de>
To: Simon Marchi <simon.marchi@polymtl.ca>,
	"Metzger, Markus T" <markus.t.metzger@intel.com>,
	"gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: flag to know that we are compiling GDB for an arm target
Date: Mon, 22 Mar 2021 16:13:21 +0100	[thread overview]
Message-ID: <4e17a72a-76bb-8f75-c85c-ee6cc5705bd9@trande.de> (raw)
In-Reply-To: <8c00ecf0-ca44-0729-b576-8347078dc324@polymtl.ca>

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

  reply	other threads:[~2021-03-22 15:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22  2:21 Zied Guermazi
2021-03-22  2:26 ` Simon Marchi
2021-03-22  2:46   ` Zied Guermazi
2021-03-22  3:40     ` Simon Marchi
2021-03-22  3:59       ` Zied Guermazi
2021-03-22  8:29         ` Metzger, Markus T
2021-03-22 14:53           ` Zied Guermazi
2021-03-22 15:06             ` Simon Marchi
2021-03-22 15:13               ` Zied Guermazi [this message]
2021-03-22 15:22                 ` Metzger, Markus T

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4e17a72a-76bb-8f75-c85c-ee6cc5705bd9@trande.de \
    --to=zied.guermazi@trande.de \
    --cc=gdb@sourceware.org \
    --cc=markus.t.metzger@intel.com \
    --cc=simon.marchi@polymtl.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).