* Inquiry on AArch64 Simulator in GDB @ 2024-03-11 3:34 Shiro B 2024-03-11 10:41 ` Andrew Dinn 0 siblings, 1 reply; 5+ messages in thread From: Shiro B @ 2024-03-11 3:34 UTC (permalink / raw) To: gdb [-- Attachment #1: Type: text/plain, Size: 1475 bytes --] 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Inquiry on AArch64 Simulator in GDB 2024-03-11 3:34 Inquiry on AArch64 Simulator in GDB Shiro B @ 2024-03-11 10:41 ` Andrew Dinn 2024-03-11 11:31 ` Shiro B 0 siblings, 1 reply; 5+ messages in thread From: Andrew Dinn @ 2024-03-11 10:41 UTC (permalink / raw) To: Shiro B, gdb 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Inquiry on AArch64 Simulator in GDB 2024-03-11 10:41 ` Andrew Dinn @ 2024-03-11 11:31 ` Shiro B 2024-03-11 11:36 ` Shiro B 2024-03-11 15:24 ` Andrew Dinn 0 siblings, 2 replies; 5+ messages in thread From: Shiro B @ 2024-03-11 11:31 UTC (permalink / raw) To: Andrew Dinn; +Cc: gdb [-- Attachment #1: Type: text/plain, Size: 7483 bytes --] 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 documentation ( https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/UMINV--Unsigned-Minimum-across-Vector-?lang=en). 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. The relevant code can be found here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=sim/aarch64/simulator.c;h=1dde0b478c3d1bc9b88a63dd703225c9a2bb3703;hb=HEAD#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 <adinn@redhat.com> 于2024年3月11日周一 18:41写道: > 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 > > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Inquiry on AArch64 Simulator in GDB 2024-03-11 11:31 ` Shiro B @ 2024-03-11 11:36 ` Shiro B 2024-03-11 15:24 ` Andrew Dinn 1 sibling, 0 replies; 5+ messages in thread From: Shiro B @ 2024-03-11 11:36 UTC (permalink / raw) To: Andrew Dinn; +Cc: gdb [-- Attachment #1: Type: text/plain, Size: 7851 bytes --] I wanted to extend a sincere apology for mistakenly spelling your name incorrectly in my previous email. Shiro B <laodabaicai@gmail.com> 于2024年3月11日周一 19:31写道: > 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 documentation ( > https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/UMINV--Unsigned-Minimum-across-Vector-?lang=en). > 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. The > relevant code can be found here: > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=sim/aarch64/simulator.c;h=1dde0b478c3d1bc9b88a63dd703225c9a2bb3703;hb=HEAD#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 <adinn@redhat.com> 于2024年3月11日周一 18:41写道: > >> 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 >> > >> >> ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Inquiry on AArch64 Simulator in GDB 2024-03-11 11:31 ` Shiro B 2024-03-11 11:36 ` Shiro B @ 2024-03-11 15:24 ` Andrew Dinn 1 sibling, 0 replies; 5+ messages in thread From: Andrew Dinn @ 2024-03-11 15:24 UTC (permalink / raw) To: Shiro B; +Cc: gdb On 11/03/2024 11:31, Shiro B wrote: > 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. Glad to be able to help. > During my exploration and testing, I believe I may have stumbled upon a > bug related to the UMINV instruction, as detailed in the ARM > documentation > (https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/UMINV--Unsigned-Minimum-across-Vector-?lang=en <https://developer.arm.com/documentation/ddi0596/2020-12/SIMD-FP-Instructions/UMINV--Unsigned-Minimum-across-Vector-?lang=en>). 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. The relevant code can be found here: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=sim/aarch64/simulator.c;h=1dde0b478c3d1bc9b88a63dd703225c9a2bb3703;hb=HEAD#l4482 <https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=sim/aarch64/simulator.c;h=1dde0b478c3d1bc9b88a63dd703225c9a2bb3703;hb=HEAD#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. Yes, I agree that is an error. The spec clearly states that all four instructions should place the result in the "SIMD&FP destination register encoded in the "Rd" field". Well done for spotting it. regards, Andrew Dinn ----------- ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-03-11 15:24 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-03-11 3:34 Inquiry on AArch64 Simulator in GDB Shiro B 2024-03-11 10:41 ` Andrew Dinn 2024-03-11 11:31 ` Shiro B 2024-03-11 11:36 ` Shiro B 2024-03-11 15:24 ` Andrew Dinn
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).