aboutsummaryrefslogtreecommitdiff
path: root/gdb/features
AgeCommit message (Collapse)AuthorFilesLines
2024-08-14btrace, gdbserver: Add ptwrite to btrace_config_pt.Felix Willgerodt1-0/+1
This enables gdb and gdbserver to communicate about ptwrite support. If ptwrite support would be enabled unconditionally, GDBs with older libipt versions would break. Approved-By: Markus Metzger <markus.t.metzger@intel.com> Reviewed-By: Eli Zaretskii <eliz@gnu.org>
2024-06-18[gdb/build] Add GPL header comment to gdb/features/feature_to_c.awkTom de Vries1-0/+17
Commit 97033da5070 ("[gdb/build] Cleanup gdb/features/feature_to_c.sh") factored out new file gdb/features/feature_to_c.awk out of gdb/features/feature_to_c.sh, but failed to add the GPL header comment, so add this now. Tested on x86_64-linux.
2024-06-15[gdb/build] Cleanup gdb/features/feature_to_c.shTom de Vries2-34/+52
Clean up script gdb/features/feature_to_c.sh by: - fixing shellcheck warnings, - moving an embedded awk script out of the file, reducing the amount of escaping in the awk script, making it more readable and maintainable, and - adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh). Tested on x86_64-linux. Approved-by: Kevin Buettner <kevinb@redhat.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi69-69/+0
Now that defs.h, server.h and common-defs.h are included via the `-include` option, it is no longer necessary for source files to include them. Remove all the inclusions of these files I could find. Update the generation scripts where relevant. Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 Approved-By: Pedro Alves <pedro@palves.net>
2024-02-06gdb: LoongArch: Add LBT extension supportFeiyang Chen3-0/+36
Loongson Binary Translation (LBT) is used to accelerate binary translation, which contains 4 scratch registers (scr0 to scr3), x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This patch support gdb to fetch/store these registers. Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn> # Framework Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> # Detail Optimizes Signed-off-by: Hui Li <lihui@loongson.cn> # Error Fixes Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2024-02-06gdb: LoongArch: Add vector extensions supportHui Li5-0/+288
Add LoongArch's vector extensions support, which including 128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX (i.e., Loongson Advanced SIMD eXtension). This patch support gdb to fetch/store vector registers. Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess191-191/+191
This commit is the result of the following actions: - Running gdb/copyright.py to update all of the copyright headers to include 2024, - Manually updating a few files the copyright.py script told me to update, these files had copyright headers embedded within the file, - Regenerating gdbsupport/Makefile.in to refresh it's copyright date, - Using grep to find other files that still mentioned 2023. If these files were updated last year from 2022 to 2023 then I've updated them this year to 2024. I'm sure I've probably missed some dates. Feel free to fix them up as you spot them.
2023-10-04sme2: Enable SME2 for AArch64 gdb on LinuxLuis Machado1-0/+43
SME2 defines a new 512-bit register named ZT0, and it is only available if SME is also supported. The ZT0 state is valid only if the SVCR ZA bit is enabled. Otherwise its contents are empty (0). The target description is dynamic and gets generated at runtime based on the availability of the feature. Validated under Fast Models. Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2023-10-04sme: Enable SME registers and pseudo-registersLuis Machado1-0/+63
The SME (Scalable Matrix Extension) [1] exposes a new matrix register ZA with variable sizes. It also exposes a new mode called streaming mode. Similarly to SVE, the ZA register size is dictated by a vector length, but the SME vector length is called streaming vetor length. The total size for ZA in a given moment is svl x svl. In streaming mode, the SVE registers have their sizes based on svl rather than the regular vector length (vl). The feature detection is controlled by the HWCAP2_SME bit, but actual support should be validated by attempting a ptrace call for one of the new register sets: NT_ARM_ZA and NT_ARM_SSVE. Due to its large size, the ZA register is exposed as a vector of bytes, but we introduce a number of pseudo-registers that gives various different views into the ZA contents. These can be arranged in a couple categories: tiles and tile slices. Tiles are matrices the same size or smaller than ZA. Tile slices are vectors which map to ZA's rows/columns in different ways. A new dynamic target description is provided containing the ZA register, the SVG register and the SVCR register. The size of ZA, like the SVE vector registers, is based on the vector length register SVG (VG for SVE). This patch enables SME register support for gdb. [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/scalable-matrix-extension-armv9-a-architecture Co-Authored-By: Ezra Sitorus <ezra.sitorus@arm.com> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2023-06-03[gdb] Fix typosTom de Vries2-3/+3
Fix a few typos: - implemention -> implementation - convertion(s) -> conversion(s) - backlashes -> backslashes - signoring -> ignoring - (un)ambigious -> (un)ambiguous - occured -> occurred - hidding -> hiding - temporarilly -> temporarily - immediatelly -> immediately - sillyness -> silliness - similiar -> similar - porkuser -> pokeuser - thats -> that - alway -> always - supercede -> supersede - accomodate -> accommodate - aquire -> acquire - priveleged -> privileged - priviliged -> privileged - priviledges -> privileges - privilige -> privilege - recieve -> receive - (p)refered -> (p)referred - succesfully -> successfully - successfuly -> successfully - responsability -> responsibility - wether -> whether - wich -> which - disasbleable -> disableable - descriminant -> discriminant - construcstor -> constructor - underlaying -> underlying - underyling -> underlying - structureal -> structural - appearences -> appearances - terciarily -> tertiarily - resgisters -> registers - reacheable -> reachable - likelyhood -> likelihood - intepreter -> interpreter - disassemly -> disassembly - covnersion -> conversion - conviently -> conveniently - atttribute -> attribute - struction -> struct - resonable -> reasonable - popupated -> populated - namespaxe -> namespace - intialize -> initialize - identifer(s) -> identifier(s) - expection -> exception - exectuted -> executed - dungerous -> dangerous - dissapear -> disappear - completly -> completely - (inter)changable -> (inter)changeable - beakpoint -> breakpoint - automativ -> automatic - alocating -> allocating - agressive -> aggressive - writting -> writing - reguires -> requires - registed -> registered - recuding -> reducing - opeartor -> operator - ommitted -> omitted - modifing -> modifying - intances -> instances - imbedded -> embedded - gdbaarch -> gdbarch - exection -> execution - direcive -> directive - demanged -> demangled - decidely -> decidedly - argments -> arguments - agrument -> argument - amespace -> namespace - targtet -> target - supress(ed) -> suppress(ed) - startum -> stratum - squence -> sequence - prompty -> prompt - overlow -> overflow - memember -> member - languge -> language - geneate -> generate - funcion -> function - exising -> existing - dinking -> syncing - destroh -> destroy - clenaed -> cleaned - changep -> changedp (name of variable) - arround -> around - aproach -> approach - whould -> would - symobl -> symbol - recuse -> recurse - outter -> outer - freeds -> frees - contex -> context Tested on x86_64-linux. Reviewed-By: Tom Tromey <tom@tromey.com>
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker189-189/+189
This commit is the result of running the gdb/copyright.py script, which automated the update of the copyright year range for all source files managed by the GDB project to be updated to include year 2023.
2022-12-09[aarch64] Add TPIDR2 register support for LinuxLuis Machado3-15/+32
With the AArch64 Scalable Matrix Extension we have a new TPIDR2 register, and it will be added to the existing NT_ARM_TLS register set. Kernel patches are being reviewed here: https://lore.kernel.org/linux-arm-kernel/20220818170111.351889-1-broonie@kernel.org/ From GDB's perspective, we handle it in a similar way to the existing TPIDR register. But we need to consider cases of systems that only have TPIDR and systems that have both TPIDR and TPIDR2. With that in mind, the following patch adds the required code to support TPIDR2 and turns the org.gnu.gdb.aarch64.tls feature into a dynamically-generated target description as opposed to a static target description containing only TPIDR. That means we can remove the gdb/features/aarch64-tls.xml file and replace the existing gdb/features/aarch64-tls.c auto-generated file with a new file that dynamically generates the target description containing either TPIDR alone or TPIDR and TPIDR2. In the future, when *BSD's start to support this register, they can just enable it as is being done for the AArch64 Linux target. The core file read/write code has been updated to support TPIDR2 as well. On GDBserver's side, there is a small change to the find_regno function to expose a non-throwing version of it. It always seemed strange to me how find_regno causes the whole operation to abort if it doesn't find a particular register name. The patch moves code from find_regno into find_regno_no_throw and makes find_regno call find_regno_no_throw instead. This allows us to do register name lookups to find a particular register number without risking erroring out if nothing is found. The patch also adjusts the feature detection code for aarch64-fbsd, since the infrastructure is shared amongst all aarch64 targets. I haven't added code to support TPIDR2 in aarch64-fbsd though, as I'm not sure when/if that will happen.
2022-10-18gdb, gdbserver: extend RSP to support namespacesMarkus Metzger1-0/+4
Introduce a new qXfer:libraries-svr4:read annex key/value pair lmid=<namespace identifier> to be used together with start and prev to provide the namespace of start and prev to gdbserver. Unknown key/value pairs are ignored by gdbserver so no new supports check is needed. Introduce a new library-list-svr4 library attribute lmid to provide the namespace of a library entry to GDB. This implementation uses the address of a namespace's r_debug object as namespace identifier. This should have incremented the minor version but since unknown XML attributes are ignored, anyway, and since changing the version results in a warning from GDB, the version is left at 1.0.
2022-10-04[AArch64] Update FPSR/FPCR fields for FPU and SVELuis Machado3-2/+53
I noticed some missing flags/fields from FPSR and FPCR registers in both the FPU and SVE target descriptions. This patch adds those and makes the SVE versions of FPSR and FPCR use the proper flags/bitfields types.
2022-10-02gdb: check for duplicate register names in selftestAndrew Burgess4-10/+6
Building on the previous commit, this commit extends the register_name selftest to check for duplicate register names. If two registers in the cooked register set (real + pseudo registers) have the same name, then this will show up as duplicate registers in the 'info all-registers' output, but the user will only be able to interact with one copy of the register. In this commit I extend the selftest that I added in the previous commit to check for duplicate register names, I didn't include this functionality in the previous commit because one architecture needed fixing, and I wanted to keep those fixes separate from the fixes in the previous commit. The problematic architecture(s) are powerpc:750 and powerpc:604. In both of these cases the 'dabr' register appears twice, there's a definition of dabr in power-oea.xml which is included into both powerpc-604.xml and powerpc-750.xml. Both of these later two xml files also define the dabr register. I'm hopeful that this change shouldn't break anything, but I don't have the ability to actually test this change, however: On the gdbserver side, neither powerpc-604.xml nor powerpc-750.xml are mentioned in gdbserver/configure.srv, which I think means that gdbserver will never use these descriptions, and, Within GDB the problematic descriptions are held in the variables tdesc_powerpc_604 and tdesc_powerpc_750, which are only mentioned in the variants array in rs6000-tdep.c, this is used when looking up a description based on the architecture. For a native Linux target however, this will not be used as ppc_linux_nat_target::read_description exists, which calls ppc_linux_match_description, which I don't believe can return either of the problematic descriptions. This leaves the other native targets, FreeBSD, AIX, etc. These don't appear to override the ::read_description method, so will potentially return the problematic descriptions, but, in each case I think the ::fetch_registers and ::store_registers methods will ignore the dabr register, which will leave the register as <unavailable>. So, my proposed solution is to just remove the duplicate register from each of powerpc-604.xml and powerpc-750.xml, then regenerate the corresponding C++ source file. With this change made, the selftest now passes for all architectures.
2022-09-29Constify target_desc declarationsKeith Seitz70-69/+70
This patch changes various global target_desc declarations to const, thereby correcting a prominent source of ODR violations in PowerPC-related target code. The majority of files/changes are mechanical const-ifications accomplished by regenerating the C files in features/. This also required manually updating mips-linux-tdep.h, s390-linux-tdep.h, nios2-tdep.h, s390-tdep.h, arch/ppc-linux-tdesc.h, arch/ppc-linux-common.c, and rs6000-tdep.c. Patch tested against the sourceware trybot, and fully regression tested against our (Red Hat's) internal test infrastructure on Rawhide aarch64, s390x, x86_64, and powerpcle. With this patch, I can finally enable LTO in our GDB package builds. [Tested with a rawhide scratch build containing this patch.] Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24835
2022-09-29cleanup: Add missing feature/ XML files to MakefileKeith Seitz4-20/+24
This patch adds some missing .xml files to features/Makefile so that when the directory's C files are regenerated, all files are appropriately remade. This has demonstrated that there have been several "misses" in regenerating files in this directory. Namely, arm-secext.c and sparc{32,64}-solaris.c. For the former case, there was what essentially amounts to a typo regarding the create feature function's name. In the later case, this file has missed at least one important update in July, 2020, when allocate_target_description was changed to return a unique pointer. Those corrections are included.
2022-09-23gdb/csky add cskyv2-linux.xml for cskyv2-linux.cJiangshuai Li3-81/+184
Add cskyv2-linux.xml for re-generating cskyv2-linux.c if needed. Also update cskyv2-linux.c.
2022-09-13gdbserver/csky add csky gdbserver supportJiangshuai Li1-0/+127
Add new files: gdb/arch/csky.c gdb/arch/csky.h gdb/features/cskyv2-linux.c gdbserver/linux-csky-low.cc 1. In gdb/arch/csky.c file, add function "csky_create_target_description()" for csky_target::low_arch_setup(). later, it can be used for csky native gdb. 2. In gdb/features/cskyv2-linux.c file, create target_tdesc for csky, include gprs, pc, hi, lo, float, vector and float control registers. 3. In gdbserver/linux-csky-low.cc file, using PTRACE_GET/SET_RGESET to get/set registers. The main data structures in asm/ptrace.h are: struct pt_regs { unsigned long tls; unsigned long lr; unsigned long pc; unsigned long sr; unsigned long usp; /* * a0, a1, a2, a3: * r0, r1, r2, r3 */ unsigned long orig_a0; unsigned long a0; unsigned long a1; unsigned long a2; unsigned long a3; /* * r4 ~ r13 */ unsigned long regs[10]; /* r16 ~ r30 */ unsigned long exregs[15]; unsigned long rhi; unsigned long rlo; unsigned long dcsr; }; struct user_fp { unsigned long vr[96]; unsigned long fcr; unsigned long fesr; unsigned long fid; unsigned long reserved; };
2022-08-31gdb/riscv: better support for fflags and frm registersAndrew Burgess4-10/+2
First, some background on the RISC-V registers fflags, frm, and fcsr. These three registers all relate to the floating-point status and control mechanism on RISC-V. The fcsr is the floatint-point control status register, and consists of two parts, the flags (bits 0 to 4) and the rounding-mode (bits 5 to 7). The fcsr register is just one of many control/status registers (or CSRs) available on RISC-V. The fflags and frm registers are also CSRs. These CSRs are aliases for the relevant parts of the fcsr register. So fflags is an alias for bits 0 to 4 of fcsr, and frm is an alias for bits 5 to 7 of fcsr. This means that a user can change the floating-point rounding mode either, by writing a complete new value into fcsr, or by writing just the rounding mode into frm. How this impacts on GDB is like this: a target description could, legitimately include all three registers, fcsr, fflags, and frm. The QEMU target currently does this, and this makes sense. The target is emulating the complete system, and has all three CSRs available, so why not tell GDB about this. In contrast, the RISC-V native Linux target only has access to the fcsr. This is because the ptrace data structure that the kernel uses for reading and writing floating point state only contains a copy of the fcsr, after all, this one field really contains both the fflags and frm fields, so why carry around duplicate data. So, we might expect that the target description for the RISC-V native Linux GDB would only contain the fcsr register. Unfortunately, this is not the case. The RISC-V native Linux target uses GDB's builtin target descriptions by calling riscv_lookup_target_description, this will then add an fpu feature from gdb/features/riscv, either 32bit-fpu.xml or 64bit-fpu.xml. The problem, is that these features include an entry for fcsr, fflags, and frm. This means that GDB expects the target to handle reading and writing these registers. And the RISC-V native Linux target currently doesn't. In riscv_linux_nat_target::store_registers and riscv_linux_nat_target::fetch_registers only the fcsr register is handled, this means that, for RISC-V native Linux, the fflags and frm registers always show up as <unavailable> - they are present in the target description, but the target doesn't know how to access the registers. A final complication relating to these floating pointer CSRs is which target description feature the registers appear in. These registers are CSRs, so it would seem sensible that these registers should appear in the CSR target description feature. However, when I first added RISC-V target description support, I was using a RISC-V simulator that didn't support any CSRs other than the floating point related ones. This simulator bundled all the float related CSRs into the fpu target feature. This didn't feel completely unreasonable to me, and so I had GDB check for these registers in either target feature. In this commit I make some changes relating to how GDB handles the three floating point CSR: 1. Remove fflags and frm from 32bit-fpu.xml and 64bit-fpu.xml. This means that the default RISC-V target description (which RISC-V native FreeBSD), and the target descriptions created for RISC-V native Linux, will not include these registers. There's nothing stopping some other target (e.g. QEMU) from continuing to include all three of these CSRs, the code in riscv-tdep.c continues to check for all three of these registers, and will handle them correctly if they are present. 2. If a target supplied fcsr, but does not supply fflags and/or frm, then RISC-V GDB will now create two pseudo registers in order to emulate the two missing CSRs. These new pseudo-registers do the obvious thing of just reading and writing the fcsr register. 3. With the new pseudo-registers we can no longer make use of the GDB register numbers RISCV_CSR_FFLAGS_REGNUM and RISCV_CSR_FRM_REGNUM. These will be the numbers used if the target supplies the registers in its target description, but, if GDB falls back to using pseudo-registers, then new, unique numbers will be used. To handle this I've added riscv_gdbarch_tdep::fflags_regnum and riscv_gdbarch_tdep::frm_regnum, I've then updated the RISC-V code to compare against these fields. When adding the pseudo-register support, it is important that the pseudo-register numbers are calculated after the call to tdesc_use_registers. This is because we don't know the total number of physical registers until after this call, and the psuedo-register numbers must follow on from the real (target supplied) registers. I've updated some tests to include more testing of the fflags and frm registers, as well as adding a new test.
2022-08-14gdb/nds32: update features/nds32.cAndrew Burgess1-1/+1
After this commit: commit 7b7c365c5c663ffdfb2b3f696db35c23cdccd921 Date: Wed Sep 15 10:10:46 2021 +0200 [bfd] Ensure unique printable names for bfd archs The printable name field of the default nds32 bfd_arch_info changed from 'n1h' to 'n1'. As a consequence the generated feature file within GDB should have been recreated. Recreate it now.
2022-08-09gdb/gdbserver: LoongArch: Improve implementation of fcc registersFeiyang Chen2-2/+16
The current implementation of the fcc register is referenced to the user_fp_state structure of the kernel uapi [1]. struct user_fp_state { uint64_t fpr[32]; uint64_t fcc; uint32_t fcsr; }; But it is mistakenly defined as a 64-bit fputype register, resulting in a confusing output of "info register". (gdb) info register ... fcc {f = 0x0, d = 0x0} {f = 0, d = 0} ... According to "Condition Flag Register" in "LoongArch Reference Manual" [2], there are 8 condition flag registers of size 1. Use 8 registers of uint8 to make it easier for users to view the fcc register groups. (gdb) info register ... fcc0 0x1 1 fcc1 0x0 0 fcc2 0x0 0 fcc3 0x0 0 fcc4 0x0 0 fcc5 0x0 0 fcc6 0x0 0 fcc7 0x0 0 ... [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h [2] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_condition_flag_register Signed-off-by: Feiyang Chen <chenfeiyang@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-07-12gdb: LoongArch: Add floating-point supportTiezhu Yang3-0/+106
This commit adds floating-point support for LoongArch gdb. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-07-05gdb: LoongArch: add orig_a0 into register setXi Ruoyao4-0/+4
The basic support for LoongArch has been merged into the upstream Linux kernel since 5.19-rc1 on June 5, 2022. This commit adds orig_a0 which is added into struct user_pt_regs [1] to match the upstream kernel, and then the upstream GDB will work with the upstream kernel. Note that orig_a0 was added into struct user_pt_regs in the development cycle for merging LoongArch port into the upstream Linux kernel, so earlier kernels (notably, the product kernel with version 4.19 used in distros like UOS and Loongnix) don't have it. Inspect arch/loongarch/include/uapi/asm/ptrace.h in the kernel tree to make sure. To build upstream GDB for a kernel lacking orig_a0, it's necessary to revert this commit locally. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/uapi/asm/ptrace.h#n24 Signed-off-by: Xi Ruoyao <xry111@xry111.site> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-05-03Add an aarch64-tls feature which includes the tpidr register.John Baldwin3-0/+26
2022-05-03Add an arm-tls feature which includes the tpidruro register from CP15.John Baldwin3-0/+26
2022-04-27gdb/arm: Add support for multiple stack pointers on Cortex-MChristophe Lyon2-0/+32
Armv8-M architecture with Security extension features four stack pointers to handle Secure and Non-secure modes. This patch adds support to switch between them as needed during unwinding, and replaces all updates of cache->prev_sp with calls to arm_cache_set_prev_sp. Signed-off-by: Torbjörn Svensson <torbjorn.svensson@st.com> Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-04-27gdb/arm: Define MSP and PSP registers for M-ProfileChristophe Lyon3-0/+28
This patch removes the hardcoded access to PSP in arm_m_exception_cache() and relies on the definition with the XML descriptions. Signed-off-by: Christophe Lyon <christophe.lyon@foss.st.com> Signed-off-by: Christophe Lyon <christophe.lyon@arm.com>
2022-03-31gdb: Consolidate 32bit-pkeys.xml and 64bit-pkeys.xmlH.J. Lu5-31/+3
1. Since 32bit-pkeys.xml and 64bit-pkeys.xml are identical, consolidate them into a single keys.xml. 2. Enable PKU for x32 to fix: $ gdbserver :123456 x32-program ... .../gdbserver/regcache.cc:255: A problem internal to GDBserver has been detected . Unknown register pkru requested on Tiger Lake.
2022-02-11gdb: LoongArch: Add Makefile, configure and NEWSTiezhu Yang1-0/+3
This commit adds Makefile, configure and NEWS for LoongArch. Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn> Signed-off-by: Qing zhang <zhangqing@loongson.cn> Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-02-11gdb: LoongArch: Add initial target description supportTiezhu Yang4-0/+182
This commit adds initial target description support for LoongArch. Signed-off-by: Zhensong Liu <liuzhensong@loongson.cn> Signed-off-by: Qing zhang <zhangqing@loongson.cn> Signed-off-by: Youling Tang <tangyouling@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker182-182/+182
This commit brings all the changes made by running gdb/copyright.py as per GDB's Start of New Year Procedure. For the avoidance of doubt, all changes in this commits were performed by the script.
2021-11-17Expose the BTI BTYPE more explicitly in the registersLuis Machado2-0/+4
Augment the register description XML to expose the BTI BTYPE field contained in the CPSR register. It will be displayed like so: cpsr 0x60001000 [ EL=0 BTYPE=0 SSBS C Z ]
2021-10-29gdb: or1k: add generated linux descriptor fileStafford Horne1-0/+78
2021-10-29gdb: or1k: implement gdb serverStafford Horne2-0/+14
This patch adds gdbserver support for OpenRISC. This has been used for debugging the glibc port that in being worked on here: https://github.com/openrisc/or1k-glibc/tree/or1k-port-2 Hence the comment about registers definitions being inline with glibc.
2021-10-11[ARM] Add support for M-profile MVE extensionSrinath Parvathaneni3-0/+40
This patch adds support for the M-profile MVE extension, which includes the following: - New M-profile XML feature m-profile-mve - MVE vector predication status and control register (VPR) - p0 pseudo register (contained in the VPR) - q0 ~ q7 pseudo vector registers - New feature bits - Documentation update Pseudo register p0 is the least significant bits of vpr and can be accessed as $p0 or displayed through $vpr. For more information about the register layout, please refer to [1]. The q0 ~ q7 registers map back to the d0 ~ d15 registers, two d registers per q register. The register dump looks like this: (gdb) info reg all r0 0x0 0 r1 0x0 0 r2 0x0 0 r3 0x0 0 r4 0x0 0 r5 0x0 0 r6 0x0 0 r7 0x0 0 r8 0x0 0 r9 0x0 0 r10 0x0 0 r11 0x0 0 r12 0x0 0 sp 0x0 0x0 <__Vectors> lr 0xffffffff -1 pc 0xd0c 0xd0c <Reset_Handler> xpsr 0x1000000 16777216 d0 0 (raw 0x0000000000000000) d1 0 (raw 0x0000000000000000) d2 0 (raw 0x0000000000000000) d3 0 (raw 0x0000000000000000) d4 0 (raw 0x0000000000000000) d5 0 (raw 0x0000000000000000) d6 0 (raw 0x0000000000000000) d7 0 (raw 0x0000000000000000) d8 0 (raw 0x0000000000000000) d9 0 (raw 0x0000000000000000) d10 0 (raw 0x0000000000000000) d11 0 (raw 0x0000000000000000) d12 0 (raw 0x0000000000000000) d13 0 (raw 0x0000000000000000) d14 0 (raw 0x0000000000000000) d15 0 (raw 0x0000000000000000) fpscr 0x0 0 vpr 0x0 [ P0=0 MASK01=0 MASK23=0 ] s0 0 (raw 0x00000000) s1 0 (raw 0x00000000) s2 0 (raw 0x00000000) s3 0 (raw 0x00000000) s4 0 (raw 0x00000000) s5 0 (raw 0x00000000) s6 0 (raw 0x00000000) s7 0 (raw 0x00000000) s8 0 (raw 0x00000000) s9 0 (raw 0x00000000) s10 0 (raw 0x00000000) s11 0 (raw 0x00000000) s12 0 (raw 0x00000000) s13 0 (raw 0x00000000) s14 0 (raw 0x00000000) s15 0 (raw 0x00000000) s16 0 (raw 0x00000000) s17 0 (raw 0x00000000) s18 0 (raw 0x00000000) s19 0 (raw 0x00000000) s20 0 (raw 0x00000000) s21 0 (raw 0x00000000) s22 0 (raw 0x00000000) s23 0 (raw 0x00000000) s24 0 (raw 0x00000000) s25 0 (raw 0x00000000) s26 0 (raw 0x00000000) s27 0 (raw 0x00000000) s28 0 (raw 0x00000000) s29 0 (raw 0x00000000) s30 0 (raw 0x00000000) s31 0 (raw 0x00000000) q0 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q1 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q2 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q3 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q4 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q5 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q6 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} q7 {u8 = {0x0 <repeats 16 times>}, u16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u32 = {0x0, 0x0, 0x0, 0x0}, u64 = {0x0, 0x0}, f32 = {0x0, 0x0, 0x0, 0x0}, f64 = {0x0, 0x0}} p0 0x0 0 Built and regtested with a simulator. [1] https://developer.arm.com/documentation/ddi0553/bn Co-Authored-By: Luis Machado <luis.machado@linaro.org>
2021-09-03Add half support for AVX512 register view.Felix Willgerodt6-0/+21
This adds support for the half datatype, FP16, to the AVX512 register printing. gdb/ChangeLog: 2020-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * i386-tdep.c (i386_zmm_type) <v32_half>: New field. (i386_ymm_type) <v16_half>: New field. (i386_gdbarch_init): Add set_gdbarch_half_format. * features/i386/64bit-avx512.xml: Add half type. * features/i386/64bit-avx512.c: Regenerated. * features/i386/64bit-sse.xml: Add half type. * features/i386/64bit-sse.c: Regenerated. gdb/testsuite/ChangeLog: 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * gdb.arch/x86-avx512fp16.c: New file. * gdb.arch/x86-avx512fp16.exp: New file. * lib/gdb.exp (skip_avx512fp16_tests): New function.
2021-09-03gdb, i386: Enable AVX512-bfloat16 for i386 targets.Felix Willgerodt2-0/+7
Values of type bfloat16 can also be used on 32-bit targets, which was missed in the original enablement. This also adjusts the testcase to pass with "unix/-m32", where only the lower 8 AVX registers are available. gdb/ChangeLog: 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * features/i386/32bit-sse.xml: Add bfloat16 type. * features/i386/32bit-sse.c: Regenerated. gdb/testsuite/ChangeLog: 2021-07-21 Felix Willgerodt <Felix.Willgerodt@intel.com> * gdb.arch/x86-avx512bf16.exp: Only use x/z/ymm 0-7.
2021-07-28gdb: clean up some things in features/MakefileSimon Marchi1-8/+1
Clean up some things I noticed: - we generate a regformats/microblaze-with-stack-protect.dat file. I don't think this is used. It could be used by a GDBserver built for Microblaze, but GDBserver isn't ported to Microblaze. So I don't think that's used at all. Remove the entry in features/Makefile and the file itself. - There are a bunch of *-expedite values in features/Makefile for architectures for which we don't generate dat files. AFAIK, these *-expedite values are only used when generating dat files. Remove those that are not necessary. - 32bit-segments.xml is not listed in the Makfile, but it's used. This means that it wouldn't get re-generated if we were to change how C files are generated from the XML. It looks like it was simply forgotten, add it. Change-Id: I112d00db317102270e1df924473c37122ccb6c3a
2021-07-17Add basic Z80 CPU supportSergey Belyashov4-1/+91
Supported ISAs: - Z80 (all undocumented instructions) - Z180 - eZ80 (Z80 mode only) Datasheets: Z80: https://www.zilog.com/manage_directlink.php?filepath=docs/z80/um0080&extn=.pdf Z180: https://www.zilog.com/manage_directlink.php?filepath=docs/z180/ps0140&extn=.pdf eZ80: http://www.zilog.com/force_download.php?filepath=YUhSMGNEb3ZMM2QzZHk1NmFXeHZaeTVqYjIwdlpHOWpjeTlWVFRBd056Y3VjR1Jt To debug Z80 programs using GDB you must configure and embed z80-stub.c to your program (SDCC compiler is required). Or you may use some simulator with GDB support. gdb/ChangeLog: * Makefile.in (ALL_TARGET_OBS): Add z80-tdep.c. * NEWS: Mention z80 support. * configure.tgt: Handle z80*. * features/Makefile (XMLTOC): Add z80.xml. * features/z80-cpu.xml: New. * features/z80.c: Generate. * features/z80.xml: New. * z80-tdep.c: New file. * z80-tdep.h: New file. gdb/stubs/ChangeLog: * z80-stub.c: New file. Change-Id: Id0b7a6e210c3f93c6853c5e3031b7bcee47d0db9
2021-03-24AArch64: Add target description/feature for MTE registersLuis Machado3-0/+26
This patch adds a target description and feature "mte" for aarch64. It includes one new register, tag_ctl, that can be used to configure the tag generation rules and sync/async modes. It is 64-bit in size. The patch also adjusts the code that creates the target descriptions at runtime based on CPU feature checks. gdb/ChangeLog: 2021-03-24 Luis Machado <luis.machado@linaro.org> * aarch64-linux-nat.c (aarch64_linux_nat_target::read_description): Take MTE flag into account. Slight refactor to hwcap flag checking. * aarch64-linux-tdep.c (aarch64_linux_core_read_description): Likewise. * aarch64-tdep.c (tdesc_aarch64_list): Add one more dimension for MTE. (aarch64_read_description): Add mte_p parameter and update to use it. Update the documentation. (aarch64_gdbarch_init): Update call to aarch64_read_description. * aarch64-tdep.h (aarch64_read_description): Add mte_p parameter. * arch/aarch64.c: Include ../features/aarch64-mte.c. (aarch64_create_target_description): Add mte_p parameter and update the code to use it. * arch/aarch64.h (aarch64_create_target_description): Add mte_p parameter. * features/Makefile (FEATURE_XMLFILES): Add aarch64-mte.xml. * features/aarch64-mte.c: New file, generated. * features/aarch64-mte.xml: New file. gdbserver/ChangeLog: 2021-03-24 Luis Machado <luis.machado@linaro.org> * linux-aarch64-ipa.cc (get_ipa_tdesc): Update call to aarch64_linux_read_description. (initialize_low_tracepoint): Likewise. * linux-aarch64-low.cc (aarch64_target::low_arch_setup): Take MTE flag into account. * linux-aarch64-tdesc.cc (tdesc_aarch64_list): Add one more dimension for MTE. (aarch64_linux_read_description): Add mte_p parameter and update to use it. * linux-aarch64-tdesc.h (aarch64_linux_read_description): Add mte_p parameter.
2021-01-12aarch64: Add support for bfloat16 in gdb.Srinath Parvathaneni2-0/+7
This patch adds support for bfloat16 in AArch64 gdb. Also adds the field "bf" to vector registers h0-h31. Also adds the vector "bf" to h field in vector registers v0-v31. The following is how the vector register h and v looks like. Before this patch: (gdb) p $h0 $1 = {f = 0, u = 0, s = 0} (gdb) p/x $h0 $2 = {f = 0x0, u = 0x0, s = 0x0} (gdb) p $v0.h $3 = {f = {0, 0, 0, 0, 0, 0, 0, 0}, u = {0, 0, 0, 0, 0, 0, 0, 0}, s = {0, 0, 0, 0, 0, 0, 0, 0}} (gdb) p/x $v0.h $4 = {f = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, s = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} After this patch: (gdb) p $h0 $1 = {bf = 0, f = 0, u = 0, s = 0} (gdb) p/x $h0 $2 = {bf = 0x0, f = 0x0, u = 0x0, s = 0x0} (gdb) p $v0.h $3 = {bf = {0, 0, 0, 0, 0, 0, 0, 0}, f = {0, 0, 0, 0, 0, 0, 0, 0}, u = {0, 0, 0, 0, 0, 0, 0, 0}, s = {0, 0, 0, 0, 0, 0, 0, 0}} (gdb) p/x $v0.h $4 = {bf = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, f = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, u = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, s = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} gdb/ChangeLog: 2021-01-12 Srinath Parvathaneni <srinath.parvathaneni@arm.com> * aarch64-tdep.c (aarch64_vnh_type): Add "bf" field in h registers. (aarch64_vnv_type): Add "bf" type in h field of v registers. * features/aarch64-fpu.c (create_feature_aarch64_fpu): Regenerated. * features/aarch64-fpu.xml: Add bfloat16 type. gdb/testsuite/ChangeLog: 2021-01-12 Srinath Parvathaneni <srinath.parvathaneni@arm.com> * gdb.arch/aarch64-fp.exp: Modify to test bfloat16 support.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker177-177/+177
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2020-12-02gdb/riscv: rewrite target description validation, add rv32e supportAndrew Burgess3-0/+62
This commit started as adding rv32e support to gdb. The rv32e architecture is a cut-down rv32i, it only has 16 x-registers compared to the usual 32, and an rv32e target should not have any floating point registers. In order to add this I needed to adjust the target description validation checks that are performed from riscv_gdbarch_init, and I finally got fed up with the current scheme of doing these checks and rewrote this code. Unfortunately the rv32e changes are currently mixed in with the rewrite of the validation scheme. I could split these apart if anyone is really interested in seeing these two ideas as separate patches. The main idea behind this change is that where previously I tried to have a purely data driven approach, a set of tables one for each expected feature, and then a single generic function that would validate a feature given a table, I have created a new class for each feature. Each class has its own check member function which allows the logic for how to check each feature to be different. I think the new scheme is much easier to follow. There are some other changes that I made to the validation code as part of this commit. I've relaxed some of the checks related to the floating point CSRs. Previously the 3 CSRs fflags, frm, and fcsr all had to be present in either the fpu feature or the csr feature. This requirement is now relaxed, if the CSRs are not present then gdb will not reject the target description. My thinking here is that there's no gdb functionality that specifically requires these registers, and so, if a target offers a description without these registers nothing else in gdb should stop working. And as part of the rv32e support targets now only have to provide the first 16 x-registers and $pc. The second half of the x-registers (x16 -> x31) are now optional. gdb/ChangeLog: * arch/riscv.c: Include 'rv32e-xregs.c'. (riscv_create_target_description): Update to handle rv32e. * arch/riscv.h (struct riscv_gdbarch_features) <embedded>: New member variable. <operator==>: Update to account for new field. <hash>: Likewise. * features/Makefile (FEATURE_XMLFILES): Add riscv/rv32e-xregs.xml. * features/riscv/rv32e-xregs.c: Generated. * features/riscv/rv32e-xregs.xml: New file. * riscv-tdep.c (riscv_debug_breakpoints): Move from later in the file. (riscv_debug_infcall): Likewise. (riscv_debug_unwinder): Likewise. (riscv_debug_gdbarch): Likewise. (enum riscv_register_required_status): Delete. (struct riscv_register_feature): Add constructor, delete default constructor, copy, and assign constructors. (struct riscv_register_feature::register_info) <required>: Delete. <check>: Update comment and arguments. (struct riscv_register_feature) <name>: Change to member function. <prefer_first_name>: Delete. <tdesc_feature>: New member function. <registers>: Rename to... <m_registers>: ...this. <m_feature_name>: New member variable. (riscv_register_feature::register_info::check): Update arguments. (riscv_xreg_feature): Rewrite as class, create a single static instance of the class. (riscv_freg_feature): Likewise. (riscv_virtual_feature): Likewise. (riscv_csr_feature): Likewise. (riscv_create_csr_aliases): Has become a member function inside riscv_csr_feature class. (riscv_abi_embedded): New function definition. (riscv_register_name): Adjust to use new feature objects. (struct riscv_call_info) <riscv_call_info>: Check for rv32e abi, and adjust available argument registers. (riscv_features_from_gdbarch_info): Check for EF_RISCV_RVE flag. (riscv_check_tdesc_feature): Delete. (riscv_tdesc_unknown_reg): Adjust to use new feature objects. (riscv_gdbarch_init): Delete target description checking code, and instead call to the new feature objects to perform the checks. Reorder handling of no abi information case, allows small code simplification. (_initialize_riscv_tdep): Remove call, this is now done in the riscv_csr_feature constructor. * riscv-tdep.h (riscv_abi_embedded): Declare.
2020-11-26gdb/aarch64: Add named flags for FPCR and FPSR registersPrzemyslaw Wirkus2-4/+103
This patch updates FPCR (Floating-point Control Register) and FPSR (Floating-point Status Register) named fields in AArch64. For detailed description of named register FPCR and FPSR bit fields see [1] and [2]. Please not that bit fields FIZ, AH and NEP (bits 0, 1 and 2 respectively) in FPCR are defined starting from Armv8.7 architecture. [1]: https://developer.arm.com/docs/ddi0595/i/aarch64-system-registers/fpcr [2]: https://developer.arm.com/docs/ddi0595/i/aarch64-system-registers/fpsr Example: >>> info all-registers fpsr fpsr 0x10 [ IXC ] >>> info all-registers fpcr fpcr 0x0 [ RMode=0 ]
2020-11-12gdb: add an option flag to 'maint print c-tdesc'Andrew Burgess3-67/+69
GDB has two approaches to generating the target descriptions found in gdb/features/, the whole description approach, where the XML file contains a complete target description which is then used to generate a single C file that builds that target description. Or, the split feature approach, where the XML files contain a single target feature, each feature results in a single C file to create that one feature, and then a manually written C file is used to build a complete target description from individual features. There's a Makefile, gdb/features/Makefile, which is responsible for managing the regeneration of the C files from the XML files. However, some of the logic that selects between the whole description approach, or the split feature approach, is actually hard-coded into GDB, inside target-descriptions.c:maint_print_c_tdesc_cmd we check the path to the incoming XML file and use this to choose which type of C file we should generate. This commit removes this hard coding from GDB, and makes the Makefile entirely responsible for choosing the approach. This makes sense as the Makefile already has the XML files partitioned based on which approach they should use. In order to allow this change the 'maint print c-tdesc' command is given a new command option '-single-feature', which tells GDB which type of C file should be created. The makefile now supplies this flag to GDB. This did reveal a bug in features/Makefile, the rx.xml file was in the wrong list, this didn't matter previously as the actual choice of which approach to use was done in GDB. Now the Makefile decides, so placing each XML file in the correct list is critical. Tested this by doing 'make GDB=/path/to/gdb clean-cfiles cfiles' to regenerate all the C files from their XML source. There are no changes after this commit. gdb/ChangeLog: * features/Makefile (XMLTOC): Add rx.xml. (FEATURE_XMLFILES): Remove rx.xml. (FEATURE_CFILES rule): Pass '-single-feature' flag. * features/rx.c: Regenerate. * features/rx.xml: Wrap in `target` tags, and reindent. * target-descriptions.c (struct maint_print_c_tdesc_options): New structure. (maint_print_c_tdesc_opt_def): New typedef. (maint_print_c_tdesc_opt_defs): New static global. (make_maint_print_c_tdesc_options_def_group): New function. (maint_print_c_tdesc_cmd): Make use of command line flags, only print single feature C file for target descriptions containing a single feature. (maint_print_c_tdesc_cmd_completer): New function. (_initialize_target_descriptions): Update call to register command completer, and include command line flag in help text. gdb/doc/ChangeLog: * gdb.texinfo (Maintenance Commands): Update description of 'maint print c-tdesc'.
2020-10-08gdb: Have allocate_target_description return a unique_ptrAndrew Burgess65-480/+480
Update allocate_target_description to return a target_desc_up, a specialisation of unique_ptr. This commit does not attempt to make use of the unique_ptr in the best possible way, in almost all cases we immediately release the pointer from within the unique_ptr and then continue as before. There are a few places where it was easy to handle the unique_ptr, and in these cases I've done that. Everything under gdb/features/* is auto-regenerated. There should be no user visible changes after this commit. gdb/ChangeLog: * arch/aarch32.c (aarch32_create_target_description): Release unique_ptr returned from allocate_target_description. * arch/aarch64.c (aarch64_create_target_description): Likewise. * arch/amd64.c (amd64_create_target_description): Likewise. * arch/arc.c (arc_create_target_description): Likewise. * arch/arm.c (arm_create_target_description): Likewise. * arch/i386.c (i386_create_target_description): Likewise. * arch/riscv.c (riscv_create_target_description): Update return type. Handle allocate_target_description returning a unique_ptr. (riscv_lookup_target_description): Update to handle unique_ptr. * arch/tic6x.c (tic6x_create_target_description): Release unique_ptr returned from allocate_target_description. * features/microblaze-with-stack-protect.c: Regenerate. * features/microblaze.c: Regenerate. * features/mips-dsp-linux.c: Regenerate. * features/mips-linux.c: Regenerate. * features/mips64-dsp-linux.c: Regenerate. * features/mips64-linux.c: Regenerate. * features/nds32.c: Regenerate. * features/nios2.c: Regenerate. * features/or1k.c: Regenerate. * features/rs6000/powerpc-32.c: Regenerate. * features/rs6000/powerpc-32l.c: Regenerate. * features/rs6000/powerpc-403.c: Regenerate. * features/rs6000/powerpc-403gc.c: Regenerate. * features/rs6000/powerpc-405.c: Regenerate. * features/rs6000/powerpc-505.c: Regenerate. * features/rs6000/powerpc-601.c: Regenerate. * features/rs6000/powerpc-602.c: Regenerate. * features/rs6000/powerpc-603.c: Regenerate. * features/rs6000/powerpc-604.c: Regenerate. * features/rs6000/powerpc-64.c: Regenerate. * features/rs6000/powerpc-64l.c: Regenerate. * features/rs6000/powerpc-7400.c: Regenerate. * features/rs6000/powerpc-750.c: Regenerate. * features/rs6000/powerpc-860.c: Regenerate. * features/rs6000/powerpc-altivec32.c: Regenerate. * features/rs6000/powerpc-altivec32l.c: Regenerate. * features/rs6000/powerpc-altivec64.c: Regenerate. * features/rs6000/powerpc-altivec64l.c: Regenerate. * features/rs6000/powerpc-e500.c: Regenerate. * features/rs6000/powerpc-e500l.c: Regenerate. * features/rs6000/powerpc-isa205-32l.c: Regenerate. * features/rs6000/powerpc-isa205-64l.c: Regenerate. * features/rs6000/powerpc-isa205-altivec32l.c: Regenerate. * features/rs6000/powerpc-isa205-altivec64l.c: Regenerate. * features/rs6000/powerpc-isa205-ppr-dscr-vsx32l.c: Regenerate. * features/rs6000/powerpc-isa205-ppr-dscr-vsx64l.c: Regenerate. * features/rs6000/powerpc-isa205-vsx32l.c: Regenerate. * features/rs6000/powerpc-isa205-vsx64l.c: Regenerate. * features/rs6000/powerpc-isa207-htm-vsx32l.c: Regenerate. * features/rs6000/powerpc-isa207-htm-vsx64l.c: Regenerate. * features/rs6000/powerpc-isa207-vsx32l.c: Regenerate. * features/rs6000/powerpc-isa207-vsx64l.c: Regenerate. * features/rs6000/powerpc-vsx32.c: Regenerate. * features/rs6000/powerpc-vsx32l.c: Regenerate. * features/rs6000/powerpc-vsx64.c: Regenerate. * features/rs6000/powerpc-vsx64l.c: Regenerate. * features/rs6000/rs6000.c: Regenerate. * features/rx.c: Regenerate. * features/s390-gs-linux64.c: Regenerate. * features/s390-linux32.c: Regenerate. * features/s390-linux32v1.c: Regenerate. * features/s390-linux32v2.c: Regenerate. * features/s390-linux64.c: Regenerate. * features/s390-linux64v1.c: Regenerate. * features/s390-linux64v2.c: Regenerate. * features/s390-te-linux64.c: Regenerate. * features/s390-tevx-linux64.c: Regenerate. * features/s390-vx-linux64.c: Regenerate. * features/s390x-gs-linux64.c: Regenerate. * features/s390x-linux64.c: Regenerate. * features/s390x-linux64v1.c: Regenerate. * features/s390x-linux64v2.c: Regenerate. * features/s390x-te-linux64.c: Regenerate. * features/s390x-tevx-linux64.c: Regenerate. * features/s390x-vx-linux64.c: Regenerate. * mips-tdep.c (_initialize_mips_tdep): Release unique_ptr returned from allocate_target_description. * target-descriptions.c (allocate_target_description): Update return type. (print_c_tdesc::visit_pre): Release unique_ptr returned from allocate_target_description. gdbserver/ChangeLog: * linux-low.cc (linux_process_target::handle_extended_wait): Release the unique_ptr returned from allocate_target_description. * linux-riscv-low.cc (riscv_target::low_arch_setup): Likewise. * linux-x86-low.cc (tdesc_amd64_linux_no_xml): Change type. (tdesc_i386_linux_no_xml): Change type. (x86_linux_read_description): Borrow pointer from unique_ptr object. (x86_target::get_ipa_tdesc_idx): Likewise. (initialize_low_arch): Likewise. * tdesc.cc (allocate_target_description): Update return type. gdbsupport/ChangeLog: * tdesc.h (allocate_target_description): Update return type.
2020-09-11Add bfloat16 support for AVX512 register view.Felix Willgerodt4-1/+15
This adds support for the bfloat16 datatype, which can be seen as a short version of FP32, skipping the least significant 16 bits of the mantissa. Since the datatype is currently only supported by the AVX512 registers, the printing of bfloat16 values is only supported for xmm, ymm and zmm registers. gdb/ChangeLog: 2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com> Felix Willgerodt <Felix.Willgerodt@intel.com> * gdbarch.sh: Added bfloat16 type. * gdbarch.c: Regenerated. * gdbarch.h: Regenerated. * gdbtypes.c (floatformats_bfloat16): New struct. (gdbtypes_post_init): Add builtin_bfloat16. * gdbtypes.h (struct builtin_type) <builtin_bfloat16>: New member. (floatformats_bfloat16): New struct. * i386-tdep.c (i386_zmm_type): Add field "v32_bfloat16" (i386_ymm_type): Add field "v16_bfloat16" (i386_gdbarch_init): Add set_gdbarch_bfloat16_format. * target-descriptions.c (make_gdb_type): Add case TDESC_TYPE_BFLOAT16. * gdbsupport/tdesc.cc (tdesc_predefined_types): New member bfloat16. * gdbsupport/tdesc.h (tdesc_type_kind): New member TDESC_TYPE_BFLOAT16. * features/i386/64bit-avx512.xml: Add bfloat16 type. * features/i386/64bit-avx512.c: Regenerated. * features/i386/64bit-sse.xml: Add bfloat16 type. * features/i386/64bit-sse.c: Regenerated. gdb/testsuite/ChangeLog: 2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com> Felix Willgerodt <Felix.Willgerodt@intel.com> * x86-avx512bf16.c: New file. * x86-avx512bf16.exp: Likewise. * lib/gdb.exp (skip_avx512bf16_tests): New function.
2020-08-25arc: Add ARCv2 XML target along with refactoringShahab Vahedi9-29/+35
A few changes have been made to make the register support simpler, more flexible and extendible. The trigger for most of these changes are the remarks [1] made earlier for v2 of this patch. The noticeable improvements are: - The arc XML target features are placed under gdb/features/arc - There are two cores (based on ISA) and one auxiliary feature: v1-core: ARC600, ARC601, ARC700 v2-core: ARC EM, ARC HS aux: common in both - The XML target features represent a minimalistic sane set of registers irrespective of application (baremetal or linux). - A concept of "feature" class has been introduced in the code. The "feature" object is constructed from BFD and GDBARCH data. It contains necessary information (ISA and register size) to determine which XML target feature to use. - A new structure (ARC_REGISTER_FEATURE) is added that allows providing index, names, and the necessity of registers. This simplifies the sanity checks and future extendibility. - Documnetation has been updated to reflect ARC features better. - Although the feature names has changed, there still exists backward compatibility with older names through find_obsolete_[core,aux]_names() functions. The last two points were inspired from RiscV port. [1] https://sourceware.org/pipermail/gdb-patches/2020-May/168511.html gdb/ChangeLog: * arch/arc.h (arc_gdbarch_features): New class to stir the selection of target XML. (arc_create_target_description): Use FEATURES to choose XML target. (arc_lookup_target_description): Use arc_create_target_description to create _new_ target descriptions or return the already created ones if the FEATURES is the same. * arch/arc.c: Implementation of prototypes described above. * gdb/arc-tdep.h (arc_regnum enum): Add more registers. (arc_gdbarch_features_init): Initialize the FEATURES struct. * arc-tdep.c (*_feature_name): Make feature names consistent. (arc_register_feature): A new struct to hold information about registers of a particular target/feature. (arc_check_tdesc_feature): Check if XML provides registers in compliance with ARC_REGISTER_FEATURE structs. (arc_update_acc_reg_names): Add aliases for r58 and r59. (determine_*_reg_feature_set): Which feature name to look for. (arc_gdbarch_features_init): Given MACH and ABFD, initialize FEATURES. (mach_type_to_arc_isa): Convert from a set of binutils machine types to expected ISA enums to be used in arc_gdbarch_features structs. * features/Makefile (FEATURE_XMLFILES): Add new files. * gdb/features/arc/v1-aux.c: New file. * gdb/features/arc/v1-aux.xml: Likewise. * gdb/features/arc/v1-core.c: Likewise. * gdb/features/arc/v1-core.xml: Likewise. * gdb/features/arc/v2-aux.c: Likewise. * gdb/features/arc/v2-aux.xml: Likewise. * gdb/features/arc/v2-core.c: Likewise. * gdb/features/arc/v2-core.xml: Likewise. * NEWS (Changes since GDB 9): Announce obsolence of old feature names. gdb/doc/ChangeLog: * gdb.texinfo (Synopsys ARC): Update the documentation for ARC Features. gdb/testsuite/ChangeLog: * gdb.arch/arc-tdesc-cpu.xml: Use new feature names.
2020-06-25gdb/riscv: Remove CSR feature fileAndrew Burgess6-986/+0
There is currently a bug in the RISC-V CSR/FPU feature files. The CSRs containing the FPU status registers are mentioned in both the FPU feature file and the CSR feature file. My original thinking when adding the FPU feature file was that it made more sense to group the FPU status registers with the other FPU state. This opened up the possibility of debugging very simple (possibly simulator only) targets that had little more than CPU and FPU available for GDB to access. When I then added code to automatically generate the CSR XML file I forgot to filter out the FPU status CSRs, so these registers were mentioned twice. Now for GDB's default RISC-V target descriptions this doesn't actually matter. I did consider adding the CSRs to the default target description, but in the end I didn't bother. The reasoning again was simplicity; the default target description is only to be used when the target doesn't supply its own description, and NOT supplying the CSRs actually serves to encourage targets to supply an accurate description. Combine this with the fact that the CSRs change from revision to revision, sometimes in non-backward compatible ways, then having a "default" set of CSRs just feels like a path to confusion and complaints. However, having a broken CSR XML file in the GDB source tree has had one negative effect, QEMU has copied this file into its source tree, and is using this as its description that it passes to GDB. That is QEMU announces the FPU status registers twice, once in the FPU feature, and once in the CSR feature. This commit starts along the path back to sanity by deleting the default CSR XML files from within GDB. These files were not used in any way by current GDB, so there is absolutely no loss of functionality with this change. gdb/ChangeLog: * features/Makefile: Remove all references to the deleted files below. * features/riscv/32bit-csr.c: Deleted. * features/riscv/32bit-csr.xml: Deleted. * features/riscv/64bit-csr.c: Deleted. * features/riscv/64bit-csr.xml: Deleted. * features/riscv/rebuild-csr-xml.sh: Deleted.
generated by cgit v1.1 at 2024-11-25 09:47:03 +0000