aboutsummaryrefslogtreecommitdiff
path: root/gdb/mips-tdep.c
AgeCommit message (Collapse)AuthorFilesLines
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-22Use std::string for disassembler optionsTom Tromey1-1/+1
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-03-22Remove some unnecessary castsTom Tromey1-6/+6
I found a few unnecessary casts when calling set_gdbarch_disassembler_options_implicit. Approved-By: John Baldwin <jhb@FreeBSD.org>
2024-02-20gdb: pass frames as `const frame_info_ptr &`Simon Marchi1-48/+48
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: 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: make get_frame_register_bytes take the next frameSimon Marchi1-3/+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_bytes take the next frameSimon Marchi1-5/+6
Similar to the previous patches, change put_frame_register_bytes to take the "next frame" instead of "this frame". Change-Id: I27bcb26573686d99b231230823cff8db6405a788 Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make put_frame_register take the next frameSimon Marchi1-2/+3
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: change value_of_register and value_of_register_lazy to take the next frameSimon Marchi1-1/+1
Some functions related to the handling of registers in frames accept "this frame", for which we want to read or write the register values, while other functions accept "the next frame", which is the frame next to that. The later is needed because we sometimes need to read register values for a frame that does not exist yet (usually when trying to unwind that frame-to-be). value_of_register and value_of_register_lazy both take "this frame", even if what they ultimately want internally is "the next frame". This is annoying if you are in a spot that currently has "the next frame" and need to call one of these functions (which happens later in this series). You need to get the previous frame only for those functions to get the next frame again. This is more manipulations, more chances of mistake. I propose to change these functions (and a few more functions in the subsequent patches) to operate on "the next frame". Things become a bit less awkward when all these functions agree on which frame they take. So, in this patch, change value_of_register_lazy and value_of_register to take "the next frame" instead of "this frame". This adds a lot of get_next_frame_sentinel_okay, but if we convert the user registers API to also use "the next frame" instead of "this frame", it will get simple again. Change-Id: Iaa24815e648fbe5ae3c214c738758890a91819cd Reviewed-By: John Baldwin <jhb@FreeBSD.org>
2023-12-14gdb: make put_frame_register take an array_viewSimon Marchi1-2/+3
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-11-29Use C++17 [[fallthrough]] attributeTom Tromey1-3/+3
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-16gdb: mips: Change E_MIPS_* to EF_MIPS_*Ying Huang1-8/+8
According to we have changed all E_MIPS_* to EF_MIPS_* in binutils and glibc, we also need to change it here to keep same style. We can refer to this commit record: https://sourceware.org/pipermail/binutils/2023-October/129904.html Approved-By: Pedro Alves <pedro@palves.net>
2023-10-10gdb: remove target_gdbarchSimon Marchi1-6/+9
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-06-03[gdb] Fix typosTom de Vries1-2/+2
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-03-28Rename "raw" to "unrelocated"Tom Tromey1-2/+2
Per an earlier discussion, this patch renames the existing "raw" APIs to use the word "unrelocated" instead.
2023-03-28Use unrelocated_addr in minimal symbolsTom Tromey1-2/+4
This changes minimal symbols to use unrelocated_addr. I believe this detected a latent bug in add_pe_forwarded_sym.
2023-03-09gdb, gdbserver, gdbsupport: fix whitespace issuesSimon Marchi1-3/+3
Replace spaces with tabs in a bunch of places. Change-Id: If0f87180f1d13028dc178e5a8af7882a067868b0
2023-02-13Turn many optimized-out value functions into methodsTom Tromey1-2/+2
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-5/+5
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 value_address and set_value_address functions into methodsTom Tromey1-1/+1
This changes the value_address and set_value_address functions to be methods of value. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-02-13Turn value_type into methodTom Tromey1-8/+8
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-01-05gdb: make gdbarch_alloc take ownership of the tdepSimon Marchi1-3/+4
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-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-25gdb: remove spurious spaces after frame_info_ptrSimon Marchi1-1/+1
Fix some whitespace issues introduced with the frame_info_ptr patch. Change-Id: I158d30d8108c97564276c647fc98283ff7b12163
2022-10-19internal_error: remove need to pass __FILE__/__LINE__Pedro Alves1-28/+23
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-48/+48
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-6/+2
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-21gdb: remove TYPE_LENGTHSimon Marchi1-56/+58
Remove the macro, replace all uses with calls to type::length. Change-Id: Ib9bdc954576860b21190886534c99103d6a47afb
2022-07-21gdb: move the type cast into gdbarch_tdepAndrew Burgess1-25/+25
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-07-21gdb/mips: rewrite show_mask_addressAndrew Burgess1-20/+17
This commit is similar to the previous commit, but in this case GDB is actually relying on undefined behaviour. Consider building GDB for all targets on x86-64/GNU-Linux, then doing this: (gdb) show mips mask-address Zeroing of upper 32 bits of 64-bit addresses is auto. The 32 bit address mask is set automatically. Currently disabled (gdb) The 'show mips mask-address' command ends up in show_mask_address in mips-tdep.c, and this function does this: mips_gdbarch_tdep *tdep = (mips_gdbarch_tdep *) gdbarch_tdep (target_gdbarch ()); Later we might pass TDEP to mips_mask_address_p. However, in my example above, on an x86-64 native target, the current target architecture will be an x86-64 gdbarch, and the tdep field within the gdbarch will be of type i386_gdbarch_tdep, not of type mips_gdbarch_tdep, as a result the cast above was incorrect, and TDEP is not pointing at what it thinks it is. I also think the current output is a little confusing, we appear to have two lines that show the same information, but using different words. The first line comes from calling deprecated_show_value_hack, while the second line is printed directly from show_mask_address. However, both of these lines are printing the same mask_address_var value. I don't think the two lines actually adds any value here. Finally, none of the text in this function is passed through the internationalisation mechanism. It would be nice to remove another use of deprecated_show_value_hack if possible, so this commit does a complete rewrite of show_mask_address. After this commit the output of the above example command, still on my x86-64 native target is: (gdb) show mips mask-address Zeroing of upper 32 bits of 64-bit addresses is "auto" (current architecture is not MIPS). The 'current architecture is not MIPS' text is only displayed when the current architecture is not MIPS. If the architecture is mips then we get the more commonly seen 'currently "on"' or 'currently "off"', like this: (gdb) set architecture mips The target architecture is set to "mips". (gdb) show mips mask-address Zeroing of upper 32 bits of 64-bit addresses is "auto" (currently "off"). (gdb) All the text is passed through the internationalisation mechanism, and we only call gdbarch_tdep when we know the gdbarch architecture is bfd_arch_mips.
2022-06-15gdb: add new base class to gdb_disassemblerAndrew Burgess1-2/+2
The motivation for this change is an upcoming Python disassembler API that I would like to add. As part of that change I need to create a new disassembler like class that contains a disassemble_info and a gdbarch. The management of these two objects is identical to how we manage these objects within gdb_disassembler, so it might be tempting for my new class to inherit from gdb_disassembler. The problem however, is that gdb_disassembler has a tight connection between its constructor, and its print_insn method. In the constructor the ui_file* that is passed in is replaced with a member variable string_file*, and then in print_insn, the contents of the member variable string_file are printed to the original ui_file*. What this means is that the gdb_disassembler class has a tight coupling between its constructor and print_insn; the class just isn't intended to be used in a situation where print_insn is not going to be called, which is how my (upcoming) sub-class would need to operate. My solution then, is to separate out the management of the disassemble_info and gdbarch into a new gdb_disassemble_info class, and make this class a parent of gdb_disassembler. In arm-tdep.c and mips-tdep.c, where we used to cast the disassemble_info->application_data to a gdb_disassembler, we can now cast to a gdb_disassemble_info as we only need to access the gdbarch information. Now, my new Python disassembler sub-class will still want to print things to an output stream, and so we will want access to the dis_asm_fprintf functionality for printing. However, rather than move this printing code into the gdb_disassemble_info base class, I have added yet another level of hierarchy, a gdb_printing_disassembler, thus the class structure is now: struct gdb_disassemble_info {}; struct gdb_printing_disassembler : public gdb_disassemble_info {}; struct gdb_disassembler : public gdb_printing_disassembler {}; In a later commit my new Python disassembler will inherit from gdb_printing_disassembler. The reason for adding the additional layer to the class hierarchy is that in yet another commit I intend to rewrite the function gdb_buffered_insn_length, and to do this I will be creating yet more disassembler like classes, however, these will not print anything, thus I will add a gdb_non_printing_disassembler class that also inherits from gdb_disassemble_info. Knowing that that change is coming, I've gone with the above class hierarchy now. There should be no user visible changes after this commit.
2022-05-10gdb: mips: Fix large-frame.exp test case failureYouling Tang1-0/+3
$ objdump -d outputs/gdb.base/large-frame/large-frame-O2 0000000120000b20 <func>: 120000b20: 67bdbff0 daddiu sp,sp,-16400 120000b24: ffbc4000 sd gp,16384(sp) 120000b28: 3c1c0002 lui gp,0x2 120000b2c: 679c8210 daddiu gp,gp,-32240 120000b30: 0399e02d daddu gp,gp,t9 120000b34: df998058 ld t9,-32680(gp) 120000b38: ffbf4008 sd ra,16392(sp) 120000b3c: 0411ffd8 bal 120000aa0 <blah> ... The disassembly of the above func function shows that we may use instructions such as daddiu/daddu, so add "daddiu $gp,$gp,n", "daddu $gp,$gp,$t9" and "daddu $gp,$t9,$gp" to the mips32_scan_prologue function to fix the large-frame.exp test case. Before applying the patch: backtrace #0 blah (a=0xfffffee220) at .../gdb/testsuite/gdb.base/large-frame-1.c:24 #1 0x0000000120000b44 in func () Backtrace stopped: frame did not save the PC (gdb) FAIL: gdb.base/large-frame.exp: optimize=-O2: backtrace # of expected passes 5 # of unexpected failures 1 After applying the patch: # of expected passes 6 Signed-off-by: Youling Tang <tangyouling@loongson.cn>
2022-04-27gdb: remove BLOCK_{START,END} macrosSimon Marchi1-2/+2
Replace with equivalent methods. Change-Id: I10a6c8a2a86462d9d4a6a6409a3f07a6bea66310
2022-04-13gdb: fix clang build failure in msymbol_is_mipsSimon Marchi1-1/+1
Building with clang++-14, I see: CXX mips-tdep.o /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] return !(MSYMBOL_TARGET_FLAG_MIPS16 (msym) ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16' (sym)->target_flag_1 () ^ /home/smarchi/src/binutils-gdb/gdb/mips-tdep.c:453:12: note: cast one or both operands to int to silence this warning /home/smarchi/src/binutils-gdb/gdb/mips-tdep.h:54:2: note: expanded from macro 'MSYMBOL_TARGET_FLAG_MIPS16' (sym)->target_flag_1 () ^ That's since commit e165fcef1e7 ("gdb: remove MSYMBOL_TARGET_FLAG_{1,2} macros"). Fix this by using the boolean || rather than the bitwise |, since the new methods return bool values. No change in behavior expected. Change-Id: Ia82664135aa25db64c29c92f5c1141859d345bf7
2022-04-11gdb: remove MSYMBOL_TARGET_FLAG_{1,2} macrosSimon Marchi1-2/+2
Replace with equivalent getter/setter macros. Change-Id: I1042564dd47347337374762bd64ec31b5c573ee2
2022-04-11gdb: remove minimal symbol size macrosSimon Marchi1-2/+2
Remove MSYMBOL_HAS_SIZE, MSYMBOL_SIZE and SET_MSYMBOL_SIZE, replace them with equivalent methods. Change-Id: I6ee1cf82df37e58dff52ea6568ceb4649c7d7538
2022-04-11gdb: remove symbol value macrosSimon Marchi1-4/+4
Remove all macros related to getting and setting some symbol value: #define SYMBOL_VALUE(symbol) (symbol)->value.ivalue #define SYMBOL_VALUE_ADDRESS(symbol) \ #define SET_SYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define SYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define SYMBOL_VALUE_COMMON_BLOCK(symbol) (symbol)->value.common_block #define SYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block #define SYMBOL_VALUE_CHAIN(symbol) (symbol)->value.chain #define MSYMBOL_VALUE(symbol) (symbol)->value.ivalue #define MSYMBOL_VALUE_RAW_ADDRESS(symbol) ((symbol)->value.address + 0) #define MSYMBOL_VALUE_ADDRESS(objfile, symbol) \ #define BMSYMBOL_VALUE_ADDRESS(symbol) \ #define SET_MSYMBOL_VALUE_ADDRESS(symbol, new_value) \ #define MSYMBOL_VALUE_BYTES(symbol) (symbol)->value.bytes #define MSYMBOL_BLOCK_VALUE(symbol) (symbol)->value.block Replace them with equivalent methods on the appropriate objects. Change-Id: Iafdab3b8eefc6dc2fd895aa955bf64fafc59ed50
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-04-06gdb: mips: Fix the handling of complex type of function return valueYouling Tang1-10/+24
$ objdump -d outputs/gdb.base/varargs/varargs 00000001200012e8 <find_max_float_real>: ... 1200013b8: c7c10000 lwc1 $f1,0(s8) 1200013bc: c7c00004 lwc1 $f0,4(s8) 1200013c0: 46000886 mov.s $f2,$f1 1200013c4: 46000046 mov.s $f1,$f0 1200013c8: 46001006 mov.s $f0,$f2 1200013cc: 46000886 mov.s $f2,$f1 1200013d0: 03c0e825 move sp,s8 1200013d4: dfbe0038 ld s8,56(sp) 1200013d8: 67bd0080 daddiu sp,sp,128 1200013dc: 03e00008 jr ra 1200013e0: 00000000 nop From the above disassembly, we can see that when the return value of the function is a complex type and len <= 2 * MIPS64_REGSIZE, the return value will be passed through $f0 and $f2, so fix the corresponding processing in mips_n32n64_return_value(). $ make check RUNTESTFLAGS='GDB=../gdb gdb.base/varargs.exp --outdir=test' Before applying the patch: FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4) FAIL: gdb.base/varargs.exp: print find_max_double_real(4, dc1, dc2, dc3, dc4) # of expected passes 9 # of unexpected failures 2 After applying the patch: # of expected passes 11 This also fixes: FAIL: gdb.base/callfuncs.exp: call inferior func with struct - returns float _Complex Signed-off-by: Youling Tang <tangyouling@loongson.cn> Co-Authored-By: Maciej W. Rozycki <macro@orcam.me.uk>
2022-03-29Unify gdb printf functionsTom Tromey1-271/+271
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-03-29Unify gdb putc functionsTom Tromey1-4/+4
Now that filtered and unfiltered output can be treated identically, we can unify the putc family of functions. This is done under the name "gdb_putc". Most of this patch was written by script.
2022-03-29Unify gdb puts functionsTom Tromey1-20/+20
Now that filtered and unfiltered output can be treated identically, we can unify the puts family of functions. This is done under the name "gdb_puts". Most of this patch was written by script.
2022-02-06gdb: remove SYMBOL_CLASS macro, add getterSimon Marchi1-1/+1
Change-Id: I83211d5a47efc0564386e5b5ea4a29c00b1fd46a
2022-01-31gdb: fix some clang-tidy readability-misleading-indentation warningsSimon Marchi1-1/+1
I have warnings like these showing in my editor all the time, so I thought I'd run clang-tidy with this diagnostic on all the files (that I can compile) and fix them. There is still one warning, in utils.c, but that's because some code is mixed up with preprocessor macros (#ifdef TUI), so I think there no good solution there. Change-Id: I345175fc7dd865318f0fbe61ac026c88c3b6a96b
2022-01-05Use filtered output in *-tdep commandsTom Tromey1-3/+3
Various targets introduce their own commands, which then use unfiltered output. It's better to use filtered output by default, so this patch fixes the instances I found.
2022-01-05Use filtered output for gdbarch dumpTom Tromey1-27/+27
This changes gdbarch dumping to use filtered output. This seems a bit better to me, both on the principle that this is an ordinary command, and because the output can be voluminous, so it may be nice to stop in the middle.
generated by cgit v1.1 at 2025-02-11 13:11:02 +0000