| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Intel has EOL'ed the Nios II architecture, and it's time to remove support
from all toolchain components before it gets any more bit-rotten from
lack of maintenance or regular testing.
|
|
Some gdbserver targets generate their target description based on the
gdb/regformats/*.dat files. These .dat files are generated from a
matching xml file in gdb/features/.
Lets consider a concrete example:
Take gdb/features/or1k-linux.xml, this file is processed by
gdb/features/Makefile to create gdb/regformats/or1k-linux.dat.
When gdbserver is built for the or1k target the file
or1k-linux-generated.cc is generated using the
gdb/regformats/regdat.sh script. This .cc file is then compiled and
linked into gdbserver.
The or1k-linux-generated.cc file contains the function
init_registers_or1k_linux which is called from within gdbserver, this
function creates a target_desc object and sets its xmltarget field to
a fixed string. This fixed string is the xml filename that was
originally used to generate the xml file, in this case or1k-linux.xml.
Additionally, as part of the gdbserver build the file or1k-linux.xml
is converted to a string and placed in the file
xml-builtin-generated.cc which is then built into gdbserver.
Now when GDB asks gdbserver for the target description, gdbserver
returns the fixed xmltarget string, which is the name of an xml file.
GDB will then ask gdbserver for that file and gdbserver will return
the contents of that file thanks to the xml-builtin-generated.cc
file's contents.
This is all rather complicated, but it does work. So what's the
problem that I'm fixing?
Well or1k-linux.xml does contain the osabi information, so this will
be returned from gdbserver to GDB. That's good.
However, the target_desc object created in init_registers_or1k_linux
will not have its osabi set correctly.
Now this doesn't really matter too much except
init_registers_or1k_linux includes a call to init_target_desc.
In the next commit I want to extend init_target_desc to require an
osabi to be passed in. The motivation for this will be explained in
the next commit, but if we accept for a moment that this is something
that should be done, then the question is what osabi should we use in
init_registers_or1k_linux?
Ideally we'd use the osabi which is set in or1k-linux.xml. If we do
that then everything will remain consistent, which is a good thing.
And so, to get the osabi from or1k-linux.xml into
init_registers_or1k_linux, we first need to get the osabi information
into or1k-linux.dat file, and this is what this commit does.
I've added a new xsl script print-osabi.xsl and updated
gdb/features/Makefile to make use of this script. Then I regenerated
all of the .dat files. Now every .dat file contains either:
osabi:GNU/Linux
osabi:unknown
The first is for xml files containing <osabi>GNU/Linux</osabi> and the
second is for xml files that don't contain an osabi element.
This commit doesn't attempt to make use of the osabi information in
the .dat files, that will come in the next commit. There should be no
user visible changes after this commit.
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
Some of the top level (i.e. those that contain the <target> element)
xml files in gdb/features/ are clearly Linux only. I conclude this
based on the files names containing the string "linux".
I think that all of these files should have the <osabi> element
included with the value "GNU/Linux".
This commits adds the <osabi> element where I believe it is
appropriate and regenerates the associated .c files.
The benefit of this change is that gdbserver, which makes use of these
files, will now send the osabi back in more cases. Sending back more
descriptive target descriptions is a good thing as this makes it
easier for GDB to select the correct gdbarch.
Approved-By: Kevin Buettner <kevinb@redhat.com>
|
|
There is a single declaration of set_tdesc_osabi that is shared
between gdbserver/ and gdb/, this declaration takes a 'const char *'
argument which is the string representing an osabi.
Then in gdb/ we have an overload of set_tdesc_osabi which takes an
'enum gdb_osabi'.
In this commit I change the shared set_tdesc_osabi to be the version
which takes an 'enum gdb_osabi', and I remove the version which takes
a 'const char *'. All users of set_tdesc_osabi are updated to pass an
'enum gdb_osabi'.
The features/ code, which is generated from the xml files, requires a
new function to be added to osabi.{c,h} which can return a string
representation of an 'enum gdb_osabi'. With that new function in
place the features/ code is regenerated.
This change is being made to support the next commit. In the next
commit gdbserver will be updated to call set_tdesc_osabi in more
cases. The problem is that gdbserver stores the osabi as a string.
The issue here is that a typo in the gdbserver/ code might go
unnoticed and result in gdbserver sending back an invalid osabi
string.
To fix this we want gdbserver to pass an 'enum gdb_osabi' to the
set_tdesc_osabi function. With that requirement in place it seems to
make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'.
There should be no user visible changes after this commit.
Approved-By: Luis Machado <luis.machado@arm.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
There are two versions of the set_tdesc_osabi function in GDB:
void
set_tdesc_osabi (struct target_desc *target_desc, const char *name)
{
set_tdesc_osabi (target_desc, osabi_from_tdesc_string (name));
}
void
set_tdesc_osabi (struct target_desc *target_desc, enum gdb_osabi osabi)
{
target_desc->osabi = osabi;
}
In the gdb/features/ files we call the second of these functions, like
this:
set_tdesc_osabi (result.get (), osabi_from_tdesc_string ("GNU/Linux"));
This can be replaced with a call to the first set_tdesc_osabi
function, so lets do that. I think that this makes the features/ code
slightly simpler and easier to understand.
There should be no user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel
listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019.
MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6)
and glibc (since v2.35). Let's now remove MPX support in GDB completely.
This includes the removal of:
- MPX functionality including register support
- deprecated mpx commands
- i386 and amd64 implementation of the hooks report_signal_info and
get_siginfo_type
- tests
- and pretty printer.
We keep MPX register numbers to not break compatibility with old gdbservers.
Approved-By: Felix Willgerodt <felix.willgerodt@intel.com>
|
|
Event tracing allows GDB to show information about interesting asynchronous
events when tracing with Intel PT. Subsequent patches will add support for
displaying each type of event.
Enabling event-tracing unconditionally would result in rather noisy output, as
breakpoints themselves result in interrupt events. Which is why this patch adds
a set/show command to allow the user to enable/disable event-tracing before
starting a recording. The event-tracing setting has no effect on an already
active recording. The default setting is off. As event tracing will use the
auxiliary infrastructure added by ptwrite, the user can still disable printing
events, even when event-tracing was enabled, by using the /a switch for the
record instruction-history/function-call-history commands.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Markus Metzger <markus.t.metzger@intel.com>
|
|
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>
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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.
|
|
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>
|
|
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>
|
|
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>
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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.
|
|
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
|
|
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.
|
|
Add cskyv2-linux.xml for re-generating cskyv2-linux.c if needed.
Also update cskyv2-linux.c.
|
|
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;
};
|
|
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.
|
|
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.
|
|
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>
|
|
This commit adds floating-point support for LoongArch gdb.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
|
|
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>
|
|
|
|
|
|
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>
|
|
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>
|
|
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.
|
|
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>
|
|
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>
|
|
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.
|
|
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 ]
|
|
|
|
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.
|
|
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>
|
|
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.
|
|
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.
|
|
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
|
|
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
|
|
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.
|
|
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.
|
|
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.
|
