aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-01-22gdb: move remote_debug to remote.{h,c}Simon Marchi6-7/+17
remote_debug is currently declared in target.h and defined in top.c. Move them to remote.h and remote.c. Include remote.h in remote-sim.c, as it uses remote_debug. gdb/ChangeLog: * target.h (remote_debug): Move to... * remote.h (remote_debug): ... here. * top.c (remote_debug): Move to... * remote.c (remote_debug): ... here. * remote-sim.c: Include remote.h. Change-Id: Iae632d12ff8900b23eee6b2529d6a3cd339a8caa
2021-01-22gdb: move set remote commands to remote.cSimon Marchi3-36/+45
Commands "set debug remote" and "set remotetimeout" are defined in cli/cli-cmds.c, I think it would make more sense for them to be in remote.c. gdb/ChangeLog: * cli/cli-cmds.c (show_remote_debug): Remove. (show_remote_timeout): Remove. (_initialize_cli_cmds): Don't register commands. * remote.c (show_remote_debug): Move here. (show_remote_timeout): Move here. (_initialize_remote): Register commands. Change-Id: Ic4d81888aa4f8dde89d1d29397ef19a08951b80b
2021-01-22gdb: remove TYPE_OBJFILE macroSimon Marchi9-35/+35
Change all users to use the type::objfile method instead. gdb/ChangeLog: * gdbtypes.h (TYPE_OBJFILE): Remove, change all users to use the type::objfile method instead. Change-Id: I6b3f580913fb1fb0cf986b176dba8db68e1fabf9
2021-01-22gdb: remove TYPE_OBJFILE_OWNED macroSimon Marchi6-15/+19
Update all users to use the type::is_objfile_owned method. gdb/ChangeLog: * gdbtypes.h (TYPE_OBJFILE_OWNED): Remove, update all users to use the type::is_objfile_owned method. Change-Id: Icae84d136393ab9f756f50a33ac3cedda13c5ba2
2021-01-22gdb: add owner-related methods to struct typeSimon Marchi6-32/+104
Add the following methods to struct type: * is_objfile_owned * set_owner (objfile and gdbarch overloads) * objfile and arch getters Rename the fields in main_type to ensure no other code accesses them directly. As usual, we can't make them actually private, but giving them the `m_` prefix will help making sure they are not accessed when not supposed to, by convention. Remove the TYPE_OWNER macro to ensure no code uses the type_owner struct directly. gdb/ChangeLog: * gdbtypes.h (TYPE_OBJFILE_OWNED): Adjust. (TYPE_OWNER): Remove. (TYPE_OBJFILE): Adjust. (struct main_type) <flag_objfile_owned>: Rename to... <m_flag_objfile_owned>: ... this. <owner>: Rename to... <m_owner>: ... this. (struct type) <is_objfile_owned, set_owner, objfile, arch>: New methods. (TYPE_ALLOC): Adjust. * gdbtypes.c (alloc_type): Adjust. (alloc_type_arch): Adjust. (alloc_type_copy): Adjust. (get_type_arch): Adjust. (smash_type): Adjust. (lookup_array_range_type): Adjust. (recursive_dump_type): Adjust. (copy_type_recursive): Adjust. * compile/compile-c-types.c (convert_func): Adjust. (convert_type_basic): Adjust. * compile/compile-cplus-types.c (compile_cplus_convert_func): Adjust. * language.c (language_arch_info::type_and_symbol::alloc_type_symbol): Adjust. Change-Id: I7f92e869d9f92e2402a3d3007dd0832e05aa6ac8
2021-01-22gdb/doc: move @menu to the end of the nodeAndrew Burgess2-4/+8
Commit: commit a72d0f3d69896b5fcdc916e0547fe774dcb58614 Date: Tue Jan 12 13:02:30 2021 +0000 gdb/doc: reorder and group sections relating to aliases Added a @menu block into the wrong place within a @node. This commit moves it to the end of the @node, where it should be been placed. gdb/doc/ChangeLog: * gdb.texinfo (Aliases): Move @menu to the end of the node.
2021-01-22gdb/doc: down case contents of @varAndrew Burgess2-2/+6
After a discussion on a recent patch it was pointed out that the contents of a @var should (generally) be lower case. I took a look through the GDB manual and there are a small number of places where the contents are currently upper case, but one in particular seemed like an obvious candidate for being down cased, so lets do that. gdb/doc/ChangeLog: * gdb.texinfo (PowerPC Embedded): Down case contents of @var.
2021-01-22MAINTAINERS: Update my e-mail addressMaciej W. Rozycki1-2/+2
binutils/ * MAINTAINERS: Update my e-mail address. gdb/ * MAINTAINERS: Update my e-mail address. sim/ * MAINTAINERS: Update my e-mail address.
2021-01-21Handle additional connection errorLuis Machado2-0/+8
On Ubuntu 18.04/20.04 I was running into annoying timeouts for gdb.server/server-connect.exp. Those were caused by the ipv6 tests, because they were running into the "Cannot assign requested address" error, originated from the connect syscall. Improve this by handling this additional error in the testsuite library. It still fails for me, but at least it fails pretty quickly and doesn't make the testsuite run take longer. gdb/testsuite/ChangeLog: 2021-01-21 Luis Machado <luis.machado@linaro.org> * lib/gdbserver-support.exp (gdb_target_cmd_ext): Handle a new error message.
2021-01-21Fix build errors for armhfLuis Machado3-4/+11
When building for 32-bit ARM, I ran into a couple build failures. The first one seems to be caused by recent changes to warning switches, leading to the following error: -- In file included from gdb/coffread.c:35:0: gdb/coffread.c: In function "void enter_linenos(file_ptr, int, int, objfile*)": gdb/complaints.h:40:40: error: format "%ld" expects argument of type "long int", but argument 2 has type "file_ptr {aka long long int}" [-Werror=format=] complaint_internal (FMT, ##__VA_ARGS__); \ ^ gdb/coffread.c:1413:7: note: in expansion of macro "complaint" complaint (_("Line number pointer %ld lower than start of line numbers"), ^~~~~~~~~ -- The other one is due to a narrowing conversion in valops.c: -- gdb/valops.c: In function "value* value_assign(value*, value*)": gdb/gdbtypes.h:1798:43: error: narrowing conversion of "type->type::length" from "ULONGEST {aka long long unsigned int}" to "size_t {aka unsigned int}" inside { } [-Werror=narrowing] #define TYPE_LENGTH(thistype) (thistype)->length ~~~~~~~~~~~~^ gdb/valops.c:1252:9: note: in expansion of macro "TYPE_LENGTH" TYPE_LENGTH (type)}); -- Fix both with the following patch. Validated with --enable-targets=all on Ubuntu 18.04/20.04. gdb/ChangeLog: 2021-01-21 Luis Machado <luis.machado@linaro.org> * coffread.c (enter_linenos): Passing string to complaint. * valops.c (value_assign): Make array view.
2021-01-21gdb: convert auto-load to new-style debug macrosSimon Marchi5-102/+92
Function file_is_auto_load_safe was taking a format string and varargs just to output a debug print. This is probably because that function is used in linux-thread-db.c and main.c, but debug_auto_load is static in auto-load.c. I simplified that, making debug_auto_load visible outside of auto-load.c, and making the callers of file_is_auto_load_safe output the debug print themselves. This file uses _() for internationalization of the debug messages. This is not necessary, as these are mostly messages for GDB developers, and it's not used in other files anyway. So I removed them. The rest is pretty much standard. gdb/ChangeLog: * auto-load.h (debug_auto_load): Move here. (auto_load_debug_printf): New. * auto-load.c: Use auto_load_debug_printf. (debug_auto_load): Move to header. * linux-thread-db.c (try_thread_db_load): Use auto_load_debug_printf. * main.c (captured_main_1): Likewise. Change-Id: I468dc2a1d24b7dbf171f55181a11abbfafe70ba1
2021-01-21gdb: remove unused f77_array_offset_tbl from f-valprint.cSimon Marchi2-5/+4
This variable appears to be unused. Its uses were removed in commit 3e2e34f8623d ("fort_dyn_array: Use value constructor instead of raw-buffer manipulation.") back in 2016. gdb/ChangeLog: * f-valprint.c (f77_array_offset_tbl): Remove. Change-Id: I39ff8d1b402e54ca2ade936f65e540f500cce86e
2021-01-21gdb: convert bfd-cache to new-style debug macrosSimon Marchi2-29/+25
gdb/ChangeLog: * gdb_bfd.c (bfd_cache_debug_printf): New, use throughout file. Change-Id: Ie29948d82adfae7edb3cdcbd61f59a66892fcc99
2021-01-21gdb: use interruptible_select when connecting to a remoteSimon Marchi2-1/+6
When GDB is waiting trying to connect to a remote target and it receives a SIGWINCH (terminal gets resized), the blocking system call gets interrupted and we abort. For example, I connect to some port (on which nothing listens): (gdb) tar rem :1234 ... GDB blocks here, resize the terminal ... :1234: Interrupted system call. The backtrace where GDB is blocked while waiting for the connection to establish is: #0 0x00007fe9db805b7b in select () from /usr/lib/libc.so.6 #1 0x000055f2472e9c42 in gdb_select (n=0, readfds=0x0, writefds=0x0, exceptfds=0x0, timeout=0x7ffe8fafe050) at /home/simark/src/binutils-gdb/gdb/posix-hdep.c:31 #2 0x000055f24759c212 in wait_for_connect (sock=-1, polls=0x7ffe8fafe300) at /home/simark/src/binutils-gdb/gdb/ser-tcp.c:147 #3 0x000055f24759d0e8 in net_open (scb=0x62500015b900, name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/ser-tcp.c:356 #4 0x000055f2475a0395 in serial_open_ops_1 (ops=0x55f24892ca60 <tcp_ops>, open_name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/serial.c:244 #5 0x000055f2475a01d6 in serial_open (name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/serial.c:231 #6 0x000055f2474d5274 in remote_serial_open (name=0x6020000601d8 ":1234") at /home/simark/src/binutils-gdb/gdb/remote.c:5019 #7 0x000055f2474d7025 in remote_target::open_1 (name=0x6020000601d8 ":1234", from_tty=1, extended_p=0) at /home/simark/src/binutils-gdb/gdb/remote.c:5571 #8 0x000055f2474d47d5 in remote_target::open (name=0x6020000601d8 ":1234", from_tty=1) at /home/simark/src/binutils-gdb/gdb/remote.c:4898 #9 0x000055f24776379f in open_target (args=0x6020000601d8 ":1234", from_tty=1, command=0x611000042bc0) at /home/simark/src/binutils-gdb/gdb/target.c:242 Fix that by using interruptible_select in wait_for_connect, instead of gdb_select. Resizing the terminal now no longer aborts the connection. It is still possible to interrupt the connection using ctrl-c. gdb/ChangeLog: * ser-tcp.c (wait_for_connect): Use interruptible_select instead of gdb_select. Change-Id: Ie25577bd1e5699e4847b6b53fdfa10b8c0dc5c89
2021-01-21gdb/testsuite: improve logging in lib/tuiterm.expSimon Marchi2-171/+281
Here's a bonus patch that applies on top of the other two. While debugging TUI test cases, it's hard to know what exactly is happening in the little mind of the terminal emulator. Add some logging for all input processing. Right now I'm interested in seeing what happens to the cursor position, so made it so all operations log the "before" and "after" cursor position. It should help see if any operation is not behaving as expected, w.r.t. the cursor position. Here are some examples of the logging found in gdb.log with this patch applied: +++ Inserting string '+|' +++ Inserted char '+', cursor: (0, 79) -> (1, 0) +++ Inserted char '|', cursor: (1, 0) -> (1, 1) +++ Inserted string '+|', cursor: (0, 79) -> (1, 1) +++ Cursor Horizontal Absolute (80), cursor: (1, 1) -> (1, 79) In the last line, note that the argument is 80 and we move to 79, that's because the position in the argument to the control sequence is 1-based, while our indexing is 0-based. gdb/testsuite/ChangeLog: * lib/tuiterm.exp (_log, _log_cur): New, use throughout. Change-Id: Ibf570d4b2867729ce65bea8c193343a8a846170d
2021-01-21gdb/doc: reorder and group sections relating to aliasesAndrew Burgess2-189/+204
This started by observing that the section name: Automatically prepend default arguments to user-defined aliases Is very long. When this is rendered in the PDF manual (at least for me), this name is so long that in the table of contents the page number ends up being misaligned. My first thought was we could drop the 'to user-defined aliases' bit if this section became a sub-section of the section on aliases. So then I looked for a section with 'aliases' in its name, and couldn't find one. It turns out that aliases are documented in a section called: Creating new spellings of existing commands Which (to me) seems an odd aspect of aliases to emphasise. So, in this patch I make the following changes: - Move the section on aliases earlier in the manual, this is now immediately after the section about creating user defined commands. This made more sense to me. - Rename the section on aliases from 'Creating new spellings of existing commands' to 'Command Aliases'. - Update the wording of the first paragraph in the 'Command Aliases' section so that it reads better given the new name. - Add a cross-reference from the 'Command Aliases' section to the 'Python' section now that the aliases section comes first. - Down case all the text inside @var within this section as this is the correct style for the GDB manual. - Move the section on default args to become a sub-section of the 'Command Aliases' section, and rename this sub-section from 'Automatically prepend default arguments to user-defined aliases' to 'Default Arguments'. - Add @menu into the 'Command Aliases' section to link to the 'Default Arguments' subsection. - Add a @cindex entry to the default arguments sub-section. gdb/doc/ChangeLog: * gdb.texinfo (Commands): Update menu. (Extending GDB): Likewise. (Command aliases default args): Moved later into the document, added a cindex entry. Renamed the section 'Automatically prepend default arguments to user-defined aliases' to 'Default Arguments'. (Aliases): Moved earlier in the document. Minor rewording of the first paragraph, down-cased the text inside all uses of @var, and added a cross reference to the Python code. Renamed the section 'Creating new spellings of existing commands' to 'Command Aliases'.
2021-01-21Add Python support for hardware breakpointsHannes Domani6-2/+53
This allows the creation of hardware breakpoints in Python with gdb.Breakpoint(type=gdb.BP_HARDWARE_BREAKPOINT) And they are included in the sequence returned by gdb.breakpoints(). gdb/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * python/py-breakpoint.c (bppy_get_location): Handle bp_hardware_breakpoint. (bppy_init): Likewise. (gdbpy_breakpoint_created): Likewise. gdb/doc/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * python.texi (Breakpoints In Python): Document gdb.BP_HARDWARE_BREAKPOINT. gdb/testsuite/ChangeLog: 2021-01-21 Hannes Domani <ssbssa@yahoo.de> PR python/19151 * gdb.python/py-breakpoint.exp: Add tests for hardware breakpoints.
2021-01-21gdb: convert arm to new-style debug macrosSimon Marchi2-19/+23
gdb/ChangeLog: * arm-tdep.c (arm_debug_printf): Add and use throughout file. Change-Id: Iec5c2955cb79d8c0288ffded2c8a58b7eb7e3554
2021-01-20gdb: change debug_bfd_cache to boolSimon Marchi2-9/+16
gdb/ChangeLog: * gdb_bfd.c (debug_bfd_cache): Change type to bool. (_initialize_gdb_bfd): Adjust. Change-Id: I90fdcc2e2d405653d0eba776f316bcec361b2d18
2021-01-20gdb/testsuite: use multi_line in gdb.base/skip.expSimon Marchi1-30/+30
This will make it easier to modify, in particular add some indentation. It is also a bit nicer to read, in my opinion. gdb/testsuite/ChangeLog; * gdb.base/skip.exp: Use multi_line where relevant. Change-Id: Ia11712aac77344e0b8a836f4181d67e1cad3826c
2021-01-20gdb/dwarf: add assertion in maybe_queue_comp_unitSimon Marchi2-1/+11
The symptom that leads to this is the crash described in PR 26828: /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:23478:25: runtime error: member access within null pointer of type 'struct dwarf2_cu' The line of the crash is the following, in follow_die_offset: if (target_cu != cu) target_cu->ancestor = cu; <--- HERE The line that assign nullptr to `target_cu` is the `per_objfile->get_cu` call after having called maybe_queue_comp_unit: /* If necessary, add it to the queue and load its DIEs. */ if (maybe_queue_comp_unit (cu, per_cu, per_objfile, cu->language)) load_full_comp_unit (per_cu, per_objfile, per_objfile->get_cu (per_cu), false, cu->language); target_cu = per_objfile->get_cu (per_cu); <--- HERE Some background: there is an invariant, documented in maybe_queue_comp_unit's doc, that if a CU is queued for expansion (present in dwarf2_per_bfd::queue), then its DIEs are loaded in memory. "its DIEs are loaded in memory" is a synonym for saying that a dwarf2_cu object exists for this CU. Yet another way to say it is that `per_objfile->get_cu (per_cu)` returns something not nullptr for that CU. The crash documented in PR 26828 triggers some hard-to-reproduce sequence that ends up violating the invariant: - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A - The DIE in CU A requires some DIE in CU B - follow_die_offset calls maybe_queue_comp_unit. maybe_queue_comp_unit sees CU B is not queued and its DIEs are not loaded, so it enqueues it and returns 1 to its caller - meaning "the DIEs are not loaded, you should load them" - prompting follow_die_offset to load the DIEs by calling load_full_comp_unit - Note that CU B is enqueued by maybe_queue_comp_unit even if it has already been expanded. It's a bit useless (and causes trouble, see next patch), but that's how it works right now. - Since we entered the dwarf2/read code through dwarf2_fetch_die_type_sect_off, nothing processes the queue, so we exit the dwarf2/read code with CU B still lingering in the queue. - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again - The DIE in CU A requires some DIE in CU B, again - This time, maybe_queue_comp_unit sees that CU B is in the queue. Because of the invariant that if a CU is in the queue, its DIEs are loaded in the memory, it returns 0 to its caller, meaning "you don't need to load the DIEs!". - That happens to be true, so everything is fine for now. - Time passes, some things call dwarf2_per_objfile::age_comp_units enough so that CU B's age becomes past the dwarf_max_cache_age threshold. age_comp_units proceeds to free CU B's DIEs. Remember that CU B is still lingering in the queue (oops, the invariant just got violated). - dwarf2_fetch_die_type_sect_off gets called for a DIE in CU A, again - The DIE in CU A requires some DIE in CU B, again - maybe_queue_comp_unit sees that CU B is in the queue, so returns to its caller "you don't need to load the DIEs!". However, we know at this point this is false. - follow_die_offset doesn't load the DIEs and tries to obtain the DIEs for CU B: target_cu = per_objfile->get_cu (per_cu); But since they are not loaded, target_cu is nullptr, and we get the crash mentioned above a few lines after that. This patch adds an assertions in maybe_queue_comp_unit to verify the invariant, to make sure it doesn't return a falsehood to its caller. The current patch doesn't fix the issue (the next patch does), but it makes it so we catch the problem earlier and get this assertion failure instead of a segmentation fault: /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9100: internal-error: int maybe_queue_comp_unit(dwarf2_cu*, dwarf2_per_cu_data*, dwarf2_per_objfile*, language): Assertion `per_objfile->get_cu (per_cu) != nullptr' failed. gdb/ChangeLog: PR gdb/26828 * dwarf2/read.c (maybe_queue_comp_unit): Add assertion. Change-Id: I4e51bd7bd58773f9fadf480179cbc4bae61508fe
2021-01-20gdb/dwarf: add some logging in dwarf2/read.cSimon Marchi2-0/+20
This patch adds some logging that helped me diagnose the problems fixed later in this series. I'm thinking that if it helped me now, it could help somebody else (or myself) in the future, so I might as well add them for real. They can happen quite frequently and be noisy, so I used dwarf_read_debug_printf_v for them, which means they'll only print if `set debug dwarf-read` is >= 2. gdb/ChangeLog: * dwarf2/read.c (follow_die_offset): Add logging. (dwarf2_per_objfile::age_comp_units): Add logging. Change-Id: I7483c0b05c37bc9710b9b5d40e272935bc010863
2021-01-20gdb: make some variables staticSimon Marchi37-53/+97
I'm trying to enable clang's -Wmissing-variable-declarations warning. This patch fixes all the obvious spots where we can simply add "static" (at least, found when building on x86-64 Linux). gdb/ChangeLog: * aarch64-linux-tdep.c (aarch64_linux_record_tdep): Make static. * aarch64-tdep.c (tdesc_aarch64_list, aarch64_prologue_unwind, aarch64_stub_unwind, aarch64_normal_base, ): Make static. * arm-linux-tdep.c (arm_prologue_unwind): Make static. * arm-tdep.c (struct frame_unwind): Make static. * auto-load.c (auto_load_safe_path_vec): Make static. * csky-tdep.c (csky_stub_unwind): Make static. * gdbarch.c (gdbarch_data_registry): Make static. * gnu-v2-abi.c (gnu_v2_abi_ops): Make static. * i386-netbsd-tdep.c (i386nbsd_mc_reg_offset): Make static. * i386-tdep.c (i386_frame_setup_skip_insns, i386_tramp_chain_in_reg_insns, i386_tramp_chain_on_stack_insns): Make static. * infrun.c (observer_mode): Make static. * linux-nat.c (sigchld_action): Make static. * linux-thread-db.c (thread_db_list): Make static. * maint-test-options.c (maintenance_test_options_list): * mep-tdep.c (mep_csr_registers): Make static. * mi/mi-cmds.c (struct mi_cmd_stats): Remove struct type name. (stats): Make static. * nat/linux-osdata.c (struct osdata_type): Make static. * ppc-netbsd-tdep.c (ppcnbsd_reg_offsets): Make static. * progspace.c (last_program_space_num): Make static. * python/py-param.c (struct parm_constant): Remove struct type name. (parm_constants): Make static. * python/py-record-btrace.c (btpy_list_methods): Make static. * python/py-record.c (recpy_gap_type): Make static. * record.c (record_goto_cmdlist): Make static. * regcache.c (regcache_descr_handle): Make static. * registry.h (DEFINE_REGISTRY): Make definition static. * symmisc.c (std_in, std_out, std_err): Make static. * top.c (previous_saved_command_line): Make static. * tracepoint.c (trace_user, trace_notes, trace_stop_notes): Make static. * unittests/command-def-selftests.c (nr_duplicates, nr_invalid_prefixcmd, lists): Make static. * unittests/observable-selftests.c (test_notification): Make static. * unittests/optional/assignment/1.cc (counter): Make static. * unittests/optional/assignment/2.cc (counter): Make static. * unittests/optional/assignment/3.cc (counter): Make static. * unittests/optional/assignment/4.cc (counter): Make static. * unittests/optional/assignment/5.cc (counter): Make static. * unittests/optional/assignment/6.cc (counter): Make static. gdbserver/ChangeLog: * ax.cc (bytecode_address_table): Make static. * debug.cc (debug_file): Make static. * linux-low.cc (stopping_threads): Make static. (step_over_bkpt): Make static. * linux-x86-low.cc (amd64_emit_ops, i386_emit_ops): Make static. * tracepoint.cc (stop_tracing_bkpt, flush_trace_buffer_bkpt, alloced_trace_state_variables, trace_buffer_ctrl, tracing_start_time, tracing_stop_time, tracing_user_name, tracing_notes, tracing_stop_note): Make static. Change-Id: Ic1d8034723b7802502bda23770893be2338ab020
2021-01-20gdb/remote.c: address conflicting enum and method nameJoel Sherrill2-5/+15
When building with gcc 4.8, we get: CXX remote.o cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ [enabled by default] /home/smarchi/src/binutils-gdb/gdb/remote.c:1157:38: error: 'resume_state' is not a class, namespace, or enumeration enum resume_state m_resume_state = resume_state::NOT_RESUMED; ^ It looks like gcc 4.8 doesn't like that there is an enum class named resume_state as well as a method. Since it's an easy fix, rename the method to get_remote_state to avoid the clash. gdb/ChangeLog: PR gdb/27219 * remote.c (struct remote_thread_info) <resume_state>: Rename to... <get_resume_state>: ... this. (remote_target::resume): Adjust. (remote_target::commit_resume): Adjust. (remote_target::select_thread_for_ambiguous_stop_reply): Adjust. Change-Id: Ib86c877a4c75ee671d69c27ed06cb8f57bc087db
2021-01-20gdb/testsuite: rename _cur_x/_cur_y to _cur_col/_cur_row in lib/tuiterm.expSimon Marchi2-86/+94
I am having trouble remembering which of _cur_x/_cur_y is columns and which is rows, so renaming them helps. We already have _rows and _cols to represent the terminal size, so I think that makes sense to name the "_cur" variables accordingly. gdb/testsuite/ChangeLog: * lib/tuiterm.exp: Rename _cur_x/_cur_y to _cur_col/_cur_row. Change-Id: I6abd3cdfdb295d8abde12dcd5f0ae09f18f07967
2021-01-20gdb/testsuite: add links for handled control sequences in lib/tuiterm.expSimon Marchi2-9/+49
This code can be a bit cryptic for those who don't know terminal control sequences very well. This patch adds links for all the handled sequences, so it's easy to get some doc to follow the code. I linked to a VT510 manual, because I think it's well formatted and easy to read. There's only the repeat sequence (_csi_b) which I haven't found in it, it looks to be xterm-specific or something. I also tried to use the sequence names as they are in the manual. gdb/testsuite/ChangeLog: * lib/tuiterm.exp: Add links in comments. Change-Id: I670b947a238e5e9bcab7c476a20eb3c31cf2909d
2021-01-20[gdb/testsuite] Fix gdb.python/py-format-string.exp with -m32Tom de Vries2-2/+9
When running test-case gdb.python/py-format-string.exp with target board unix/-m32, we run into: ... (gdb) python print \ (gdb.parse_and_eval ('a_base_ref').format_string (deref_refs=True))^M @0xffffc468: {_vptr.Base = 0x80487e0 <vtable for Deriv+8>, a = 42, \ static a_static_member = 2019}^M (gdb) FAIL: gdb.python/py-format-string.exp: format_string: \ lang_cpp: a_base_ref with option deref_refs: deref_refs=true ... while with -m64, we have instead: ... @0x7fffffffd170: {_vptr.Base = 0x400910 <vtable for Deriv+16>, a = 42, \ static a_static_member = 2019}^M (gdb) PASS: gdb.python/py-format-string.exp: format_string: \ lang_cpp: a_base_ref with option deref_refs: deref_refs=true ... The vtable contains pointer entries which are 4-byte for -m32 and 8-byte for -m64, so it's not surprising the offsets (Deriv+8 vs. Deriv+16) differ. Fix this by allow Deriv+$decimal. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-20 Tom de Vries <tdevries@suse.de> * gdb.python/py-format-string.exp: Allow Deriv+$decimal as vtable offset.
2021-01-20[gdb/testsuite] Skip gdb.rust/*.exp for target board unix/-m32Tom de Vries2-1/+20
When running gdb.rust/*.exp with target board unix/-m32, we see: ... Running src/gdb/testsuite/gdb.rust/union.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/modules.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/unsized.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/simple.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/watch.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/traits.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/expr.exp ... Running src/gdb/testsuite/gdb.rust/rust-style.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/methods.exp ... gdb compile failed, error: Unrecognized option: 'm' Running src/gdb/testsuite/gdb.rust/generics.exp ... gdb compile failed, error: Unrecognized option: 'm' === gdb Summary === nr of expected passes 95 nr of untested testcases 9 ... Fix this by testing for -m32 in the target board multilib_flags in skip_rust_tests. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-20 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (skip_rust_tests): Skip if multilib_flags contains -m32.
2021-01-20Fix a few stap parser issues and add a new test for probe expressionsSergio Durigan Junior5-5/+155
The creation of this patch was motivated by Tom's "Change handling of '!' operator in stap probes" patch. While reviewing his patch, I stumbled upon a few issues with the stap expression parser. They are: - As it turns out, even with Tom's patch applied the parser doesn't properly handle the '!' operator. The underlying issue was the fact that stap_parse_argument_conditionally also needed to be patched in order to recognize '!' as an operator that is part of a single operand, and parse it accordingly. - While writing the testcase I'm proposing on this patch, I found that parenthesized sub-expressions were not being parsed correctly when there was another term after them. For example: 1 - (2 + 3) + 4 In this case, the parser was considering "1" to be the left-side of the expression, and "(2 + 3) + 4" to be the right-side. The patch fixes the parser by making it identify whether a parenthesized sub-expression has just been parsed, and act accordingly. I've tested this on my Debian testing amd64, and everything seems OK. gdb/ChangeLog: 2021-01-20 Sergio Durigan Junior <sergiodj@sergiodj.net> Tom Tromey <tom@tromey.com> * stap-probe.c (stap_parse_single_operand): Handle '!' operator. (stap_parse_argument_conditionally): Likewise. Skip spaces after processing open-parenthesis sub-expression. (stap_parse_argument_1): Skip spaces after call to stap_parse_argument_conditionally. Handle case when right-side expression is a parenthesized sub-expression. Skip spaces after call to stap_parse_argument_1. gdb/testsuite/ChangeLog: 2021-01-20 Sergio Durigan Junior <sergiodj@sergiodj.net> * gdb.arch/amd64-stap-expressions.S: New file. * gdb.arch/amd64-stap-expressions.exp: New file.
2021-01-19use DISABLE_COPY_AND_ASSIGN in switch_thru_all_uisLancelot SIX2-5/+6
In switch_thru_all_uis, a pre-c++11 way of removing copy constructor and assignment operator is used. This patch uses the DISABLE_COPY_AND_ASSIGN macro which does the right thing for pre and post c++11. gdb/Changelog: 2021-01-19 Lancelot SIX <lsix@lancelotsix.com> * top.h (switch_thru_all_uis): Use DISABLE_COPY_AND_ASSIGN.
2021-01-19trad-frame cleanupsLuis Machado28-232/+183
With the new member functions for struct trad_frame_saved_reg, there is no need to invoke some of the set/get functions anymore. This patch removes those and adjusts all callers. Even though the most natural initial state of a saved register value is UNKNOWN, there are target backends relying on the previous initial state of REALREG set to a register's own number. I noticed this in at least a couple targets: aarch64 and riscv. Because of that, I decided to keep the reset function that sets the set of register values to REALREG. I can't exercise all the targets to make sure the initial state change won't break things, hence why it is risky to change the default. Validated with --enable-targets=all on aarch64-linux Ubuntu 18.04/20.04. gdb/ChangeLog 2021-01-19 Luis Machado <luis.machado@linaro.org> * trad-frame.h (trad_frame_saved_reg) <set_value_bytes>: Allocate memory and save data. (trad_frame_set_value, trad_frame_set_realreg, trad_frame_set_addr) (trad_frame_set_unknown, trad_frame_set_value_bytes) (trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p) (trad_frame_value_bytes_p): Remove. (trad_frame_reset_saved_regs): Adjust documentation. * trad-frame.c (trad_frame_alloc_saved_regs): Initialize via a constructor and reset the state of the registers. (trad_frame_value_p, trad_frame_addr_p, trad_frame_realreg_p) (trad_frame_value_bytes_p, trad_frame_set_value) (trad_frame_set_realreg, trad_frame_set_addr) (trad_frame_set_unknown, trad_frame_set_value_bytes): Remove. (trad_frame_set_reg_realreg): Update to call member function. (trad_frame_set_reg_addr, trad_frame_set_reg_value_bytes): Likewise. (trad_frame_get_prev_register): Likewise. * aarch64-tdep.c (aarch64_analyze_prologue) (aarch64_analyze_prologue_test, aarch64_make_prologue_cache_1) (aarch64_prologue_prev_register): Update to use member functions. * alpha-mdebug-tdep.c (alpha_mdebug_frame_unwind_cache): Likewise. * alpha-tdep.c (alpha_heuristic_frame_unwind_cache): Likewise. * arc-tdep.c (arc_print_frame_cache, arc_make_frame_cache): Likewise. * arm-tdep.c (arm_make_prologue_cache, arm_exidx_fill_cache) (arm_make_epilogue_frame_cache): Likewise. * avr-tdep.c (avr_frame_unwind_cache) (avr_frame_prev_register): Likewise. * cris-tdep.c (cris_scan_prologue): Likewise. * csky-tdep.c (csky_frame_unwind_cache): Likewise. * frv-tdep.c (frv_analyze_prologue): Likewise. * hppa-tdep.c (hppa_frame_cache, hppa_fallback_frame_cache): Likewise. * lm32-tdep.c (lm32_frame_cache): Likewise. * m32r-tdep.c (m32r_frame_unwind_cache): Likewise. * m68hc11-tdep.c (m68hc11_frame_unwind_cache): Likewise. * mips-tdep.c (set_reg_offset, mips_insn16_frame_cache) (mips_micro_frame_cache, mips_insn32_frame_cache): Likewise. (reset_saved_regs): Adjust to set realreg. * riscv-tdep.c (riscv_scan_prologue, riscv_frame_cache): Adjust to call member functions. * rs6000-tdep.c (rs6000_frame_cache, rs6000_epilogue_frame_cache) * s390-tdep.c (s390_prologue_frame_unwind_cache) (s390_backchain_frame_unwind_cache): Likewise. * score-tdep.c (score7_analyze_prologue) (score3_analyze_prologue, score_make_prologue_cache): Likewise. * sparc-netbsd-tdep.c (sparc32nbsd_sigcontext_saved_regs): Likewise. * sparc-sol2-tdep.c (sparc32_sol2_sigtramp_frame_cache): Likewise. * sparc64-netbsd-tdep.c (sparc64nbsd_sigcontext_saved_regs): Likewise. * sparc64-sol2-tdep.c (sparc64_sol2_sigtramp_frame_cache): Likewise. * tilegx-tdep.c (tilegx_analyze_prologue) (tilegx_frame_cache): Likewise. * v850-tdep.c (v850_frame_cache): Likewise. * vax-tdep.c (vax_frame_cache): Likewise.
2021-01-19Convert some frame functions to use gdb::array_view.Luis Machado27-84/+147
This patch converts the most obvious functions from gdb/frame.h to use the gdb::array_view abstraction. I've converted the ones that used buffer + length. There are others using only the buffer, with an implicit size. I did not touch those for now. But it would be nice to pass the size for safety. Tested with --enable-targets=all on Ubuntu 18.04/20.04 aarch64-linux. gdb/ChangeLog 2021-01-19 Luis Machado <luis.machado@linaro.org> * frame.h (get_frame_register_bytes): Pass a gdb::array_view instead of buffer + length. (put_frame_register_bytes): Likewise. Adjust documentation. (get_frame_memory): Pass a gdb::array_view instead of buffer + length. (safe_frame_unwind_memory): Likewise. * frame.c (get_frame_register_bytes, put_frame_register_bytes) (get_frame_memory, safe_frame_unwind_memory): Adjust to use gdb::array_view. * amd64-fbsd-tdep.c (amd64fbsd_sigtramp_p): Likewise. * amd64-linux-tdep.c (amd64_linux_sigtramp_start): Likewise. * amd64-obsd-tdep.c (amd64obsd_sigtramp_p): Likewise. * arc-linux-tdep.c (arc_linux_is_sigtramp): Likewise. * cris-tdep.c (cris_sigtramp_start, cris_rt_sigtramp_start): Likewise. * dwarf2/loc.c (rw_pieced_value): Likewise. * hppa-tdep.c (hppa_frame_cache): Likewise. * i386-fbsd-tdep.c (i386fbsd_sigtramp_p): Likewise. * i386-gnu-tdep.c (i386_gnu_sigtramp_start): Likewise. * i386-linux-tdep.c (i386_linux_sigtramp_start) (i386_linux_rt_sigtramp_start): Likewise. * i386-obsd-tdep.c (i386obsd_sigtramp_p): Likewise. * i386-tdep.c (i386_register_to_value): Likewise. * i387-tdep.c (i387_register_to_value): Likewise. * ia64-tdep.c (ia64_register_to_value): Likewise. * m32r-linux-tdep.c (m32r_linux_sigtramp_start) (m32r_linux_rt_sigtramp_start): Likewise. * m68k-linux-tdep.c (m68k_linux_pc_in_sigtramp): Likewise. * m68k-tdep.c (m68k_register_to_value): Likewise. * mips-tdep.c (mips_register_to_value) (mips_value_to_register): Likewise. * ppc-fbsd-tdep.c (ppcfbsd_sigtramp_frame_sniffer) (ppcfbsd_sigtramp_frame_cache): Likewise. * ppc-obsd-tdep.c (ppcobsd_sigtramp_frame_sniffer) (ppcobsd_sigtramp_frame_cache): Likewise. * rs6000-tdep.c (rs6000_in_function_epilogue_frame_p) (rs6000_register_to_value): Likewise. * tilegx-tdep.c (tilegx_analyze_prologue): Likewise. * tramp-frame.c (tramp_frame_start): Likewise. * valops.c (value_assign): Likewise.
2021-01-19Use gdb::array_view for setting value bytes in trad-frameLuis Machado4-19/+28
This patch updates the functions setting value bytes in trad-frame to use a gdb::array_view instead of passing a buffer and a size. gdb/ChangeLog: 2021-01-19 Luis Machado <luis.machado@linaro.org> * aarch64-linux-tdep.c (aarch64_linux_restore_vreg): Pass in an array_view. * trad-frame.c (trad_frame_set_value_bytes): Use gdb::array_view instead of buffer and size. (trad_frame_set_reg_value_bytes): Likewise. * trad-frame.h (trad_frame_set_reg_value_bytes): Likewise. (trad_frame_set_value_bytes): Likewise.
2021-01-19[gdb/testsuite] Fix gdb.base/step-over-syscall.exp with -m32Tom de Vries2-0/+28
When executing test-case gdb.base/step-over-syscall.exp with target board unix/-m32, we run into: ... (gdb) x/2i $pc^M => 0xf7fd5155 <__kernel_vsyscall+5>: sysenter ^M 0xf7fd5157 <__kernel_vsyscall+7>: int $0x80^M (gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: \ pc before/after syscall instruction stepi^M [Detaching after fork from child process 23593]^M 0xf7fd5159 in __kernel_vsyscall ()^M 1: x/i $pc^M => 0xf7fd5159 <__kernel_vsyscall+9>: pop %ebp^M (gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: stepi fork insn print /x $pc^M $2 = 0xf7fd5159^M (gdb) PASS: gdb.base/step-over-syscall.exp: fork: displaced=off: pc after stepi FAIL: gdb.base/step-over-syscall.exp: fork: displaced=off: \ pc after stepi matches insn addr after syscall ... The test tries to verify that after doing a stepi at a syscall insn, the $pc is matching the insn after the syscall insn. However, in the case that the syscall insn is "sysenter", the stepi will land further away, so in this case: ... 0xf7fd5155 <__kernel_vsyscall+5>: sysenter ^M 0xf7fd5157 <__kernel_vsyscall+7>: int $0x80^M 0xf7fd5159 <__kernel_vsyscall+9>: pop %ebp^M ... the stepi will land at 0xf7fd5159 instead of 0xf7fd5157. Fix this by detecting the sysenter/int sequence and adjusting the expected pc. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-19 Tom de Vries <tdevries@suse.de> * gdb.base/step-over-syscall.exp: Detect and handle sysenter/int sequence.
2021-01-19[gdb/testsuite] Fix gdb.arch/i386-mpx.exp with -m32Tom de Vries2-1/+5
When running test-case gdb.arch/i386-mpx.exp with target board unix/-m32, we run into: ... (gdb) print $bndstatus^M $3 = {raw = 0xf7ca7ff2, status = {bde = 1039310844, error = 2}}^M (gdb) FAIL: gdb.arch/i386-mpx.exp: bndstatus formating print $bndstatus.raw^M $4 = (void *) 0xf7ca7ff2^M (gdb) FAIL: gdb.arch/i386-mpx.exp: bndstatus is zero by startup ... The failure does not occur with -m64, there we have instead: ... (gdb) print $bndstatus^M $3 = {raw = 0x0, status = {bde = 0, error = 0}}^M (gdb) PASS: gdb.arch/i386-mpx.exp: bndstatus formating print $bndstatus.raw^M $4 = (void *) 0x0^M (gdb) PASS: gdb.arch/i386-mpx.exp: bndstatus is zero by startup ... The difference is as follows. At the point of issuing the print commands, we have run to main, so in the case of -m64 we have executed: ... 00000000004004c7 <main>: 4004c7: 55 push %rbp 4004c8: 48 89 e5 mov %rsp,%rbp 4004cb: 89 7d fc mov %edi,-0x4(%rbp) 4004ce: 48 89 75 f0 mov %rsi,-0x10(%rbp) 4004d2: 66 0f 1b 45 e0 bndmov %bnd0,-0x20(%rbp) ... and in the case of -m32: ... 08048426 <main>: 8048426: 55 push %ebp 8048427: 89 e5 mov %esp,%ebp 8048429: 83 ec 08 sub $0x8,%esp 804842c: 8d 45 0c lea 0xc(%ebp),%eax 804842f: 8b 55 0c mov 0xc(%ebp),%edx 8048432: 0f 1a 04 10 bndldx (%eax,%edx,1),%bnd0 8048436: 66 0f 1b 45 f8 bndmov %bnd0,-0x8(%ebp) ... In both cases, the bnd instructions attempt to save the bound for pointer argument argv to stack. However, there's no such bound set. In the -m64 case, that means we just save some random value to stack. In the -m32 case, that means that when executing bndldx the corresponding entry in the Bounds Directory is invalid, and $bndstatus is updated to reflect that. Fix this by dropping the unnecessary argv parameter to main, similar to all other gdb.arch/i386-mpx*.c test-cases. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-19 Tom de Vries <tdevries@suse.de> * gdb.arch/i386-mpx.c (main): Drop argc/argv parameter.
2021-01-18sim: bfin: delete accidental ADI copyrightMike Frysinger2-1/+5
This wasn't supposed to be in here when it was first merged as we had specifically disabled it for all the tests (and ADI has papers in place w/the FSF). Clean up this one.
2021-01-18gdb/testsuite: remove actual addresses from some test namesAndrew Burgess2-1/+7
After commit: commit 10f92414d6d4a5f8eb8cbb2bf39ca86c1f9c1da5 Date: Fri Jan 15 12:14:45 2021 +0100 [gdb/testsuite] Fix gdb.fortran/array-slices.exp with -m32 Some test names now contain the addresses of variables from the inferior. When running the test in different directories I'm seeing slightly different values for the addresses. This makes comparing test results between directories harder than it needs to be. This commit just gives the tests a descriptive name without including the addresses. gdb/testsuite/ChangeLog: * gdb.fortran/array-slices.exp (run_test): Avoid including addresses in test names.
2021-01-18gdb/riscv: use a single regset supply function for riscv fbsd & linuxAndrew Burgess5-20/+87
The RISC-V x0 register is hard-coded to zero. As such neither Linux or FreeBSD supply the value of the register x0 in their core dump files. For FreeBSD we take care of this by manually supplying the value of x0 in riscv_fbsd_supply_gregset, however we don't do this for Linux. As a result after loading a core file on Linux we see this behaviour: (gdb) p $x0 $1 = <unavailable> In this commit I make riscv_fbsd_supply_gregset a common function that can be shared between RISC-V for FreeBSD and Linux, this resolves the above issue. There is a similar problem for the two registers `fflags` and `frm`. These two floating point related CSRs are a little weird. They are separate CSRs in the RISC-V specification, but are actually sub-fields of the `fcsr` CSR. As a result neither Linux or FreeBSD supply the `fflags` or `frm` registers as separate fields in their core dumps, and so, after restoring a core dump these register are similarly unavailable. In this commit I supply `fflags` and `frm` by first asking for the value of `fcsr`, extracting the two fields, and using these to supply the values for `fflags` and `frm`. gdb/ChangeLog: * riscv-fbsd-tdep.c (riscv_fbsd_supply_gregset): Delete. (riscv_fbsd_gregset): Use riscv_supply_regset. (riscv_fbsd_fpregset): Likewise. * riscv-linux-tdep.c (riscv_linux_gregset): Likewise. (riscv_linux_fregset): Likewise. * riscv-tdep.c (riscv_supply_regset): Define new function. * riscv-tdep.h (riscv_supply_regset): Declare new function.
2021-01-18[gdb/tdep] Handle si_addr_bnd in compat_siginfo_from_siginfoTom de Vries2-0/+21
When running test-case gdb.arch/i386-mpx-sigsegv.exp with target board unix/-m32, we run into: ... (gdb) continue^M Continuing.^M Saw a #BR! status 1 at 0x8048c2d^M ^M Program received signal SIGSEGV, Segmentation fault^M Upper bound violation while accessing address 0x0804c15c^M Bounds: [lower = 0x00000000, upper = 0x00000000].^M 0x08048a4f in lower (p=0x804c160, a=0x804c180, b=0x804c1a0, c=0x804c1c0, \ d=0x804c1e0, len=1) at i386-mpx-sigsegv.c:79^M 79 value = *(p - len);^M (gdb) FAIL: gdb.arch/i386-mpx-sigsegv.exp: MPX signal segv Lower: 0 ... The problem is that lower and upper in the Bounds message are 0x0, which is caused by $_siginfo._sifields._sigfault._addr_bnd.{_lower,_upper} evaluating to 0x0. Fix this by copying the si_lower/si_upper fields in compat_siginfo_from_siginfo. Tested on x86_64-linux, with target board unix/-m32. gdb/ChangeLog: 2021-01-18 Tom de Vries <tdevries@suse.de> PR tdep/27172 * nat/amd64-linux-siginfo.c (cpt_si_lower, cpt_si_upper, SEGV_BNDERR): New macro. (compat_siginfo_from_siginfo): Copy cpt_si_lower and cpt_si_upper for SEGV_BNDERR.
2021-01-18gdb: const-ify hostio methods parameter in remote.cSimon Marchi2-8/+18
gdb/ChangeLog: * remote.c (class remote_target) <remote_hostio_send_command, remote_hostio_parse_result>: Constify parameter. (remote_hostio_parse_result): Likewise. (remote_target::remote_hostio_send_command): Adjust. (remote_target::remote_hostio_pread_vFile): Adjust. (remote_target::fileio_readlink): Adjust. (remote_target::fileio_fstat): Adjust. Change-Id: I6b585b99937e6526a0a7e06261d2193114589912
2021-01-18gdb: move remote_target::start_remote variable to narrower scopeSimon Marchi2-5/+7
The wait_status variable is only used when the target is in in all-stop mode. We can therefore move it in the !target_is_non_stop scope. That lets us remove the assert in the else, that checks that the wait status is not set. If the variable doesn't exist in that scope, it pretty much guarantees that it is not set. gdb/ChangeLog: * remote.c (remote_target::start_remote): Move wait_status to narrower scope. Change-Id: I30979135e3f4f36d04178baa67575c4e58d3b648
2021-01-18gdb: const-ify remote_target::add_current_inferior_and_thread parameterSimon Marchi2-5/+13
... and adjust callers / callees. gdb/ChangeLog: * remote.c (class remote_target): <add_current_inferior_and_thread>: Constify parameter. (stop_reply_extract_thread): Likewise. (remote_target::get_current_thread): Likewise. (remote_target::add_current_inferior_and_thread): Likewise. Change-Id: Ifdc6c263104b58852b532cfda81caf836437d29c
2021-01-18gdb: const-ify unpack_* functions in remote.cSimon Marchi2-25/+39
Const-ify the unpack_* functions, and then adjust the callers accordingly. gdb/ChangeLog: * remote.c (class remote_target) <remote_unpack_thread_info_response, parse_threadlist_response>: Constify parameter and/or return value and or local variable. (stub_unpack_int): Likewise. (unpack_nibble): Likewise. (unpack_byte): Likewise. (unpack_int): Likewise. (unpack_string): Likewise. (unpack_threadid): Likewise. (remote_target::remote_unpack_thread_info_response): Likewise. (remote_target::parse_threadlist_response): Likewise. Change-Id: Ibda75f664d6e3452df00f85af7134533049171b7
2021-01-15gdb/tui: compare pointer to nullptr, not 0Andrew Burgess2-2/+6
Compare pointers to nullptr, not 0. I also fixed a trailing whitespace in the same function. There should be no user visible changes after this commit. gdb/ChangeLog: * tui/tui.c (tui_is_window_visible): Compare to nullptr, not 0.
2021-01-15[gdb/testsuite] Fix gdb.fortran/array-slices.exp with -m32Tom de Vries2-1/+7
When running test-case gdb.fortran/array-slices.exp with target board unix/-m32, we run into: ... (gdb) print /x &array4d^M $69 = 0xffffb620^M (gdb) print /x (&array4d) + sizeof (array4d)^M $70 = 0x95c620^M (gdb) FAIL: gdb.fortran/array-slices.exp: repack=on: test 9: check sizes match ... The expressions calculate the start and end of an array, but the calculation of the end expression has an unexpected result (given that it lies before the start of the array). By printing "sizeof (array4d)" as a separate expression: ... (gdb) print /x sizeof (array4d) $1 = 0xc40 ... it becomes clear we expected to get 0xffffb620 + 0xc40 == 0xffffc260 instead. The problem is that using the '&' returns a pointer type: ... (gdb) p &array4d $5 = (PTR TO -> ( integer(kind=4) (-3:3,7:10,-3:3,-10:-7) )) 0xffffbe00 ... which has the consequence that the addition is done as pointer arithmetic. Fix this by using the result of "print /x &array4d" instead of &array4d in the addition. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-15 Tom de Vries <tdevries@suse.de> PR testsuite/26997 * gdb.fortran/array-slices.exp (run_test): Avoid pointer arithmetic when adding sizeof.
2021-01-14Add myself to gdb/MAINTAINERSLancelot SIX2-0/+5
gdb/ChangeLog: * MAINTAINERS (Wrate After Approval): Add myself.
2021-01-14Fix building gdb with gcc-4.xBernd Edlinger2-1/+10
Since is_trivially_default_constructible was not implemented before gcc-5 it cannot be used with gcc-4.x. Fix the build by using conditional compilation around that line. Use the equivalent is_trivially_constructible<T> instead, since we already have HAVE_IS_TRIVIALLY_CONSTRUCTIBLE for that purpose. Fixes: 098caef485a ("Refactor struct trad_frame_saved_regs") gdb: 2021-01-14 Bernd Edlinger <bernd.edlinger@hotmail.de> * trad-frame.c (trad_frame_alloc_saved_regs): Avoid compile-error because is_trivially_default_constructible was first implemented with gcc-5.
2021-01-14[gdb/breakpoint] Handle .plt.sec in in_plt_sectionTom de Vries2-1/+7
Consider the following test-case small.c: ... #include <stdio.h> #include <stdlib.h> #include <string.h> int main (void) { int *p = (int *)malloc (sizeof(int) * 4); memset (p, 0, sizeof(p)); printf ("p[0] = %d; p[3] = %d\n", p[0], p[3]); return 0; } ... On Ubuntu 20.04, we get: ... $ gcc -O0 -g small.c $ gdb -batch a.out -ex start -ex step Temporary breakpoint 1, main () at small.c:6 6 int *p = (int *) malloc(sizeof(int) * 4); p[0] = 0; p[3] = 0 [Inferior 1 (process $dec) exited normally] ... but after switching off the on-by-default fcf-protection, we get the desired behaviour: ... $ gcc -O0 -g small.c -fcf-protection=none $ gdb -batch a.out -ex start -ex step Temporary breakpoint 1, main () at small.c:6 6 int *p = (int *) malloc(sizeof(int) * 4); 7 memset (p, 0, sizeof(p)); ... Using "set debug infrun 1", the first observable difference between the two debug sessions is that with -fcf-protection=none we get: ... [infrun] process_event_stop_test: stepped into dynsym resolve code ... In this case, "in_solib_dynsym_resolve_code (malloc@plt)" returns true because "in_plt_section (malloc@plt)" returns true. With -fcf-protection=full, "in_solib_dynsym_resolve_code (malloc@plt)" returns false because "in_plt_section (malloc@plt)" returns false, because the section name for malloc@plt is .plt.sec instead of .plt, which is not handled in in_plt_section: ... static inline int in_plt_section (CORE_ADDR pc) { return pc_in_section (pc, ".plt"); } ... Fix this by handling .plt.sec in in_plt_section. Tested on x86_64-linux. [ Another requirement to be able to reproduce this is to have a dynamic linker with a "malloc" minimal symbol, which causes find_solib_trampoline_target to find it, such that skip_language_trampoline returns the address for the dynamic linkers malloc. This causes the step machinery to set a breakpoint there, and to continue, expecting to hit it. Obviously, we execute glibc's malloc instead, so the breakpoint is not hit and we continue to program completion. ] gdb/ChangeLog: 2021-01-14 Tom de Vries <tdevries@suse.de> PR breakpoints/27151 * objfiles.h (in_plt_section): Handle .plt.sec.
2021-01-14[gdb/testsuite] Fix gdb.base/style.exp with -m32Tom de Vries2-6/+48
When running test-case gdb.base/style.exp with target board unix/-m32, we run into (stripped styling from output, shortened file name): ... (gdb) frame argv=0xffffc714) at src/gdb/testsuite/gdb.base/style.c:45 45 return some_called_function (); /* break here */ (gdb) FAIL: gdb.base/style.exp: frame when width=20 ... while with native we have instead: ... (gdb) frame argv=0x7fffffffd478) at src/gdb/testsuite/gdb.base/style.c:45 45 return some_called_function (); /* break here */ (gdb) PASS: gdb.base/style.exp: frame when width=20 ... The problem is that due to argv having a different length for -m32, we get a different layout, and the test-case doesn't accommodate for that. Fix this by using a different regexp depending on the length of argv. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-14 Tom de Vries <tdevries@suse.de> PR testsuite/24590 * gdb.base/style.exp: Handle shorter argv in frame command output.
2021-01-13gdb: better handling of 'S' packetsAndrew Burgess5-55/+336
This commit builds on work started in the following two commits: commit 24ed6739b699f329c2c45aedee5f8c7d2f54e493 Date: Thu Jan 30 14:35:40 2020 +0000 gdb/remote: Restore support for 'S' stop reply packet commit cada5fc921e39a1945c422eea055c8b326d8d353 Date: Wed Mar 11 12:30:13 2020 +0000 gdb: Handle W and X remote packets without giving a warning This is related to how GDB handles remote targets that send back 'S' packets. In the first of the above commits we fixed GDB's ability to handle a single process, single threaded target that sends back 'S' packets. Although the 'T' packet would always be preferred to 'S' these days, there's nothing really wrong with 'S' for this situation. The second commit above fixed an oversight in the first commit, a single-process, multi-threaded target can send back a process wide event, for example the process exited event 'W' without including a process-id, this also is fine as there is no ambiguity in this case. In PR gdb/26819 we run into yet another problem with the above commits. In this case we have a single process with two threads, GDB hits a breakpoint in thread 2 and then performs a stepi: (gdb) b main Breakpoint 1 at 0x1212340830: file infinite_loop.S, line 10. (gdb) c Continuing. Thread 2 hit Breakpoint 1, main () at infinite_loop.S:10 10 in infinite_loop.S (gdb) set debug remote 1 (gdb) stepi Sending packet: $vCont;s:2#24...Packet received: S05 ../binutils-gdb/gdb/infrun.c:5807: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed. What happens in this case is that on the RISC-V target displaced stepping is not supported, so when the stepi is issued GDB steps just thread 2. As only a single thread was set running the target decides that is can get away with sending back an 'S' packet without a thread-id. GDB then associates the stop with thread 1 (the first non-exited thread), but as thread 1 was not previously set executing the assertion seen above triggers. As an aside I am surprised that the target sends pack 'S' in this situation. The target is happy to send back 'T' (including thread-id) when multiple threads are set running, so (to me) it would seem easier to just always use the 'T' packet when multiple threads are in use. However, the target only uses 'T' when multiple threads are actually executing, otherwise an 'S' packet it used. Still, when looking at the above situation we can see that GDB should be able to understand which thread the 'S' reply is referring too. The problem is that is that in commit 24ed6739b699 (above) when a stop reply comes in with no thread-id we look for the first non-exited thread and select that as the thread the stop applies too. What we should really do is select the first non-exited, resumed thread, and associate the stop event with this thread. In the above example both thread 1 and 2 are non-exited, but only thread 2 is resumed, so this is what we should use. There's a test for this issue included which works with stock gdbserver by disabling use of the 'T' packet, and enabling 'scheduler-locking' within GDB so only one thread is set running. gdb/ChangeLog: PR gdb/26819 * remote.c (remote_target::select_thread_for_ambiguous_stop_reply): New member function. (remote_target::process_stop_reply): Call select_thread_for_ambiguous_stop_reply. gdb/testsuite/ChangeLog: PR gdb/26819 * gdb.server/stop-reply-no-thread-multi.c: New file. * gdb.server/stop-reply-no-thread-multi.exp: New file. Change-Id: I9b49d76c2a99063dcc76203fa0f5270a72825d15
generated by cgit v1.1 at 2025-09-26 20:35:52 +0000