From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 73BE53858D20 for ; Mon, 11 Mar 2024 11:36:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 73BE53858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 73BE53858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::629 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710157009; cv=none; b=IF2JQuDrFUqzrDi+IuDR/OD+2oCoOippoyHCdfJEeQauUHl08TRqkTX/MS6zN3DsrPQ0maxErZ928Imi9anKRLIcl8HXgmiW2VrC6AlNZH7nkexzV2UWQwluccmim4bLgATlXyqbvWXpfsz5H03zeyPMpFLhg5/go3Uk9oOlJyM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710157009; c=relaxed/simple; bh=4ooTHBYCSsTuIZcSPIubIn66Aa9/WYUXNDU07KXCwKU=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=UEHFTeFj5fXy5lF3/uHkPv9avx4gzBa0bjp7mDhfh2eh9S9zeSO6EOEBW+BszlvqLFLaIWGmW6IZK+ZRRt3x9YHCaKjj/463r1dBoIbkE+EOCtVHjtdHg9P2spmBFpaRSrIqZdII2L58NrwisZqOlt3lSrgvQaYLyYf9RS1YUXM= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a460185d1a7so222475166b.0 for ; Mon, 11 Mar 2024 04:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710157004; x=1710761804; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9BQyBit7oxPa6sdptTdhYW69xaCCoHs9Z6ZAioCa7Rs=; b=P6cdr9gv+UJr8rzuudNyx56BooVTLXzhYWCMbBcbpFP9R6q84T8TdELYVn+dVRltCN 0s1RnvQ2uZtbe8mY4K5pjrsP4PurQ8eGZR8Fjcid4JAFOi7pw+yxKauvOOjIwmzX4Aro DqwccVqVcoBkZD+lI4Snu7Zd8qFU/W1L4tg1WhcMRoctIP2+G9zseqN4tfa0dwbP03hq QpkT2RxkKtDlXYfXn2g1D7GOLAb1q12LWXr7imUjb5H4v/9VRoVYpDuOffaK0IQLBccN QgGEXSAZcSZGqN99iHS1FeEInRCP8iEpX7AuC7jU4k73JlE8px/UVGN/8R5ZsNui78kj cp9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710157004; x=1710761804; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9BQyBit7oxPa6sdptTdhYW69xaCCoHs9Z6ZAioCa7Rs=; b=jVYCzufLsM/5aEYnQDzJ1Qg+Oz25FGj3n3YQEIv1p+w4FfH9aodX0Ikd9DT13H44U9 UIqWMyOmnxwP2D95GzqlAg1ghReL4snFTDwTSqty/stRr/aac49QXAEmeyIiz6dnbe3H iLvmaFivEfCWcYnYHlTdLHSo+BHUzubtGaHt2f+XE9dwqrrBc4HCVfKnn9IlzttOgxDi KZyoWqoqtf8iPw6RdexyqpRHBjgq/zfak09hs4LOEfcUrv5G2R906DYZtIZPv54cL67l un4sjQyvXpfLsyvp38g9QVqX/NkUEqI2XwU2czoMIJZgMVrc2HFQLKndwwhtoUYJ/vfD IDlg== X-Gm-Message-State: AOJu0Yz6jWBSRyXeGiWFfZN1jcOokrK5TDkvc0t7GidehHRJwk3hsPnG J/oBFwfFXW0r8JQ+GcacZ34qVV0IHSgshzij4cVu36UR+tPdzcPmdr+vyXr9BzblqjejikTXI6F 1bQOGme6Rwi89jASbekxh10M0cK0= X-Google-Smtp-Source: AGHT+IG/W9z9D8mJj5bwqWPTFVnLJZXwRoO9j8Fvze85GkWmJh3yaEZr6q8h/P+hx3Fm+Ck9/5nLdGAS3HB0s9o6q10= X-Received: by 2002:a17:907:8744:b0:a46:2623:7525 with SMTP id qo4-20020a170907874400b00a4626237525mr2059188ejc.20.1710157003768; Mon, 11 Mar 2024 04:36:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shiro B Date: Mon, 11 Mar 2024 19:36:32 +0800 Message-ID: Subject: Re: Inquiry on AArch64 Simulator in GDB To: Andrew Dinn Cc: gdb@sourceware.org Content-Type: multipart/alternative; boundary="000000000000b84bf8061360f496" X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --000000000000b84bf8061360f496 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wanted to extend a sincere apology for mistakenly spelling your name incorrectly in my previous email. Shiro B =E4=BA=8E2024=E5=B9=B43=E6=9C=8811=E6=97=A5= =E5=91=A8=E4=B8=80 19:31=E5=86=99=E9=81=93=EF=BC=9A > Hi Andrew Binn, > > Thank you very much for your comprehensive response regarding the AArch64 > simulator. A userspace simulator is all I need, and this seems will be > very helpful to my project. > > During my exploration and testing, I believe I may have stumbled upon a > bug related to the UMINV instruction, as detailed in the ARM documentatio= n ( > https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructi= ons/UMINV--Unsigned-Minimum-across-Vector-?lang=3Den). > According to ARM's specifications, it appears that after comparing and > identifying the minimum value in a vector, the result should be stored in= a > floating-point/vector register, rather than a general-purpose register. T= he > relevant code can be found here: > https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dblob;f=3Dsim/aarch64= /simulator.c;h=3D1dde0b478c3d1bc9b88a63dd703225c9a2bb3703;hb=3DHEAD#l4482 > > Admittedly, my familiarity with ARM64, especially SIMD instructions, is > not very extensive. However, through testing, I've noticed that the > simulation's outcome for this instruction indeed differs from that of an > actual CPU. > > Could you please take a look at this observation and provide your > insights? I'm keen to understand whether this discrepancy could be > attributed to my limited understanding or if it indeed points to a > potential oversight in the simulator's implementation of the UMINV > instruction (and also UMAXV, SMINV, SMAXV). > > Thank you once again for your invaluable feedback and for considering my > query. I look forward to your expert opinion on this matter. > > Best regards > > > Andrew Dinn =E4=BA=8E2024=E5=B9=B43=E6=9C=8811=E6=97= =A5=E5=91=A8=E4=B8=80 18:41=E5=86=99=E9=81=93=EF=BC=9A > >> 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 ke= en >> > 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 n= ot >> > 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 a= nd >> > 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 >> > >> >> --000000000000b84bf8061360f496--