public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Andrew Dinn <adinn@redhat.com>
To: Shiro B <laodabaicai@gmail.com>, gdb@sourceware.org
Subject: Re: Inquiry on AArch64 Simulator in GDB
Date: Mon, 11 Mar 2024 10:41:10 +0000	[thread overview]
Message-ID: <f357b3e9-faa8-00eb-6f35-2645a8a20a49@redhat.com> (raw)
In-Reply-To: <CAC3JbXcAc0jZhoONpBFwLE8hYhrKo=MrD7_E=qS2qzi+BD9xEQ@mail.gmail.com>

Hi Shiro B,

I believe a lot of the simulator code is based on work that was 
originally done by me when we used the simulator to port OpenJDK to run 
on AArch64. It  was adapted by Phil Muldoon for use in gdb but a lot of 
the code still looks recognisable to me. I cannot properly answer all 
your questions but I can provide some background that might help.

The original simulator was built to allow execution of AArch64 code 
generated by the OpenJDK JIT compiler before any hardware was available. 
So, it was based on a pre-release copy of the ARM ARM (ARM Architecture 
Reference Manual) and it only catered for the subset of the original 
instruction set that might be used during operation of conventional 
userspace application.

It did cover all the standard GPR- and FPR-based instructions. I think 
it may also have supported a small subset of Neon vector instructions. 
It did not cater for instructions, and associated registers, that would 
only be needed during system bootstrap (e.g. only a few move to/from 
system register options are supported). It also does not correctly 
implement the AArch64 memory model - the original sim provided a 
per-thread memory cache to simulate a local memory buffer but it was 
nothing like the real thing. So, memory reads and writes operate using 
host memory semantics (e.g. TSO on x86).

I am not certain but I think the version currently in the gdb tree has 
been updated to allow for extra Neon vector instructions that were not 
in the original decode/execute tree. I don't think it has been updated 
to cater for the few recent additions to the instruction set, nor to 
allow for SVE. I cannot say exactly what is implemented now. It looks 
like it still  only really addresses userspace programs.

I can tell you how to find out fairly quickly and easily what parts of 
the instruction set are implemented. Start by looking at routine 
*aarch64_decode_and_execute* in file simulator.c. It gets called from 
*aarch64_step/run* to decode and execute a single instruction. The 
decode does a recursive descent through groups and subgroups of 
instructions, based on a hierarchy of discriminant bits.

So, the top level dispatch is on bits [28..25]. Within each top level 
group different bit patterns are used to do the next dispatch and so on. 
For example, instructions in top level groups GROUP_DPIMM_1000 and 
GROUP_DPIMM_1001 are discriminated by looking at bits [25..23] (n.b. it 
may be obvious but just to spell it out -- the numbers in those top 
level enum tags indicate what value bits [28..25] have).

The logic of this recursive dispatch is implemented by the functions in 
simulator.c with names in the format dexAAAAAA (A is an Alphabetic 
character). The corresponding top level and nested bit patterns they 
rely on are defined by enums with names in the format DispatchAAAA in 
file decode.h. The function and enum names should match up.

So, if you follow through each of these functions and associated nested 
bit patterns you can find all the instructions in a given family and 
subfamily that are implemented by the sim. Likewise if you want to see 
if an instruction is implemented then you need to read off the bit 
patterns from the top level on downwards to place it in a family and 
subfamilies. When you reach the bottom of the dexAAAA tree you will find 
out whether it is catered for or treated as an unknown instruction.

Sorry that does not answer all your questions. Hopefully the comments in 
the code will still help you identify what is supported and how. If they 
are not enough then I may be able to answer specific queries. However, 
since I wrote the original code 12 years ago I'm not sure I will be able 
to remember all the details.

regards,


Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill


On 11/03/2024 03:34, Shiro B via Gdb wrote:
> Dear GDB Mailing List,
> 
> I hope this message finds you well. I am reaching out to express my keen
> interest in the AArch64 simulator included within GDB.  (the one in
> [binutils-gdb.git]/sim/aarch64/)
> 
> Despite my efforts, I have encountered difficulty in locating detailed
> documentation or introductions that shed light on several aspects of this
> simulator.
> 
> My inquiries primarily revolve around its capabilities and limitations with
> regard to the ARM64 instruction set.
> 
> Specifically, I am eager to understand:
> 
> 1. Which ARM64 instructions are supported by the AArch64 simulator?
> 2. Which version of the ARM standard does it adhere to? like v8 v8.1...?
> 3. Are there any extensions to the instruction set that the simulator
> supports? like pauth, crypto, neon, etc
> 3. Could you provide details on any instructions that are explicitly not
> supported?
> 4. Is the simulator limited to user-mode instructions, or does it offer
> broader functionality?
> 5. Lastly, I would appreciate insights into any known issues, limitations,
> or scenarios where the AArch64 simulator may not be suitable for use.
> 
> I believe understanding these aspects will greatly enhance my ability to
> utilize the AArch64 simulator effectively within GDB for development and
> testing purposes. Your guidance and any available documentation or
> resources on this topic would be immensely valuable.
> 
> Thank you for your time and assistance. I look forward to your response and
> any information you can share.
> 
> Best regards
> 


  reply	other threads:[~2024-03-11 10:41 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-11  3:34 Shiro B
2024-03-11 10:41 ` Andrew Dinn [this message]
2024-03-11 11:31   ` Shiro B
2024-03-11 11:36     ` Shiro B
2024-03-11 15:24     ` Andrew Dinn

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=f357b3e9-faa8-00eb-6f35-2645a8a20a49@redhat.com \
    --to=adinn@redhat.com \
    --cc=gdb@sourceware.org \
    --cc=laodabaicai@gmail.com \
    /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).