aboutsummaryrefslogtreecommitdiff
path: root/gdb/i386-tdep.c
AgeCommit message (Collapse)AuthorFilesLines
2024-08-12gdb: drop struct keyword when using bound_minimal_symbolSimon Marchi1-2/+1
This is a simple find / replace from "struct bound_minimal_symbol" to "bound_minimal_symbol", to make things shorter and more consisten througout. In some cases, move variable declarations where first used. Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849 Reviewed-by: Keith Seitz <keiths@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
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-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-12gdb: Deprecate MPX commands.Schimpe, Christina1-2/+4
This patch deprecates the MPX commands "show/set mpx bound". Intel listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019. Following gcc v9.1, the linux kernel v5.6 and glibc v2.35, deprecate MPX in GDB.
2024-02-20gdb: pass frames as `const frame_info_ptr &`Simon Marchi1-32/+32
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-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-12-14gdb: migrate i386 and amd64 to the new gdbarch_pseudo_register_writeSimon Marchi1-95/+51
Make i386 and amd64 use the new gdbarch_pseudo_register_write. This fixes writing to pseudo registers in non-current frames for those architectures. Change-Id: I4977e8fe12d2cef116f8834c34cdf6fec618554f Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: rename gdbarch_pseudo_register_write to ↵Simon Marchi1-1/+2
gdbarch_deprecated_pseudo_register_write The next patch introduces a new variant of gdbarch_pseudo_register_write that takes a frame instead of a regcache for implementations to write raw registers. Rename to old one to make it clear it's deprecated. Change-Id: If8872c89c6f8a1edfcab983eb064248fd5ff3115 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: read pseudo register through frameSimon Marchi1-144/+80
Change gdbarch_pseudo_register_read_value to take a frame instead of a regcache. The frame (and formerly the regcache) is used to read raw registers needed to make up the pseudo register value. The problem with using the regcache is that it always provides raw register values for the current frame (frame 0). Let's say the user wants to read the ebx register on amd64. ebx is a pseudo register, obtained by reading the bottom half (bottom 4 bytes) of the rbx register, which is a raw register. If the currently selected frame is frame 0, it works fine: (gdb) frame 0 #0 break_here_asm () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:36 36 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S (gdb) p/x $ebx $1 = 0x24252627 (gdb) p/x $rbx $2 = 0x2021222324252627 But if the user is looking at another frame, and the raw register behind the pseudo register has been saved at some point in the call stack, then we get a wrong answer: (gdb) frame 1 #1 0x000055555555517d in caller () at /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S:56 56 in /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.arch/amd64-pseudo-unwind-asm.S (gdb) p/x $ebx $3 = 0x24252627 (gdb) p/x $rbx $4 = 0x1011121314151617 Here, the value of ebx was computed using the value of rbx in frame 0 (through the regcache), it should have been computed using the value of rbx in frame 1. In other to make this work properly, make the following changes: - Make dwarf2_frame_prev_register return nullptr if it doesn't know how to unwind a register and that register is a pseudo register. Previously, it returned `frame_unwind_got_register`, meaning, in our example, "the value of ebx in frame 1 is the same as the value of ebx in frame 0", which is obviously false. Return nullptr as a way to say "I don't know". - In frame_unwind_register_value, when prev_register (for instance dwarf2_frame_prev_register) returns nullptr, and we are trying to read a pseudo register, try to get the register value through gdbarch_pseudo_register_read_value or gdbarch_pseudo_register_read. If using gdbarch_pseudo_register_read, the behavior is known to be broken. Implementations should be migrated to use gdbarch_pseudo_register_read_value to fix that. - Change gdbarch_pseudo_register_read_value to take a frame_info instead of a regcache, update implementations (aarch64, amd64, i386). In i386-tdep.c, I made a copy of i386_mmx_regnum_to_fp_regnum that uses a frame instead of a regcache. The version using the regcache is still used by i386_pseudo_register_write. It will get removed in a subsequent patch. - Add some helpers in value.{c,h} to implement the common cases of pseudo registers: taking part of a raw register and concatenating multiple raw registers. - Update readable_regcache::{cooked_read,cooked_read_value} to pass the current frame to gdbarch_pseudo_register_read_value. Passing the current frame will give the same behavior as before: for frame 0, raw registers will be read from the current thread's regcache. Notes: - I do not plan on changing gdbarch_pseudo_register_read to receive a frame instead of a regcache. That method is considered deprecated. Instead, we should be working on migrating implementations to use gdbarch_pseudo_register_read_value instead. - In frame_unwind_register_value, we still ask the unwinder to try to unwind pseudo register values. It's apparently possible for the debug info to provide information about [1] pseudo registers, so we want to try that first, before falling back to computing them ourselves. [1] https://inbox.sourceware.org/gdb-patches/20180528174715.A954AD804AD@oc3748833570.ibm.com/ Change-Id: Id6ef1c64e19090a183dec050e4034d8c2394e7ca Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make get_frame_register_bytes take the next frameSimon Marchi1-4/+4
Similar to the previous patches, change get_frame_register_bytes to take the "next frame" instead of "this frame". Change-Id: Ie8f35042bfa6e93565fcefaee71b6b3903f0fe9f Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make put_frame_register take the next frameSimon Marchi1-1/+2
Similar to the previous patches, change put_frame_register to take the "next frame" instead of "this frame". Change-Id: I062fd4663b8f54f0fc7bbf39c860b7341363821b Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make put_frame_register take an array_viewSimon Marchi1-1/+2
Change put_frame_register to take an array_view instead of a raw pointer. Add an assertion to verify that the number of bytes we try to write matches the length of the register. Change-Id: Ib75a9c8a12b47e203097621643eaa2c1830591ae Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: don't handle i386 k registers as pseudo registersSimon Marchi1-23/+0
I think that i386 k registers are raw registers, and therefore shouldn't be handled in the various functions handling pseudo registers. What tipped me off is the code in i386_pseudo_register_read_into_value: else if (i386_k_regnum_p (gdbarch, regnum)) { regnum -= tdep->k0_regnum; /* Extract (always little endian). */ status = regcache->raw_read (tdep->k0_regnum + regnum, raw_buf); We take regnum (the pseudo register number we want to read), subtract k0_regnum, add k0_regnum, and pass the result to raw_read. So we would end up calling raw_read with the same regnum as the function received which is supposedly a pseudo register number. Other hints are: - The command `maint print raw-registers` shows the k registers. - Printing $k0 doesn't cause i386_pseudo_register_read_into_value to be called. - There's code in i387-tdep.c to save/restore the k registers. Remove handling of the k registers from: - i386_pseudo_register_read_into_value - i386_pseudo_register_write - i386_ax_pseudo_register_collect Change-Id: Ic97956ed59af6099fef6d36a0b61464172694562 Reviewed-by: John Baldwin <jhb@FreeBSD.org>
2023-12-07gdb/record: Support for rdtscp in i386_process_record.Cupertino Miranda1-0/+8
This patch adds support for process recording of the instruction rdtscp in x86 architecture. Debugging applications with "record full" fail to record with the error message "Process record does not support instruction 0xf01f9". Approved-by: Guinevere Larsen <blarsen@redhat.com>
2023-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-4/+4
This changes gdb to use the C++17 [[fallthrough]] attribute rather than special comments. This was mostly done by script, but I neglected a few spellings and so also fixed it up by hand. I suspect this fixes the bug mentioned below, by switching to a standard approach that, presumably, clang supports. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23159 Approved-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com> Approved-By: Pedro Alves <pedro@palves.net>
2023-11-27i386: Use a fallback XSAVE layout for remote targetsJohn Baldwin1-0/+75
If a target provides a target description including registers from the XSAVE extended region, but does not provide an XSAVE layout, use a fallback XSAVE layout based on the included registers. This fallback layout matches GDB's behavior in earlier releases which assumes the layout from Intel CPUs. This fallback layout is currently only used for remote targets since native targets which support XSAVE provide an explicit layout derived from CPUID. PR gdb/30912 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30912 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-11-17gdb: remove get_current_regcacheSimon Marchi1-2/+1
Remove get_current_regcache, inlining the call to get_thread_regcache in callers. When possible, pass the right thread_info object known from the local context. Otherwise, fall back to passing `inferior_thread ()`. This makes the reference to global context bubble up one level, a small step towards the long term goal of reducing the number of references to global context (or rather, moving those references as close as possible to the top of the call tree). No behavior change expected. Change-Id: Ifa6980c88825d803ea586546b6b4c633c33be8d6
2023-10-27gdb: trim trailing spaces in i386-tdep.{c,h}Simon Marchi1-17/+17
Change-Id: I06c2e7c958c3451f00c70978538c1c2ad1b566df
2023-10-10gdb: remove target_gdbarchSimon Marchi1-2/+4
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-08-28gdb: Store an x86_xsave_layout in i386_gdbarch_tdep.John Baldwin1-3/+15
This structure is fetched from the current target in i386_gdbarch_init via a new "fetch_x86_xsave_layout" target method. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-06-05[gdb] Fix grammar in comments and docsTom de Vries1-1/+1
Fix grammar in some comments and docs: - machines that doesn't -> machines that don't - its a -> it's a - its the -> it's the - if does its not -> if it does it's not - one more instructions if doesn't match -> one more instruction if it doesn't match - it's own -> its own - it's first -> its first - it's pointer -> its pointer I also came across "it's performance" in gdb/stubs/*-stub.c in the HP public domain notice, I've left that alone. Tested on x86_64-linux.
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-05-01Replace field_is_static with a methodTom Tromey1-1/+1
This changes field_is_static to be a method on struct field, and updates all the callers. Most of this patch was written by script. Regression tested on x86-64 Fedora 36.
2023-04-06gdb: fix reg corruption from displaced stepping on amd64Andrew Burgess1-12/+12
This commit aims to address a problem that exists with the current approach to displaced stepping, and was identified in PR gdb/22921. Displaced stepping is currently supported on AArch64, ARM, amd64, i386, rs6000 (ppc), and s390. Of these, I believe there is a problem with the current approach which will impact amd64 and ARM, and can lead to random register corruption when the inferior makes use of asynchronous signals and GDB is using displaced stepping. The problem can be found in displaced_step_buffers::finish in displaced-stepping.c, and is this; after GDB tries to perform a displaced step, and the inferior stops, GDB classifies the stop into one of two states, either the displaced step succeeded, or the displaced step failed. If the displaced step succeeded then gdbarch_displaced_step_fixup is called, which has the job of fixing up the state of the current inferior as if the step had not been performed in a displaced manner. This all seems just fine. However, if the displaced step is considered to have not completed then GDB doesn't call gdbarch_displaced_step_fixup, instead GDB remains in displaced_step_buffers::finish and just performs a minimal fixup which involves adjusting the program counter back to its original value. The problem here is that for amd64 and ARM setting up for a displaced step can involve changing the values in some temporary registers. If the displaced step succeeds then this is fine; after the step the temporary registers are restored to their original values in the architecture specific code. But if the displaced step does not succeed then the temporary registers are never restored, and they retain their modified values. In this context a temporary register is simply any register that is not otherwise used by the instruction being stepped that the architecture specific code considers safe to borrow for the lifetime of the instruction being stepped. In the bug PR gdb/22921, the amd64 instruction being stepped is an rip-relative instruction like this: jmp *0x2fe2(%rip) When we displaced step this instruction we borrow a register, and modify the instruction to something like: jmp *0x2fe2(%rcx) with %rcx having its value adjusted to contain the original %rip value. Now if the displaced step does not succeed, then %rcx will be left with a corrupted value. Obviously corrupting any register is bad; in the bug report this problem was spotted because %rcx is used as a function argument register. And finally, why might a displaced step not succeed? Asynchronous signals provides one reason. GDB sets up for the displaced step and, at that precise moment, the OS delivers a signal (SIGALRM in the bug report), the signal stops the inferior at the address of the displaced instruction. GDB cancels the displaced instruction, handles the signal, and then tries again with the displaced step. But it is that first cancellation of the displaced step that causes the problem; in that case GDB (correctly) sees the displaced step as having not completed, and so does not perform the architecture specific fixup, leaving the register corrupted. The reason why I think AArch64, rs600, i386, and s390 are not effected by this problem is that I don't believe these architectures make use of any temporary registers, so when a displaced step is not completed successfully, the minimal fix up is sufficient. On amd64 we use at most one temporary register. On ARM, looking at arm_displaced_step_copy_insn_closure, we could modify up to 16 temporary registers, and the instruction being displaced stepped could be expanded to multiple replacement instructions, which increases the chances of this bug triggering. This commit only aims to address the issue on amd64 for now, though I believe that the approach I'm proposing here might be applicable for ARM too. What I propose is that we always call gdbarch_displaced_step_fixup. We will now pass an extra argument to gdbarch_displaced_step_fixup, this a boolean that indicates whether GDB thinks the displaced step completed successfully or not. When this flag is false this indicates that the displaced step halted for some "other" reason. On ARM GDB can potentially read the inferior's program counter in order figure out how far through the sequence of replacement instructions we got, and from that GDB can figure out what fixup needs to be performed. On targets like amd64 the problem is slightly easier as displaced stepping only uses a single replacement instruction. If the displaced step didn't complete the GDB knows that the single instruction didn't execute. The point is that by always calling gdbarch_displaced_step_fixup, each architecture can now ensure that the inferior state is fixed up correctly in all cases, not just the success case. On amd64 this ensures that we always restore the temporary register value, and so bug PR gdb/22921 is resolved. In order to move all architectures to this new API, I have moved the minimal roll-back version of the code inside the architecture specific fixup functions for AArch64, rs600, s390, and ARM. For all of these except ARM I think this is good enough, as no temporaries are used all that's needed is the program counter restore anyway. For ARM the minimal code is no worse than what we had before, though I do consider this architecture's displaced-stepping broken. I've updated the gdb.arch/amd64-disp-step.exp test to cover the 'jmpq*' instruction that was causing problems in the original bug, and also added support for testing the displaced step in the presence of asynchronous signal delivery. I've also added two new tests (for amd64 and i386) that check that GDB can correctly handle displaced stepping over a single instruction that branches to itself. I added these tests after a first version of this patch relied too much on checking the program-counter value in order to see if the displaced instruction had executed. This works fine in almost all cases, but when an instruction branches to itself a pure program counter check is not sufficient. The new tests expose this problem. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22921 Approved-By: Pedro Alves <pedro@palves.net>
2023-03-29gdb: move displaced_step_dump_bytes into gdbsupport (and rename)Andrew Burgess1-1/+1
It was pointed out during review of another patch that the function displaced_step_dump_bytes really isn't specific to displaced stepping, and should really get a more generic name and move into gdbsupport/. This commit does just that. The function is renamed to bytes_to_string and is moved into gdbsupport/common-utils.{cc,h}. The function implementation doesn't really change. Much... ... I have updated the function to take an array view, which makes it slightly easier to call in a couple of places where we already have a gdb::bytes_vector. I've then added an inline wrapper to convert a raw pointer and length into an array view, which is used in places where we don't easily have a gdb::bytes_vector (or similar). Updated all users of displaced_step_dump_bytes. There should be no user visible changes after this commit. Finally, I ended up having to add an include of gdb_assert.h into array-view.h. When I include array-view.h into common-utils.h I ran into build problems because array-view.h calls gdb_assert. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-03-09gdb, gdbserver, gdbsupport: fix whitespace issuesSimon Marchi1-1/+1
Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-02-20[gdb/tdep] Add amd64/i386 epilogue override unwindersTom de Vries1-7/+52
For amd64 the current frame-unwinders are: ... $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders" The target architecture is set to "i386:x86-64". dummy DUMMY_FRAME dwarf2 tailcall TAILCALL_FRAME inline INLINE_FRAME python NORMAL_FRAME amd64 epilogue NORMAL_FRAME dwarf2 NORMAL_FRAME dwarf2 signal SIGTRAMP_FRAME amd64 sigtramp SIGTRAMP_FRAME amd64 prologue NORMAL_FRAME ... For a -g0 -fasynchronous-unwind-tables exec (without .debug_info but with .eh_frame section), we'd like to start using the dwarf2 unwinder instead of the "amd64 epilogue" unwinder, by returning true in compunit_epilogue_unwind_valid for cust == nullptr. But we'd run into the following problem for a -g0 -fno-asynchronous-unwind-tables (without .debug_info and .eh_frame section) exec: - the "amd64 epilogue" unwinder would not run (because compunit_epilogue_unwind_valid () == true) - the dwarf2 unwinder would also not run (because there's no .eh_frame info). Fix this by: - renaming the "amd64 epilogue" unwinder to "amd64 epilogue override", and - adding a fallback "amd64 epilogue" after the dwarf unwinders, while making sure that only one of the two is active. Likewise for i386. NFC. For amd64, this results in this change: ... $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders" The target architecture is set to "i386:x86-64". dummy DUMMY_FRAME dwarf2 tailcall TAILCALL_FRAME inline INLINE_FRAME python NORMAL_FRAME -amd64 epilogue NORMAL_FRAME +amd64 epilogue override NORMAL_FRAME dwarf2 NORMAL_FRAME dwarf2 signal SIGTRAMP_FRAME +amd64 epilogue NORMAL_FRAME amd64 sigtramp SIGTRAMP_FRAME amd64 prologue NORMAL_FRAME ... And for i386: ... $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders" The target architecture is set to "i386". dummy DUMMY_FRAME dwarf2 tailcall TAILCALL_FRAME iline INLINE_FRAME -i386 epilogue NORMAL_FRAME +i386 epilogue override NORMAL_FRAME dwarf2 NORMAL_FRAME dwarf2 signal SIGTRAMP_FRAME +i386 epilogue NORMAL_FRAME i386 stack tramp NORMAL_FRAME i386 sigtramp SIGTRAMP_FRAME i386 prologue NORMAL_FRAME ...
2023-02-20[gdb/tdep] Fix amd64/i386_stack_frame_destroyed_pTom de Vries1-8/+12
The use of compunit_epilogue_unwind_valid in both amd64_stack_frame_destroyed_p and i386_stack_frame_destroyed_p is problematic, in the sense that the functions no longer match their documented behaviour. Fix this by moving the use of compunit_epilogue_unwind_valid to amd64_epilogue_frame_sniffer and i386_epilogue_frame_sniffer. No functional changes.
2023-02-20[gdb/symtab] Factor out compunit_epilogue_unwind_validTom de Vries1-3/+1
Factor out compunit_epilogue_unwind_valid from both amd64_stack_frame_destroyed_p and i386_stack_frame_destroyed_p. No functional changes. Also add a comment in the new function about the assumption that in absence of producer information, epilogue unwind info is invalid. Approved-By: Tom Tromey <tom@tromey.com>
2023-02-15gdb, fortran: Fix quad floating-point type for ifort compiler.Felix Willgerodt1-1/+3
I fixed this a while ago for ifx, one of the two Intel compilers, in 8d624a9d8050ca96e154215c7858ac5c2d8b0b19. Apparently I missed that the older ifort Intel compiler actually emits slightly different debug info again: 0x0000007a: DW_TAG_base_type DW_AT_byte_size (0x20) DW_AT_encoding (DW_ATE_complex_float) DW_AT_name ("COMPLEX(16)") 0x00000081: DW_TAG_base_type DW_AT_byte_size (0x10) DW_AT_encoding (DW_ATE_float) DW_AT_name ("REAL(16)") This fixes two failures in gdb.fortran/complex.exp with ifort. Approved-By: Tom Tromey <tom@tromey.com>
2023-02-13Introduce set_lval method on valueTom Tromey1-1/+1
This introduces the set_lval method on value, one step toward removing deprecated_lval_hack. Ultimately I think the goal should be for some of these set_* methods to be replaced with constructors; but I haven't done this, as the series is already too long. Other 'deprecated' methods can probably be handled the same way. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn many optimized-out value functions into methodsTom Tromey1-17/+17
This turns many functions that are related to optimized-out or availability-checking to be methods of value. The static function value_entirely_covered_by_range_vector is also converted to be a private method. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn remaining value_contents functions into methodsTom Tromey1-2/+2
This turns the remaining value_contents functions -- value_contents, value_contents_all, value_contents_for_printing, and value_contents_for_printing_const -- into methods of value. It also converts the static functions require_not_optimized_out and require_available to be private methods. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn some value_contents functions into methodsTom Tromey1-2/+2
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-2/+2
This changes allocate_value to be a static "constructor" of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_enclosing_type into methodTom Tromey1-3/+3
This changes value_enclosing_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn deprecated_set_value_type into a methodTom Tromey1-1/+1
This changes deprecated_set_value_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_type into methodTom Tromey1-3/+3
This changes value_type to be a method of value. Much of this patch was written by script. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-11[gdb/tdep] Don't use i386 unwinder for amd64Tom de Vries1-4/+8
For i386 we have these unwinders: ... $ gdb -q -batch -ex "set arch i386" -ex "maint info frame-unwinders" The target architecture is set to "i386". dummy DUMMY_FRAME dwarf2 tailcall TAILCALL_FRAME inline INLINE_FRAME i386 epilogue NORMAL_FRAME dwarf2 NORMAL_FRAME dwarf2 signal SIGTRAMP_FRAME i386 stack tramp NORMAL_FRAME i386 sigtramp SIGTRAMP_FRAME i386 prologue NORMAL_FRAME ... and for amd64: ... $ gdb -q -batch -ex "set arch i386:x86-64" -ex "maint info frame-unwinders" The target architecture is set to "i386:x86-64". dummy DUMMY_FRAME dwarf2 tailcall TAILCALL_FRAME inline INLINE_FRAME python NORMAL_FRAME amd64 epilogue NORMAL_FRAME i386 epilogue NORMAL_FRAME dwarf2 NORMAL_FRAME dwarf2 signal SIGTRAMP_FRAME amd64 sigtramp SIGTRAMP_FRAME amd64 prologue NORMAL_FRAME i386 stack tramp NORMAL_FRAME i386 sigtramp SIGTRAMP_FRAME i386 prologue NORMAL_FRAME ... ISTM me there's no reason for the i386 unwinders to be there for amd64. Furthermore, there's a generic need to play around with enabling and disabling unwinders, see PR8434. Currently, that's only available for both the dwarf2 unwinders at once using "maint set dwarf unwinders on/off". If I manually disable the "amd64 epilogue" unwinder, the "i386 epilogue" unwinder becomes active and gives the wrong answer, while I'm actually interested in the result of the dwarf2 unwinder. Of course I can also manually disable the "i386 epilogue", but I take the fact that I have to do that as evidence that on amd64, the "i386 epilogue" is not only unnecessary, but in the way. Fix this by only adding the i386 unwinders if "info.bfd_arch_info->bits_per_word == 32". Note that the x32 abi (x86_64/-mx32): - has the same unwinder list as amd64 (x86_64/-m64) before this commit, - has info.bfd_arch_info->bits_per_word == 64, the same as amd64, and consequently, - has the same unwinder list as amd64 after this commit. Tested on x86_64-linux, -m64 and -m32. Not tested with -mx32. Reviewed-By: John Baldwin <jhb@freebsd.org> PR tdep/30102 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30102
2023-01-05gdb: make gdbarch_alloc take ownership of the tdepSimon Marchi1-4/+3
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-03Fix inferior calls with variably-sized return typeTom Tromey1-12/+10
This patch updates the gdbarch_return_value_as_value implementations to work correctly with variably-sized return types.
2023-01-03Convert selected architectures to gdbarch_return_value_as_valueTom Tromey1-5/+16
This converts a few selected architectures to use gdbarch_return_value_as_value rather than gdbarch_return_value. The architectures are just the ones that I am able to test. This patch should not introduce any behavior changes.
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-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-9/+7
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-10Change GDB to use frame_info_ptrTom Tromey1-27/+27
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-09-21gdb: remove TYPE_LENGTHSimon Marchi1-24/+24
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-09-21gdb: remove TYPE_TARGET_TYPESimon Marchi1-1/+1
Remove the macro, replace all uses by calls to type::target_type. Change-Id: Ie51d3e1e22f94130176d6abd723255282bb6d1ed
2022-08-16Remove register_gdbarch_initTom Tromey1-1/+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-03Use gdb_bfd_ref_ptr in objfileTom Tromey1-3/+4
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to removing some manual memory management, this fixes a use-after-free that was introduced by the registry rewrite series. The issue there was that, in some cases, registry shutdown could refer to memory that had already been freed. This help fix the bug by delaying the destruction of the BFD reference (and thus the per-bfd object) until after the registry has been shut down.
generated by cgit v1.1 at 2024-12-25 21:29:20 +0000