aboutsummaryrefslogtreecommitdiff
path: root/gdb/gdbarch-gen.h
AgeCommit message (Collapse)AuthorFilesLines
2023-01-03Don't emit gdbarch_return_valueTom Tromey1-1/+0
The previous patch introduced a new overload of gdbarch_return_value. The intent here is that this new overload always be called by the core of gdb -- the previous implementation is effectively deprecated, because a call to the old-style method will not work with any converted architectures (whereas calling the new-style method is will delegate when needed). This patch changes gdbarch.py so that the old gdbarch_return_value wrapper function can be omitted. This will prevent any errors from creeping in.
2023-01-03Add new overload of gdbarch_return_valueTom Tromey1-2/+19
The gdbarch "return_value" can't correctly handle variably-sized types. The problem here is that the TYPE_LENGTH of such a type is 0, until the type is resolved, which requires reading memory. However, gdbarch_return_value only accepts a buffer as an out parameter. Fixing this requires letting the implementation of the gdbarch method resolve the type and return a value -- that is, both the contents and the new type. After an attempt at this, I realized I wouldn't be able to correctly update all implementations (there are ~80) of this method. So, instead, this patch adds a new method that falls back to the current method, and it updates gdb to only call the new method. This way it's possible to incrementally convert the architectures that I am able to test.
2023-01-01Update copyright year range in header of all files managed by GDBJoel Brobecker1-1/+1
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-16[aarch64] Fix removal of non-address bits for PAuthLuis Machado1-7/+14
PR gdb/28947 The address_significant gdbarch setting was introduced as a way to remove non-address bits from pointers, and it is specified by a constant. This constant represents the number of address bits in a pointer. Right now AArch64 is the only architecture that uses it, and 56 was a correct option so far. But if we are using Pointer Authentication (PAuth), we might use up to 2 bytes from the address space to store the required information. We could also have cases where we're using both PAuth and MTE. We could adjust the constant to 48 to cover those cases, but this doesn't cover the case where GDB needs to sign-extend kernel addresses after removal of the non-address bits. This has worked so far because bit 55 is used to select between kernel-space and user-space addresses. But trying to clear a range of bits crossing the bit 55 boundary requires the hook to be smarter. The following patch renames the gdbarch hook from significant_addr_bit to remove_non_address_bits and passes a pointer as opposed to the number of bits. The hook is now responsible for removing the required non-address bits and sign-extending the address if needed. While at it, make GDB and GDBServer share some more code for aarch64 and add a new arch-specific testcase gdb.arch/aarch64-non-address-bits.exp. Bug-url: https://sourceware.org/bugzilla/show_bug.cgi?id=28947 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2022-11-14PowerPC, fix support for printing the function return value for non-trivial ↵Carl Love1-0/+11
values. Currently, a non-trivial return value from a function cannot currently be reliably determined on PowerPC. This is due to the fact that the PowerPC ABI uses register r3 to store the address of the buffer containing the non-trivial return value when the function is called. The PowerPC ABI does not guarantee the value in register r3 is not modified in the function. Thus the value in r3 cannot be reliably used to obtain the return addreses on exit from the function. This patch adds a new gdbarch method to allow PowerPC to access the value of r3 on entry to a function. On PowerPC, the new gdbarch method attempts to use the DW_OP_entry_value for the DWARF entries, when exiting the function, to determine the value of r3 on entry to the function. This requires the use of the -fvar-tracking compiler option to compile the user application thus generating the DW_OP_entry_value in the binary. The DW_OP_entry_value entries in the binary file allows GDB to resolve the DW_TAG_call_site entries. This new gdbarch method is used to get the return buffer address, in the case of a function returning a nontrivial data type, on exit from the function. The GDB function should_stop checks to see if RETURN_BUF is non-zero. By default, RETURN_BUF will be set to zero by the new gdbarch method call for all architectures except PowerPC. The get_return_value function will be used to obtain the return value on all other architectures as is currently being done if RETURN_BUF is zero. On PowerPC, the new gdbarch method will return a nonzero address in RETURN_BUF if the value can be determined. The value_at function uses the return buffer address to get the return value. This patch fixes five testcase failures in gdb.cp/non-trivial-retval.exp. The correct function return values are now reported. Note this patch is dependent on patch: "PowerPC, function ppc64_sysv_abi_return_value add missing return value convention". This patch has been tested on Power 10 and x86-64 with no regressions.
2022-10-31Use enum for gdbarch's call_dummy_locationTom Tromey1-2/+2
This changes gdbarch to use an enum for call_dummy_location, providing a little more type safety.
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-30/+30
This changes GDB to use frame_info_ptr instead of frame_info * The substitution was done with multiple sequential `sed` commands: sed 's/^struct frame_info;/class frame_info_ptr;/' sed 's/struct frame_info \*/frame_info_ptr /g' - which left some issues in a few files, that were manually fixed. sed 's/\<frame_info \*/frame_info_ptr /g' sed 's/frame_info_ptr $/frame_info_ptr/g' - used to remove whitespace problems. The changed files were then manually checked and some 'sed' changes undone, some constructors and some gets were added, according to what made sense, and what Tromey originally did Co-Authored-By: Bruno Larsen <blarsen@redhat.com> Approved-by: Tom Tomey <tom@tromey.com>
2022-10-02gdb/gdbarch: add a comment to gdbarch_register_nameAndrew Burgess1-0/+6
After the previous commit, this commit sets out to formalise the API for gdbarch_register_name. Not every architecture is actually in compliance with the API I set out here, but I believe that most are. I think architectures that don't comply with the API laid out here will fail the gdb.base/completion.exp test. The claims in the comment are I feel, best demonstrated with the asserts in this code: const char * gdbarch_register_name (struct gdbarch *gdbarch, int regnr) { gdb_assert (regnr >= 0); gdb_assert (regnr < gdbarch_num_cooked_regs (gdbarch)); const char *name = gdbarch->register_name (gdbarch, regnr); gdb_assert (name != nullptr); return name; } Like I said, I don't believe every architecture follows these rules right now, which is why I'm not actually adding any asserts. Instead, this commit adds a comment to gdbarch_register_name, this comment is where I'd like to get to, rather than where we are right now. Subsequent commits will fix all targets to be in compliance with this comment, and will even add the asserts shown above to gdbarch_register_name.
2022-09-29gdb: constify auxv parse functionsSimon Marchi1-2/+2
Constify the input parameters of the various auxv parse functions, they don't need to modify the raw auxv data. Change-Id: I13eacd5ab8e925ec2b5c1f7722cbab39c41516ec
2022-09-20Move solib_ops into gdbarchTom Tromey1-0/+5
This changs solib_ops to be an ordinary gdbarch value and updates all the uses. This removes a longstanding FIXME and makes the code somewhat cleaner as well.
2022-07-19[AArch64] MTE corefile supportLuis Machado1-0/+26
Teach GDB how to dump memory tags for AArch64 when using the gcore command and how to read memory tag data back from a core file generated by GDB (via gcore) or by the Linux kernel. The format is documented in the Linux Kernel documentation [1]. Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each of those segments when reading the core file back. To save a little bit of space, given MTE tags only take 4 bits, the memory tags are stored packed as 2 tags per byte. When reading the data back, the tags are unpacked. I've added a new testcase to exercise the feature. Build-tested with --enable-targets=all and regression tested on aarch64-linux Ubuntu 20.04. [1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)
2022-05-05gdb: use gdb::function_view for ↵Simon Marchi1-9/+4
gdbarch_iterate_over_objfiles_in_search_order callback A rather straightforward patch to change an instance of callback + void pointer to gdb::function_view, allowing pasing lambdas that capture, and eliminating the need for the untyped pointer. Change-Id: I73ed644e7849945265a2c763f79f5456695b0037
2022-04-07gdb: make gdbarch_register_reggroup_p take a const reggroup *Andrew Burgess1-2/+2
Change gdbarch_register_reggroup_p to take a 'const struct reggroup *' argument. This requires a change to the gdb/gdbarch-components.py script, regeneration of gdbarch.{c,h}, and then updates to all the architectures that implement this method. There should be no user visible changes after this commit.
2022-03-14gdb/gdbarch: remove the predicate function for gdbarch_register_typeAndrew Burgess1-2/+0
I don't believe that the gdbarch_register_type_p predicate is called anywhere in GDB, and the gdbarch_register_type function is called without checking the gdbarch_register_type_p predicate function everywhere it is used, for example in init_regcache_descr (regcache.c). My claim is that the gdbarch_register_type function is required for every architecture, and GDB will not work if this function is not supplied. And so, in this commit, I remove the 'predicate=True' from gdbarch-components.py for the 'register_type' field, and regenerate the gdbarch files. There should be no user visible changes after this commit.
2022-03-02Move copyright code from gdbarch.py to new fileTom Tromey1-1/+3
This moves the copyright code from gdbarch.py to a new Python source file, gdbcopyright.py. The function in this file will find the copyright dates by scanning the calling script. This will be reused in a future patch. This involved minor changes to the output of gdbarch.py. Also, I've updated copyright.py to remove the reference to gdbarch.sh. We don't need to mention gdbarch.py there, either.
2022-01-01Automatic Copyright Year update after running gdb/copyright.pyJoel Brobecker1-1/+1
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-12-17Remove gdbarch.shTom Tromey1-64/+64
This patch runs gdbarch.py and removes gdbarch.sh.
2021-12-17Split gdbarch.h into two filesTom Tromey1-0/+1608
This patch splits gdbarch.h into two files -- gdbarch.h now is editable and hand-maintained, and the new gdbarch-gen.h file is the only thing generated by gdbarch.sh. This lets us avoid maintaining boilerplate in the gdbarch.sh file. Note that gdbarch.sh still generates gdbarch.h after this patch. This makes it easier to re-run when rebasing. This code is removed in a subsequent patch.