aboutsummaryrefslogtreecommitdiff
path: root/gdb/arch-utils.c
AgeCommit message (Collapse)AuthorFilesLines
2024-07-15gdb: pass program space to entry_point_addressSimon Marchi1-1/+1
Make the current program space reference bubble up one level. Change-Id: Ifc9b8186abaefb10caf99f79ae09e526fa65c882 Approved-By: Tom Tromey <tom@tromey.com> Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2024-05-10Change gdbarch_inner_than to return boolTom Tromey1-4/+4
A recent patch from Andrew pointed out that gdbarch_inner_than returns 'int', while it should really return 'bool'. Approved-By: Pedro Alves <pedro@palves.net>
2024-04-25gdb: remove gdbcmd.hSimon Marchi1-1/+1
Most files including gdbcmd.h currently rely on it to access things actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make things easy, replace all includes of gdbcmd.h with includes of cli/cli-cmds.h. This might lead to some unused includes of cli/cli-cmds.h, but it's harmless, and much faster than going through the 170 or so files by hand. Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f Approved-By: Tom Tromey <tom@tromey.com>
2024-04-22gdb: move store/extract integer functions to extract-store-integer.{c,h}Simon Marchi1-0/+1
Move the declarations out of defs.h, and the implementations out of findvar.c. I opted for a new file, because this functionality of converting integers to bytes and vice-versa seems a bit to generic to live in findvar.c. Change-Id: I524858fca33901ee2150c582bac16042148d2251 Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-04-19gdb: Introduce is_address_tagged target hookGustavo Romero1-1/+1
This commit introduces a new target hook, target_is_address_tagged, which is used instead of the gdbarch_tagged_address_p gdbarch hook in the upper layer (printcmd.c). This change enables easy specialization of memory tagging address check per target in the future. As target_is_address_tagged continues to utilize the gdbarch_tagged_address_p hook, there is no change in behavior for all the targets that use the new target hook (i.e., the remote.c, aarch64-linux-nat.c, and corelow.c targets). Just the gdbarch_tagged_address_p signature is changed for convenience, since target_is_address_tagged takes the address to be checked as a CORE_ADDR type. Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Approved-By: Luis Machado <luis.machado@arm.com> Tested-By: Luis Machado <luis.machado@arm.com>
2024-03-26gdb, gdbserver, gdbsupport: remove includes of early headersSimon Marchi1-1/+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-03-22Use std::string for disassembler optionsTom Tromey1-3/+3
I noticed that the disassembler_options code uses manual memory management. It seemed simpler to replace this with std::string. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-02-20gdb: pass frames as `const frame_info_ptr &`Simon Marchi1-4/+5
We currently pass frames to function by value, as `frame_info_ptr`. This is somewhat expensive: - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass by value - the constructors and destructor link/unlink the object in the global `frame_info_ptr::frame_list` list. This is an `intrusive_list`, so it's not so bad: it's just assigning a few points, there's no memory allocation as if it was `std::list`, but still it's useless to do that over and over. As suggested by Tom Tromey, change many function signatures to accept `const frame_info_ptr &` instead of `frame_info_ptr`. Some functions reassign their `frame_info_ptr` parameter, like: void the_func (frame_info_ptr frame) { for (; frame != nullptr; frame = get_prev_frame (frame)) { ... } } I wondered what to do about them, do I leave them as-is or change them (and need to introduce a separate local variable that can be re-assigned). I opted for the later for consistency. It might not be clear why some functions take `const frame_info_ptr &` while others take `frame_info_ptr`. Also, if a function took a `frame_info_ptr` because it did re-assign its parameter, I doubt that we would think to change it to `const frame_info_ptr &` should the implementation change such that it doesn't need to take `frame_info_ptr` anymore. It seems better to have a simple rule and apply it everywhere. Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 Approved-By: Andrew Burgess <aburgess@redhat.com>
2024-02-06gdb: remove core_bfd macroSimon Marchi1-1/+1
The core_bfd macro hides a use of current_program_space. Remove it, so that we have the opportunity to get the program space from the context, if possible. I guess that the macro was introduced at some point to replace a global variable of the same name without changing all the uses. Change-Id: I971a65b29b5e5a5941f3cb7ea234547daa787268 Approved-By: Tom Tromey <tom@tromey.com>
2024-01-12Update copyright year range in header of all files managed by GDBAndrew Burgess1-1/+1
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-16gdb: replace architecture_changed with new_architecture observerAndrew Burgess1-0/+2
This commit replaces the architecture_changed observer with a new_architecture observer. Currently the only user of the architecture_changed observer is the Python code, which uses this observer to register the Python unwinder with the architecture. The problem is that the architecture_changed observer is triggered from inferior::set_arch(), which only sees the inferior-wide gdbarch value. For targets that use thread-specific architectures, these never trigger the architecture_changed observer, and so never have the Python unwinder registered with them. When it comes to unwinding GDB makes use of the frame's gdbarch, which is based on the thread's regcache gdbarch, which is set in get_thread_regcache to the value returned from target_thread_architecture, which is not always the inferiors gdbarch value, it might be a thread-specific gdbarch which has not passed through inferior::set_arch(). The new_architecture observer will be triggered from gdbarch_find_by_info, whenever a new gdbarch is created and initialised. As GDB caches and reuses gdbarch values, we should expect to see each new architecture trigger the new_architecture observer just once. After this commit, targets that make use of thread-specific architectures should be able to make use of Python unwinders. As I don't have access to a machine that makes use of thread-specific architectures right now, I asked Luis to confirm that an AArch64 target that uses SVE/SME can't use the Python unwinders in threads that are using a thread-specific architectures, and he confirmed that this is indeed the case, see this discussion: https://inbox.sourceware.org/gdb/87wmvsat8i.fsf@redhat.com Tested-By: Lancelot Six <lancelot.six@amd.com> Tested-By: Luis Machado <luis.machado@arm.com> Reviewed-By: Luis Machado <luis.machado@arm.com> Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-10-10gdb: remove target_gdbarchSimon Marchi1-10/+2
This function is just a wrapper around the current inferior's gdbarch. I find that having that wrapper just obscures where the arch is coming from, and that it's often used as "I don't know which arch to use so I'll use this magical target_gdbarch function that gets me an arch" when the arch should in fact come from something in the context (a thread, objfile, symbol, etc). I think that removing it and inlining `current_inferior ()->arch ()` everywhere will make it a bit clearer where that arch comes from and will trigger people into reflecting whether this is the right place to get the arch or not. Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: move set_target_gdbarch to inferior::set_archSimon Marchi1-12/+8
set_target_gdbarch is basically a setter for the current inferior's arch, that notifies other parts of GDB of the architecture change. Move the code of set_target_gdbarch to the inferior::set_arch method. Add gdbarch_initialized_p, so we can keep the assertion. Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: add inferior parameter to architecture_changed observableSimon Marchi1-1/+2
This is to make it explicit which inferior's architecture just changed, and that the callbacks should not assume it is the current inferior. Update the only caller, pyuw_on_new_gdbarch, to add the parameter, although it doesn't use it currently. Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: add inferior::{arch, set_arch}Simon Marchi1-2/+2
Make the inferior's gdbarch field private, and add getters and setters. This helped me by allowing putting breakpoints on set_arch to know when the inferior's arch was set. A subsequent patch in this series also adds more things in set_arch. Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-04corefile/bug: Add hook to control the use of target description notes from ↵Luis Machado1-0/+10
corefiles Due to the nature of the AArch64 SVE/SME extensions in GDB, each thread can potentially have distinct target descriptions/gdbarches. When loading a gcore-generated core file, at the moment GDB gives priority to the target description dumped to NT_GDB_TDESC. Though technically correct for most targets, it doesn't work correctly for AArch64 with SVE or SME support. The correct approach for AArch64/Linux is to either have per-thread target description notes in the corefiles or to rely on the gdbarch_core_read_description hook, so it can figure out the proper target description for a given thread based on the various available register notes. The former, although more correct, doesn't address the case of existing gdb's that only output a single target description note. This patch goes for the latter, and adds a new gdbarch hook to conditionalize the use of the corefile target description note. The hook is called use_target_description_from_corefile_notes. The hook defaults to returning true, meaning targets will use the corefile target description note. AArch64 Linux overrides the hook to return false when it detects any of the SVE or SME register notes in the corefile. Otherwise it should be fine for AArch64 Linux to use the corefile target description note. When we support per-thread target description notes, then we can augment the AArch64 Linux hook to rely on those notes. Regression-tested on aarch64-linux Ubuntu 22.04/20.04. Approved-By: Simon Marchi <simon.marchi@efficios.com> Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2023-09-20Remove explanatory comments from includesTom Tromey1-1/+1
I noticed a comment by an include and remembered that I think these don't really provide much value -- sometimes they are just editorial, and sometimes they are obsolete. I think it's better to just remove them. Tested by rebuilding. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-06-03[gdb] Fix typosTom de Vries1-1/+1
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-04-21Handle erroneous DW_AT_call_return_pcTom Tromey1-0/+6
On PPC64, with the test case included in an earlier patch, we found that "finish" would still not correctly find the return value via entry values. The issue is simple. The compiler emits: 0x00000000100032b8 <+28>: bl 0x1000320c <pck__create_large> 0x00000000100032bc <+32>: nop 0x00000000100032c0 <+36>: li r9,42 ... but the DWARF says: <162a> DW_AT_call_return_pc: 0x100032c0 That is, the declared return PC is one instruction past the actual return PC. This patch adds a new arch hook to handle this scenario, and implements it for PPC64. Some care is taken so that GDB will continue to work if this compiler bug is fixed. A GCC patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613336.html No check for 'nop' is done, as subsequent discussion revealed that the linker might replace this with another instruction.
2023-04-18PowerPC: fix _Float128 type output stringCarl Love1-0/+7
PowerPC supports two 128-bit floating point formats, the IBM long double and IEEE 128-bit float. The issue is the DWARF information does not distinguish between the two. There have been proposals of how to extend the DWARF information as discussed in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104194 but has not been fully implemented. GCC introduced the _Float128 internal type as a work around for the issue. The workaround is not transparent to GDB. The internal _Float128 type name is printed rather then the user specified long double type. This patch adds a new gdbarch method to allow PowerPC to detect the GCC workaround. The workaround checks for "_Float128" name when reading the base typedef from the die_info. If the workaround is detected, the type and format fields from the _Float128 typedef are copied to the long double typedef. The same is done for the complex long double typedef. This patch fixes 74 regression test failures in gdb.base/whatis-ptype-typedefs.exp on PowerPC with IEEE float 128 as the default on GCC. It fixes one regression test failure in gdb.base/complex-parts.exp. The patch has been tested on Power 10 where GCC defaults to IEEE Float 128-bit and on Power 10 where GCC defaults to the IBM 128-bit float. The patch as also been tested on X86-64 with no new regression failures.
2023-02-13Turn some value_contents functions into methodsTom Tromey1-1/+1
This turns value_contents_raw, value_contents_writeable, and value_contents_all_raw into methods on value. The remaining functions will be changed later in the series; they were a bit trickier and so I didn't include them in this patch. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn allocate_value into a static "constructor"Tom Tromey1-1/+1
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-02gdb: add supports_arch_info callback to gdbarch_registerLancelot SIX1-2/+7
In the ROCm GDB port, there are some amdgcn architectures known by BFD that we don't actually support in GDB. We don't want gdbarch_printable_names to return these architectures. gdbarch_printable_names is used for a few things: - completion of the "set architecture" command - the gdb.architecture_names function in Python - foreach-arch selftests Add an optional callback to gdbarch_register that is a predicate indicating whether the gdbarch supports the given bfd_arch_info. by default, it is nullptr, meaning that the gdbarch accepts all "mach"s for that architecture known by BFD. Change-Id: I712f94351b0b34ed1f42e5cf7fc7ba051315d860 Co-Authored-By: Simon Marchi <simon.marchi@efficios.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-05gdb: make gdbarch_alloc take ownership of the tdepSimon Marchi1-1/+1
It's currently not clear how the ownership of gdbarch_tdep objects works. In fact, nothing ever takes ownership of it. This is mostly fine because we never free gdbarch objects, and thus we never free gdbarch_tdep objects. There is an exception to that however: when initialization fails, we do free the gdbarch object that is not going to be used, and we free the tdep too. Currently, i386 and s390 do it. To make things clearer, change gdbarch_alloc so that it takes ownership of the tdep. The tdep is thus automatically freed if the gdbarch is freed. Change all gdbarch initialization functions to pass a new gdbarch_tdep object to gdbarch_alloc and then retrieve a non-owning reference from the gdbarch object. Before this patch, the xtensa architecture had a single global instance of xtensa_gdbarch_tdep. Since we need to pass a dynamically allocated gdbarch_tdep_base instance to gdbarch_alloc, remove this global instance, and dynamically allocate one as needed, like we do for all other architectures. Make the `rmap` array externally visible and rename it to the less collision-prone `xtensa_rmap` name. Change-Id: Id3d70493ef80ce4bdff701c57636f4c79ed8aea2 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-01-03Don't emit gdbarch_return_valueTom Tromey1-18/+18
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-0/+18
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-0/+8
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-30[gdb] Improve printing of float formatsTom de Vries1-4/+4
Currently, on x86_64, a little endian target, I get: ... $ gdb -q -batch -ex "maint print architecture" | grep " = floatformat" gdbarch_dump: bfloat16_format = floatformat_bfloat16_big gdbarch_dump: double_format = floatformat_ieee_double_big gdbarch_dump: float_format = floatformat_ieee_single_big gdbarch_dump: half_format = floatformat_ieee_half_big gdbarch_dump: long_double_format = floatformat_i387_ext ... which suggests big endian. This is due to this bit of code in pformat: ... /* Just print out one of them - this is only for diagnostics. */ return format[0]->name; ... Fix this by using gdbarch_byte_order to pick the appropriate index, such that we have the more accurate: ... gdbarch_dump: bfloat16_format = floatformat_bfloat16_little gdbarch_dump: half_format = floatformat_ieee_half_little gdbarch_dump: float_format = floatformat_ieee_single_little gdbarch_dump: double_format = floatformat_ieee_double_little gdbarch_dump: long_double_format = floatformat_i387_ext ... Tested on x86_64-linux.
2022-11-14PowerPC, fix support for printing the function return value for non-trivial ↵Carl Love1-0/+6
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-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-22/+11
Currently, every internal_error call must be passed __FILE__/__LINE__ explicitly, like: internal_error (__FILE__, __LINE__, "foo %d", var); The need to pass in explicit __FILE__/__LINE__ is there probably because the function predates widespread and portable variadic macros availability. We can use variadic macros nowadays, and in fact, we already use them in several places, including the related gdb_assert_not_reached. So this patch renames the internal_error function to something else, and then reimplements internal_error as a variadic macro that expands __FILE__/__LINE__ itself. The result is that we now should call internal_error like so: internal_error ("foo %d", var); Likewise for internal_warning. The patch adjusts all calls sites. 99% of the adjustments were done with a perl/sed script. The non-mechanical changes are in gdbsupport/errors.h, gdbsupport/gdb_assert.h, and gdb/gdbarch.py. Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
2022-10-17Fix null pointer representationsTaiseiIto1-9/+9
Since "NULL" and "0" are used to represent invalid address in function "gdbarch_find_by_info" in "binutils-gdb/gdb/arch-utils.c", I modified them to "nullptr".
2022-10-10Change GDB to use frame_info_ptrTom Tromey1-3/+3
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: update now gdbarch_register_name doesn't return nullptrAndrew Burgess1-2/+1
After the previous few commit, gdbarch_register_name no longer returns nullptr. This commit audits all the calls to gdbarch_register_name and removes any code that checks the result against nullptr. There should be no visible change after this commit.
2022-09-20Move solib_ops into gdbarchTom Tromey1-0/+1
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-08-16Remove register_gdbarch_initTom Tromey1-9/+1
This removes the deprecated register_gdbarch_init in favor a default argument to gdbarch_register. Regression tested on x86-64 Fedora 34.
2022-08-04Use registry in gdbarchTom Tromey1-109/+3
gdbarch implements its own registry-like approach. This patch changes it to instead use registry.h. It's a rather large patch but largely uninteresting -- it's mostly a straightforward conversion from the old approach to the new one. The main benefit of this change is that it introduces type safety to the gdbarch registry. It also removes a bunch of code. One possible drawback is that, previously, the gdbarch registry differentiated between pre- and post-initialization setup. This doesn't seem very important to me, though.
2022-08-04Use new and delete for gdbarchTom Tromey1-8/+4
This changes gdbarch to use new and delete.
2022-08-04Use bool in gdbarchTom Tromey1-1/+1
This changes gdbarch to use bool for initialized_p.
2022-07-26gdb: rename gdbarch_tdep struct to fix g++ 4.8 buildAndrew Burgess1-1/+1
After the commit: commit 08106042d9f5fdff60c129bf33190639f1a98b2a Date: Thu May 19 13:20:17 2022 +0100 gdb: move the type cast into gdbarch_tdep GDB would no longer build using g++ 4.8. The issue appears to be some confusion caused by GDB having 'struct gdbarch_tdep', but also a templated function called 'gdbarch_tdep'. Prior to the above commit the gdbarch_tdep function was not templated, and this compiled just fine. Note that the above commit compiles just fine with later versions of g++, so this issue was clearly fixed at some point, though I've not tried to track down exactly when. In this commit I propose to fix the g++ 4.8 build problem by renaming 'struct gdbarch_tdep' to 'struct gdbarch_tdep_base'. This rename better represents that the struct is only ever used as a base class, and removes the overloading of the name, which allows GDB to build with g++ 4.8. I've also updated the comment on 'struct gdbarch_tdep_base' to fix a typo, and the comment on the 'gdbarch_tdep' function, to mention that in maintainer mode a run-time type check is performed.
2022-07-21gdb: move the type cast into gdbarch_tdepAndrew Burgess1-2/+4
I built GDB for all targets on a x86-64/GNU-Linux system, and then (accidentally) passed GDB a RISC-V binary, and asked GDB to "run" the binary on the native target. I got this error: (gdb) show architecture The target architecture is set to "auto" (currently "i386"). (gdb) file /tmp/hello.rv32.exe Reading symbols from /tmp/hello.rv32.exe... (gdb) show architecture The target architecture is set to "auto" (currently "riscv:rv32"). (gdb) run Starting program: /tmp/hello.rv32.exe ../../src/gdb/i387-tdep.c:596: internal-error: i387_supply_fxsave: Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed. What's going on here is this; initially the architecture is i386, this is based on the default architecture, which is set based on the native target. After loading the RISC-V executable the architecture of the current inferior is updated based on the architecture of the executable. When we "run", GDB does a fork & exec, with the inferior being controlled through ptrace. GDB sees an initial stop from the inferior as soon as the inferior comes to life. In response to this stop GDB ends up calling save_stop_reason (linux-nat.c), which ends up trying to read register from the inferior, to do this we end up calling target_ops::fetch_registers, which, for the x86-64 native target, calls amd64_linux_nat_target::fetch_registers. After this I eventually end up in i387_supply_fxsave, different x86 based targets will end in different functions to fetch registers, but it doesn't really matter which function we end up in, the problem is this line, which is repeated in many places: i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch); The problem here is that the ARCH in this line comes from the current inferior, which, as we discussed above, will be a RISC-V gdbarch, the tdep field will actually be of type riscv_gdbarch_tdep, not i386_gdbarch_tdep. After this cast we are relying on undefined behaviour, in my case I happen to trigger an assert, but this might not always be the case. The thing I tried that exposed this problem was of course, trying to start an executable of the wrong architecture on a native target. I don't think that the correct solution for this problem is to detect, at the point of cast, that the gdbarch_tdep object is of the wrong type, but, I did wonder, is there a way that we could protect ourselves from incorrectly casting the gdbarch_tdep object? I think that there is something we can do here, and this commit is the first step in that direction, though no actual check is added by this commit. This commit can be split into two parts: (1) In gdbarch.h and arch-utils.c. In these files I have modified gdbarch_tdep (the function) so that it now takes a template argument, like this: template<typename TDepType> static inline TDepType * gdbarch_tdep (struct gdbarch *gdbarch) { struct gdbarch_tdep *tdep = gdbarch_tdep_1 (gdbarch); return static_cast<TDepType *> (tdep); } After this change we are no better protected, but the cast is now done within the gdbarch_tdep function rather than at the call sites, this leads to the second, much larger change in this commit, (2) Everywhere gdbarch_tdep is called, we make changes like this: - i386_gdbarch_tdep *tdep = (i386_gdbarch_tdep *) gdbarch_tdep (arch); + i386_gdbarch_tdep *tdep = gdbarch_tdep<i386_gdbarch_tdep> (arch); There should be no functional change after this commit. In the next commit I will build on this change to add an assertion in gdbarch_tdep that checks we are casting to the correct type.
2022-03-29Unify gdb printf functionsTom Tromey1-64/+64
Now that filtered and unfiltered output can be treated identically, we can unify the printf family of functions. This is done under the name "gdb_printf". Most of this patch was written by script.
2022-01-26Fix another crash with gdb parameters in PythonTom Tromey1-2/+3
While looking into the language-capturing issue, I found another way to crash gdb using parameters from Python: (gdb) python print(gdb.parameter('endian')) (This is related to PR python/12188, though this patch isn't going to fix what that bug is really about.) The problem here is that the global variable that underlies the "endian" parameter is initialized to NULL. However, that's not a valid value for an "enum" set/show parameter. My understanding is that, in gdb, an "enum" parameter's underlying variable must have a value that is "==" (not just strcmp-equal) to one of the values coming from the enum array. This invariant is relied on in various places. I started this patch by fixing the problem with "endian". Then I added some assertions to add_setshow_enum_cmd to try to catch other problems of the same type. This patch fixes all the problems that I found. I also looked at all the calls to add_setshow_enum_cmd to ensure that they were all included in the gdb I tested. I think they are: there are no calls in nat-* files, or in remote-sim.c; and I was trying a build with all targets, Python, and Guile enabled. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12188
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-29Use filtered output in show callbacksTom Tromey1-8/+8
"show" command callbacks, like most ordinary gdb commands, should use filtered output. I found a few that did not, so this patch changes them to use the filtered form.
2021-12-29Send arch-utils error messages to gdb_stderrTom Tromey1-4/+7
This changes arch-utils.c to send some error messages to gdb_stderr. This is part of PR gdb/7233. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=7233
2021-12-17Move ordinary gdbarch code to arch-utilsTom Tromey1-0/+488
While I think it makes sense to generate gdbarch.c, at the same time I think it is better for ordinary code to be editable in a C file -- not as a hunk of C code embedded in the generator. This patch moves this sort of code out of gdbarch.sh and gdbarch.c and into arch-utils.c, then has arch-utils.c include gdbarch.c.
2021-11-16gdb: Add aliases for read_core_file_mappings callbacksAaron Merey1-10/+5
Add aliases read_core_file_mappings_loop_ftype and read_core_file_mappings_pre_loop_ftype. Intended for use with read_core_file_mappings. Also add build_id parameter to read_core_file_mappings_loop_ftype.
2021-08-12gdb: make gdbarch_printable_names return a vectorSimon Marchi1-11/+14
I noticed that gdbarch_selftest::operator() leaked the value returned by gdbarch_printable_names. Make gdbarch_printable_names return an std::vector and update callers. That makes it easier for everyone involved, less manual memory management. Change-Id: Ia8fc028bdb91f787410cca34f10bf3c5a6da1498
2021-06-28gdb: remove gdbarch_info_initSimon Marchi1-25/+1
While reviewing another patch, I realized that gdbarch_info_init could easily be removed in favor of initializing gdbarch_info fields directly in the struct declaration. The only odd part is the union. I don't know if it's actually important for it to be zero-initialized, but I presume it is. I added a constructor to gdbarch_info to take care of that. A proper solution would be to use std::variant. Or, these could also be separate fields, the little extra space required wouldn't matter. gdb/ChangeLog: * gdbarch.sh (struct gdbarch_info): Initialize fields, add constructor. * gdbarch.h: Re-generate. * arch-utils.h (gdbarch_info_init): Remove, delete all usages. * arch-utils.c (gdbarch_info_init): Remove. Change-Id: I7502e08fe0f278d84eef1667a072e8a97bda5ab5