aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-01-28gdb: rename get_type_arch to type::archSimon Marchi30-110/+101
... and update all users. gdb/ChangeLog: * gdbtypes.h (get_type_arch): Rename to... (struct type) <arch>: ... this, update all users. Change-Id: I0e3ef938a0afe798ac0da74a9976bbd1d082fc6f
2021-01-28gdb: rename type::{arch,objfile} -> type::{arch_owner,objfile_owner}Simon Marchi12-50/+58
I think this makes the names of the methods clearer, especially for the arch. The type::arch method (which gets the arch owner, or NULL if the type is not arch owned) is easily confused with the get_type_arch method (which returns an arch no matter what). The name "arch_owner" will make it intuitive that the method returns NULL if the type is not arch-owned. Also, this frees the type::arch name, so we will be able to morph the get_type_arch function into the type::arch method. gdb/ChangeLog: * gdbtypes.h (struct type) <arch>: Rename to... <arch_owner>: ... this, update all users. <objfile>: Rename to... <objfile_owner>: ... this, update all users. Change-Id: Ie7c28684c7b565adec05a7619c418c69429bd8c0
2021-01-28gdb/testsuite: unset XDG_CONFIG_HOMEAndrew Burgess2-0/+11
Since this commit: commit 64aaad6349d2b2c45063a5383f877ce9a3a0c354 Date: Fri Sep 25 14:50:56 2020 +0100 gdb: use get_standard_config_dir when looking for .gdbinit GDB has been checking for ${XDG_CONFIG_HOME}/gdb/gdbinit on startup. Most tests pass -nx to GDB to block loading of gdbinit files, but there are a few tests (e.g. gdb.base/gdbinit-history.exp) that don't use -nx and instead setup a fake HOME directory containing a gdbinit file. However, since the above commit, if XDG_CONFIG_HOME is set then once -nx is no longer being passed GDB will load any gdbinit file it finds in that directory, which could cause the test to fail. As a concrete example: $ mkdir -p fake_xdg_config_home/gdb/ $ cat <<EOF >fake_xdg_config_home/gdb/gdbinit echo goodbye\n quit EOF $ export XDG_CONFIG_HOME=$PWD/fake_xdg_config_home $ make check-gdb TESTS="gdb.base/gdbinit-history.exp" Should result in the test failing. The solution I propose is to unset XDG_CONFIG_HOME in default_gdb_init, we already unset a bunch of environment variables in this proc. gdb/testsuite/ChangeLog: * lib/gdb.exp (default_gdb_init): Unset XDG_CONFIG_HOME.
2021-01-28gdb: update comment for execute_command_to_stringAndrew Burgess3-6/+12
The function execute_command_to_string had two header comments, one in gdbcmd.h and one in top.c. This commit merges the two comments into one and places this comment in gdbcmd.h. The comment in top.c is updated to just reference gdbcmd.h. gdb/ChangeLog: * gdbcmd.h (execute_command_to_string): Update comment. * top.c (execute_command_to_string): Update header comment.
2021-01-28[gdb/breakpoints] Fix longjmp master breakpoint with separate debug infoTom de Vries2-74/+118
When running test-case gdb.base/longjmp.exp with target board unix/-m32, we run into: ... (gdb) next^M Warning:^M Cannot insert breakpoint 0.^M Cannot access memory at address 0x7dbf7353^M ^M __libc_siglongjmp (env=0x804a040 <env>, val=1) at longjmp.c:28^M 28 longjmps++;^M (gdb) FAIL: gdb.base/longjmp.exp: next over longjmp(1) ... The failure to access memory happens in i386_get_longjmp_target and is due to glibc having pointer encryption (aka "pointer mangling" or "pointer guard") of the long jump buffer. This is a known problem. In create_longjmp_master_breakpoint (which attempts to install a master longjmp breakpoint) a preference scheme is present, which installs a probe breakpoint if a libc:longjmp probe is present, and otherwise falls back to setting breakpoints at the names in the longjmp_names array. But in fact, both the probe breakpoint and the longjmp_names breakpoints are set. The latter ones are set when processing libc.so.debug, and the former one when processing libc.so. In other words, this is the longjmp variant of PR26881, which describes the same problem for master exception breakpoints. This problem only triggers when the glibc debug info package is installed, which is not due to the debug info itself in libc.so.debug, but due to the minimal symbols (because create_longjmp_master_breakpoint uses minimal symbols to translate the longjmp_names to addresses). The problem doesn't trigger for -m64, because there tdep->jb_pc_offset is not set. Fix this similar to commit 1940319c0ef (the fix for PR26881): only install longjmp_names breakpoints in libc.so/libc.so.debug if installing the libc:longjmp probe in libc.so failed. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-28 Tom de Vries <tdevries@suse.de> PR breakpoints/27205 * breakpoint.c (create_longjmp_master_breakpoint_probe) (create_longjmp_master_breakpoint_names): New function, factored out of ... (create_longjmp_master_breakpoint): ... here. Only try to install longjmp_names breakpoints in libc.so/libc.so.debug if installing probe breakpoint in libc.so failed.
2021-01-28[gdb/testsuite] Fix gdb.ada/out_of_line_in_inlined.exp with -m32 and gcc-10Tom de Vries2-2/+5
When running test-case gdb.ada/out_of_line_in_inlined.exp with target board unix/-m32 on a system with gcc-10 default compiler, we run into: ... (gdb) break foo_o224_021.child1.child2^M Breakpoint 1 at 0x804ba59: foo_o224_021.child1.child2. (3 locations)^M (gdb) FAIL: gdb.ada/out_of_line_in_inlined.exp: scenario=all: \ break foo_o224_021.child1.child2 ... The test does not expect the "3 locations" part. Fix this by using gdb_breakpoint instead of gdb_test. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-28 Tom de Vries <tdevries@suse.de> * gdb.ada/out_of_line_in_inlined.exp: Use gdb_breakpoint.
2021-01-28[gdb/testsuite] Fix ERROR in gdb.dwarf2/dw2-out-of-range-end-of-seq.expTom de Vries2-3/+10
When running test-case gdb.dwarf2/dw2-out-of-range-end-of-seq.exp on a system with debug packages installed, I run into: ... (gdb) maint info line-table^M ... <lots of output> ... ERROR: internal buffer is full. UNRESOLVED: gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: \ END with address 1 eliminated ... Fix this by limiting the output of the command using a regexp. I also noticed that when making the regexp match nothing, meaning the command has no output, the test didn't FAIL. Fixed this by adding a PASS pattern. I also noticed that the FAIL pattern didn't work with -m32, fixed that as well. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-28 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: Add regexp to "maint info line-table". Make PASS pattern more specific. Make FAIL pattern work for -m32.
2021-01-27Avoid use after free with logging and debug redirect.Lancelot SIX4-0/+30
This patch addresses PR gdb/27133. Before it, the following succession of commands would cause gdb to crash: set logging redirect on set logging debugredirect on set logging on The problem eventually comes down to a use after free. The function cli_interp_base::set_logging is called with a unique_ptr argument that holds a pointer to the redirection file. In the problematic use case, no-one ever took ownership of that pointer (as far as unique_ptr is concerned), so the call to its dtor at the end of the function causes the file object to be deleted. Any later use of the pointer to the redirection file is therefore an error. This patch ensures that the unique_ptr is released when required (so it does not assume ownership anymore). The internal logic of cli_interp_base::set_logging takes care of freeing the ui_file when it is not necessary anymore using the saved_output.file_to_delete field. gdb/ChangeLog: PR gdb/27133 * cli/cli-interp.c (cli_interp_base::set_logging): Ensure the unique_ptr is released when the wrapped pointer is kept for later use. gdb/testsuite/ChangeLog: PR gdb/27133 * gdb.base/ui-redirect.exp: Add test case that ensures that redirecting both logging and debug does not cause gdb to crash.
2021-01-27GDB: aarch64: Add ability to displaced step over a BR/BLR instructionMatthew Malcomson5-6/+114
Enable displaced stepping over a BR/BLR instruction Displaced stepping over an instruction executes a instruction in a scratch area and then manually fixes up the PC address to leave execution where it would have been if the instruction were in its original location. The BR instruction does not need modification in order to run correctly at a different address, but the displaced step fixup method should not manually adjust the PC since the BR instruction sets that value already. The BLR instruction should also avoid such a fixup, but must also have the link register modified to point to just after the original code location rather than back to the scratch location. This patch adds the above functionality. We add this functionality by modifying aarch64_displaced_step_others rather than by adding a new visitor method to aarch64_insn_visitor. We choose this since it seems that visitor approach is designed specifically for PC relative instructions (which must always be modified when executed in a different location). It seems that the BR and BLR instructions are more like the RET instruction which is already handled specially in aarch64_displaced_step_others. This also means the gdbserver code to relocate an instruction when creating a fast tracepoint does not need to be modified, since nothing special is needed for the BR and BLR instructions there. Regression tests showed nothing untoward on native aarch64 (though it took a while for me to get the testcase to account for PIE). ------##### Original observed (mis)behaviour before was that displaced stepping over a BR or BLR instruction would not execute the function they called. Most easily seen by putting a breakpoint with a condition on such an instruction and a print statement in the functions they called. When run with the breakpoint enabled the function is not called and "numargs called" is not printed. When run with the breakpoint disabled the function is called and the message is printed. --- GDB Session ~ [15:57:14] % gdb ../using-blr Reading symbols from ../using-blr...done. (gdb) disassemble blr_call_value Dump of assembler code for function blr_call_value: ... 0x0000000000400560 <+28>: blr x2 ... 0x00000000004005b8 <+116>: ret End of assembler dump. (gdb) break *0x0000000000400560 Breakpoint 1 at 0x400560: file ../using-blr.c, line 22. (gdb) condition 1 10 == 0 (gdb) run Starting program: /home/matmal01/using-blr [Inferior 1 (process 33279) exited with code 012] (gdb) disable 1 (gdb) run Starting program: /home/matmal01/using-blr numargs called [Inferior 1 (process 33289) exited with code 012] (gdb) Test program: ---- using-blr ---- \#include <stdio.h> typedef int (foo) (int, int); typedef void (bar) (int, int); struct sls_testclass { foo *x; bar *y; int left; int right; }; __attribute__ ((noinline)) int blr_call_value (struct sls_testclass x) { int retval = x.x(x.left, x.right); if (retval % 10) return 100; return 9; } __attribute__ ((noinline)) int blr_call (struct sls_testclass x) { x.y(x.left, x.right); if (x.left % 10) return 100; return 9; } int numargs (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right) { printf("numargs called\n"); return 10; } void altfunc (__attribute__ ((unused)) int left, __attribute__ ((unused)) int right) { printf("altfunc called\n"); } int main(int argc, char **argv) { struct sls_testclass x = { .x = numargs, .y = altfunc, .left = 1, .right = 2 }; if (argc > 2) { blr_call (x); } else blr_call_value (x); return 10; }
2021-01-27Remove extra space after @pxref in gdb.texinfoTom Tromey2-1/+5
Internally at AdaCore, documentation is still built with Texinfo 4.13. This version gave an error when building gdb.texinfo: ../../../binutils-gdb/gdb/doc/gdb.texinfo:27672: @pxref expected braces. ../../../binutils-gdb/gdb/doc/gdb.texinfo:27672: ` {dotdebug_gdb_scripts section,,The @cod...' is too long for expansion; not expanded. ... followed by many more spurious errors that were caused by this one. This patch fix the problem by removing the extra space. I don't know whether it's advisable to try to support this ancient version of Texinfo (released in 2008 apparently); but in this particular case the fix is trivial, so I'm checking it in. gdb/doc/ChangeLog 2021-01-27 Tom Tromey <tromey@adacore.com> * gdb.texinfo (Auto-loading extensions): Remove extraneous space.
2021-01-26Use debug_prefixed_printf_cond in windows-nat.cTom Tromey3-68/+89
This changes windows-nat.c and nat/windows-nat.c to use the new debug_prefixed_printf_cond facility. I tried this out on a Windows build and I think it makes the output look a little nicer. 2021-01-26 Tom Tromey <tromey@adacore.com> * windows-nat.c (DEBUG_EXEC, DEBUG_EVENTS, DEBUG_MEM) (DEBUG_EXCEPT): Use debug_prefixed_printf_cond. (windows_init_thread_list, windows_nat::handle_load_dll) (windows_nat::handle_unload_dll, windows_nat_target::resume) (windows_nat_target::resume) (windows_nat_target::get_windows_debug_event) (windows_nat_target::interrupt, windows_xfer_memory) (windows_nat_target::close): Update. * nat/windows-nat.c (DEBUG_EVENTS): Use debug_prefixed_printf_cond. (matching_pending_stop, fetch_pending_stop) (continue_last_debug_event): Update.
2021-01-26bfd: add elfcore_write_file_noteMihails Strasuns2-5/+8
Adds a trivial wrapper over elfcore_write_note, primarily to be more consistent with other ELF note helper functions and highlight NT_FILE as one of notes handled by gdb. bfd/ChangeLog: 2020-12-17 Mihails Strasuns <mihails.strasuns@intel.com> * bfd-elf.h (elfcore_write_file_note): New function. * elf.c (elfcore_write_file_note): New function. gdb/ChangeLog: 2020-12-17 Mihails Strasuns <mihails.strasuns@intel.com> * linux-tdep.c (linux_make_mappings_corefile_notes): Start using elfcore_write_file_note.
2021-01-26gdb: Add default reggroups for ARCShahab Vahedi2-0/+23
There is no reggroups set in ARC. If a "maintenance print reggroups" command is issued, the default register set is dumped (which is fine). However, if a new group is added via an XML file, then that will become the _only_ group. This behavior causes gdb.xml/tdesc-regs.exp to fail. Fixes gdb.xml/tdesc-regs.exp on ARC. gdb/ChangeLog: * arc-tdep.c (arc_add_reggroups): New function. (arc_gdbarch_init): Call arc_add_reggroups.
2021-01-26Fix the date for the last entry in gdb/ChangeLogShahab Vahedi1-1/+1
The previous patch [1] sets the date incorrectly in the ChangeLog. Sorry for the inconvenience. [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=d56834cbfb7c1
2021-01-26arc: Log "pc" value in "arc_skip_prologue"Anton Kolesov2-1/+5
Log the "pc" address upon entering "arc_skip_prologue". gdb/ChangeLog: * arc-tdep.c (arc_skip_prologue): Log "pc" address.
2021-01-26[gdb/testsuite] Fix gdb.threads/killed-outside.exp with -m32Tom de Vries2-0/+7
When running test-case gdb.threads/killed-outside.exp with target board unix/-m32, we run into: ... (gdb) PASS: gdb.threads/killed-outside.exp: get pid of inferior Executing on target: kill -9 10969 (timeout = 300) spawn -ignore SIGHUP kill -9 10969^M continue^M Continuing.^M [Thread 0xf7cb4b40 (LWP 10973) exited]^M ^M Program terminated with signal SIGKILL, Killed.^M The program no longer exists.^M (gdb) FAIL: gdb.threads/killed-outside.exp: prompt after first continue ... Fix this by allowing this output. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-26 Tom de Vries <tdevries@suse.de> * gdb.threads/killed-outside.exp: Allow regular output.
2021-01-26[gdb/testsuite] Fix gdb.opt/solib-intra-step.exp with -m32Tom de Vries2-17/+42
When running test-case gdb.opt/solib-intra-step.exp with target board unix/-m32, we run into: ... (gdb) step^M __x86.get_pc_thunk.bx () at ../sysdeps/i386/crti.S:66^M 66 ../sysdeps/i386/crti.S: No such file or directory.^M (gdb) FAIL: gdb.opt/solib-intra-step.exp: first-hit (optimized) ... The thunk is a helper function for PIC, and given that we have line info for it, we step into. Fix this by allowing the step into the thunk, and stepping out of it. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-01-26 Tom de Vries <tdevries@suse.de> * gdb.opt/solib-intra-step.exp: Handle stepping into thunk.
2021-01-25[gdb/symtab] Handle DW_AT_ranges with DW_FORM_sec_off in partial DIETom de Vries5-2/+53
While looking into a failure in gdb.go/package.exp with gcc-11, I noticed that gdb shows some complaints when loading the executable (also with gcc-10, where the test-case passes): ... $ gdb -batch -iex "set complaints 100" package.10 -ex start During symbol reading: Attribute value is not a constant (DW_FORM_sec_offset) Temporary breakpoint 1 at 0x402ae6: file gdb.go/package1.go, line 8. During symbol reading: Attribute value is not a constant (DW_FORM_sec_offset) During symbol reading: Invalid .debug_rnglists data (no base address) ... Fix this by using as_unsigned () to read DW_AT_ranges in the partial DIE reader, similar to how that is done in dwarf2_get_pc_bounds. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-25 Bernd Edlinger <bernd.edlinger@hotmail.de> Simon Marchi <simon.marchi@polymtl.ca> Tom de Vries <tdevries@suse.de> * dwarf2/read.c (partial_die_info::read): Use as_unsigned () for DW_AT_ranges. gdb/testsuite/ChangeLog: 2021-01-25 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-ranges-psym.exp (gdb_load_no_complaints): New proc. * lib/gdb.exp: Use gdb_load_no_complaints.
2021-01-25gdb/docs: add parentheses in Python examples using printMarco Barisione2-9/+13
This makes the examples work both in Python 2 and 3. gdb/doc/ChangeLog: * python.texi: Add parentheses to print statements/functions. Change-Id: I8571f2ee005acd96c7bb43f9882d19b00b2aa3db
2021-01-25Fix fixed-point regression with recent GCCTom Tromey6-19/+65
A recent version of GCC changed how fixed-point types are described. For example, a denominator in one test case now looks like: GNU_denominator (exprloc) [ 0] implicit_value: 16 byte block: 00 00 b8 9d 0d 69 55 a0 01 00 00 00 00 00 00 00 ... the difference being that this now uses exprloc and emits a DW_OP_implicit_value for the 16-byte block. (DWARF 5 still uses DW_FORM_data16.) This change was made here: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/560897.html This patch updates gdb to handle this situation. Note that, before GCC 11, this test would not give the same answer. Earlier versions of GCC fell back to GNAT encodings for this case. gdb/ChangeLog 2021-01-25 Tom Tromey <tromey@adacore.com> * dwarf2/read.c (get_mpz): New function. (get_dwarf2_rational_constant): Use it. gdb/testsuite/ChangeLog 2021-01-25 Tom Tromey <tromey@adacore.com> * gdb.ada/fixed_points.exp: Add regression test. * gdb.ada/fixed_points/fixed_points.adb (FP5_Var): New variable. * gdb.ada/fixed_points/pck.adb (Delta5, FP5_Type): New.
2021-01-25Specially handle array contexts in Ada expression resolutionTom Tromey4-3/+32
A user noticed that the Ada expression code in gdb did not automatically disambiguate an enumerator in an array context. That is, an expression like "print array(enumerator)" is not ambiguous, even if "enumerator" is declared in multiple enumerations, because the correct one can be found by examining the array's index type. This patch changes the Ada expression resolution code to handle this case. gdb/ChangeLog 2021-01-25 Tom Tromey <tromey@adacore.com> * ada-lang.c (resolve_subexp): Handle array context. gdb/testsuite/ChangeLog 2021-01-25 Tom Tromey <tromey@adacore.com> * gdb.ada/local-enum.exp: Add enumerator resolution test.
2021-01-25Add test case for symbol menu for local enumeratorsTom Tromey3-0/+116
Ada will normally present a menu to the user to allow manual disambiguation of symbols. The AdaCore internal GDB had a bug that prevented this from happening. Although this bug is not in the FSF GDB, it seemed worthwhile to write a test case to ensure this. gdb/testsuite/ChangeLog 2021-01-25 Tom Tromey <tromey@adacore.com> * gdb.ada/local-enum.exp: New file. * gdb.ada/local-enum/local.adb: New file.
2021-01-25gdb/doc: move @menu blocks to the end of their enclosing @nodeAndrew Burgess2-35/+44
The @menus should be at the end of a @node. We mostly get this right, but there's a few places where we don't. This commit fixes the 5 places we get this wrong. I manually checked the info page and read each of the offending nodes after this change and I believe they all still make sense with the menu moved. gdb/doc/ChangeLog: * gdb.texinfo (Specify Location): Move menu to the end of the node. (Auto-loading): Likewise. (Extending GDB): Likewise. (TUI): Likewise. (Operating System Information): Likewise.
2021-01-23Avoid crash when "compile" expression uses cooked registerTom Tromey2-2/+22
If the "compile" command is used with an expression that happens to require a cooked register, then GDB can crash. This patch does not fix the bug, but at least turns the crash into an error instead. 2021-01-23 Tom Tromey <tom@tromey.com> PR compile/25575 * compile/compile-loc2c.c (note_register): New function. (pushf_register_address, pushf_register): Use it.
2021-01-23Use std::vector for "registers_used" in compile featureTom Tromey9-26/+51
This changes the GDB compile code to use std::vector<bool> when computing which registers are used. This is a bit more idiomatic, but the main benefit is that it also adds some checking when the libstd++ debug mode is enabled. 2021-01-23 Tom Tromey <tom@tromey.com> * symtab.h (struct symbol_computed_ops) <generate_c_location>: Change type of "registers_used". * dwarf2/loc.h (dwarf2_compile_property_to_c): Update. * dwarf2/loc.c (dwarf2_compile_property_to_c) (locexpr_generate_c_location, loclist_generate_c_location): Change type of "registers_used". * compile/compile.h (compile_dwarf_expr_to_c) (compile_dwarf_bounds_to_c): Update. * compile/compile-loc2c.c (pushf_register_address) (pushf_register, do_compile_dwarf_expr_to_c) (compile_dwarf_expr_to_c, compile_dwarf_bounds_to_c): Change type of "registers_used". * compile/compile-c.h (generate_c_for_variable_locations): Update. * compile/compile-c-symbols.c (generate_vla_size) (generate_c_for_for_one_variable): Change type of "registers_used". (generate_c_for_variable_locations): Return std::vector. * compile/compile-c-support.c (generate_register_struct): Change type of "registers_used". (compute): Update.
2021-01-23Remove call to reset from compile_to_objectTom Tromey3-7/+15
compile_to_object declares 'error_message' and then immediately calls reset on it. It seemed better to change it to use initialization instead; and then I noticed that set_arguments could return a unique_xmalloc_ptr<char> itself. 2021-01-23 Tom Tromey <tom@tromey.com> * compile/compile-internal.h (class compile_instance) <set_arguments>: Change return type. * compile/compile.c (compile_to_object): Remove call to reset. (compile_instance::set_arguments): Change return type.
2021-01-23gdb: fix regression in copy_type_recursiveSimon Marchi3-1/+10
Commit 5b7d941b90d1 ("gdb: add owner-related methods to struct type") introduced a regression when running gdb.base/jit-reader-simple.exp and others. A NULL pointer dereference happens here: #3 0x0000557b7e9e8650 in gdbarch_obstack (arch=0x0) at /home/simark/src/binutils-gdb/gdb/gdbarch.c:484 #4 0x0000557b7ea5b138 in copy_type_recursive (objfile=0x614000006640, type=0x62100018da80, copied_types=0x62100018e280) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:5537 #5 0x0000557b7ea5dcbb in copy_type_recursive (objfile=0x614000006640, type=0x62100018e200, copied_types=0x62100018e280) at /home/simark/src/binutils-gdb/gdb/gdbtypes.c:5598 #6 0x0000557b802cef51 in preserve_one_value (value=0x6110000b3640, objfile=0x614000006640, copied_types=0x62100018e280) at /home/simark/src/binutils-gdb/gdb/value.c:2518 #7 0x0000557b802cf787 in preserve_values (objfile=0x614000006640) at /home/simark/src/binutils-gdb/gdb/value.c:2562 #8 0x0000557b7fbaf19b in reread_symbols () at /home/simark/src/binutils-gdb/gdb/symfile.c:2489 #9 0x0000557b7ec65d1d in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at /home/simark/src/binutils-gdb/gdb/infcmd.c:439 #10 0x0000557b7ec67a97 in run_command (args=0x0, from_tty=1) at /home/simark/src/binutils-gdb/gdb/infcmd.c:546 This is inside a TYPE_ALLOC macro. The fact that gdbarch_obstack is called means that the type is flagged as being arch-owned, but arch=0x0 means that type::arch returned NULL, probably meaning that the m_owner field contains NULL. If we look at the code before the problematic patch, in the copy_type_recursive function, we see: if (! TYPE_OBJFILE_OWNED (type)) return type; ... TYPE_OBJFILE_OWNED (new_type) = 0; TYPE_OWNER (new_type).gdbarch = get_type_arch (type); The last two lines were replaced with: new_type->set_owner (type->arch ()); get_type_arch and type->arch isn't the same thing: get_type_arch gets the type's arch owner if it is arch-owned, and gets the objfile's arch if the type is objfile owned. So it always returns non-NULL. type->arch returns the type's arch if the type is arch-owned, else NULL. So since the original type is objfile owned, it effectively made the new type arch-owned (that is good) but set the owner to NULL (that is bad). Fix this by using get_type_arch again there. I spotted one other similar change in lookup_array_range_type, in the original patch. But that one appears to be correct, as it is executed only if the type is arch-owned. Add some asserts in type::set_owner to ensure we never set a NULL owner. That would have helped catch the issue a little bit earlier, so it could help in the future. gdb/ChangeLog: * gdbtypes.c (copy_type_recursive): Use get_type_arch. * gdbtypes.h (struct type) <set_owner>: Add asserts. Change-Id: I5d8bc7bfc83b3abc579be0b5aadeae4241179a00
2021-01-23Improve gdb_tilde_expand logic.Lancelot SIX3-0/+101
Before this patch, gdb_tilde_expand would use glob(3) in order to expand tilde at the begining of a path. This implementation has limitation when expanding a tilde leading path to a non existing file since glob fails to expand. This patch proposes to use glob only to expand the tilde component of the path and leaves the rest of the path unchanged. This patch is a followup to the following discution: https://sourceware.org/pipermail/gdb-patches/2021-January/174776.html Before the patch: gdb_tilde_expand("~") -> "/home/lsix" gdb_tilde_expand("~/a/c/b") -> error() is called After the patch: gdb_tilde_expand("~") -> "/home/lsix" gdb_tilde_expand("~/a/c/b") -> "/home/lsix/a/c/b" Tested on x84_64 linux. gdb/ChangeLog: * Makefile.in (SELFTESTS_SRCS): Add unittests/gdb_tilde_expand-selftests.c. * unittests/gdb_tilde_expand-selftests.c: New file. gdbsupport/ChangeLog: * gdb_tilde_expand.cc (gdb_tilde_expand): Improve implementation. (gdb_tilde_expand_up): Delegate logic to gdb_tilde_expand. * gdb_tilde_expand.h (gdb_tilde_expand): Update description.
2021-01-23Disable bracketed paste mode in GDB testsTom Tromey2-7/+12
I have a patch to import GNU readline 8.1 into GDB. However, when running the tests, there were a number of failures due to "bracketed paste mode". This is a terminal feature that readline 8.1 enables by default. The simplest way to work around this was to always make a ".inputrc" for GDB tests that will tell readline to disable brackted paste mode. gdb/testsuite/ChangeLog 2021-01-23 Tom Tromey <tom@tromey.com> * lib/gdb.exp (default_gdb_init): Set INPUTRC to a cached file.
2021-01-22Fix expected output of gdb.base/line65535.exp with dwarf-5Bernd Edlinger2-1/+5
With gcc & binutils built from latest git revision this test case fails because the output of the break command changes and contains the full path name of the source file, while previously only the file name was printed. Fixed that by adjusting the test expectation. 2021-01-22 Bernd Edlinger <bernd.edlinger@hotmail.de> * gdb.base/line65535.exp: Fix test expectation.
2021-01-22gdb/testsuite: eliminate gdb_suppress_tests mechanismSimon Marchi20-772/+300
There is a lot of support code for the test suppression mechanism. But as far as I know, it is not useful. The gdb_suppress_tests proc is in fact disabled with this comment that has been there since forever: return; # fnf - disable pending review of results where # testsuite ran better without this I suggest to just remove everything related to test suppression, that removes some unnecessary complexity from the support code and the tests. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_test_multiple): Remove things related to test suppression. (default_gdb_exit): Likewise. (default_gdb_spawn): Likewise. (send_gdb): Likewise. (gdb_expect): Likewise. (gdb_expect_list): Likewise. (default_gdb_init): Likewise. (gdb_suppress_entire_file): Remove. (gdb_suppress_tests): Remove. (gdb_stop_suppressing_tests): Remove. (gdb_clear_suppressed): Remove. * lib/mi-support.exp (mi_uncatched_gdb_exit): Remove things related to test suppression. (default_mi_gdb_start): Likewise. (mi_gdb_reinitialize_dir): Likewise. (mi_gdb_test): Likewise. (mi_run_cmd_full): Likewise. (mi_runto_helper): Likewise. (mi_execute_to): Likewise. * lib/prompt.exp (default_prompt_gdb_start): Likewise. * gdb.base/bitfields.exp: Likewise. * gdb.base/bitfields2.exp: Likewise. * gdb.base/break.exp: Likewise. * gdb.base/call-sc.exp: Likewise. * gdb.base/callfuncs.exp: Likewise. * gdb.base/dfp-test.exp: Likewise. * gdb.base/endian.exp: Likewise. * gdb.base/exprs.exp: Likewise. * gdb.base/funcargs.exp: Likewise. * gdb.base/hbreak2.exp: Likewise. * gdb.base/recurse.exp: Likewise. * gdb.base/scope.exp: Likewise. * gdb.base/sepdebug.exp: Likewise. * gdb.base/structs.exp: Likewise. * gdb.base/until.exp: Likewise. * gdb.cp/misc.exp: Likewise. Change-Id: Ie6d3025091691ba72010faa28b85ebd417b738f7
2021-01-22gdb: add new version styleAndrew Burgess10-12/+74
This commit adds a new 'version' style, which replaces the hard coded styling currently used for GDB's version string. GDB's version number is displayed: 1. In the output of 'show version', and 2. When GDB starts up (without the --quiet option). This new style can only ever affect the first of these two cases as the second case is printed before GDB has processed any initialization files, or processed any GDB commands passed on the command line. However, because the first case exists I think this commit makes sense, it means the style is no longer hard coded into GDB, and we can add some tests that the style can be enabled/disabled correctly. This commit is an alternative to a patch Tom posted here: https://sourceware.org/pipermail/gdb-patches/2020-June/169820.html I've used the style name 'version' instead of 'startup' to reflect what the style is actually used for. If other parts of the startup text end up being highlighted I imagine they would get their own styles based on what is being highlighted. I feel this is more inline with the other style names that are already in use within GDB. I also decoupled adding this style from the idea of startup options, and the possibility of auto-saving startup options. Those ideas can be explored in later patches. This commit should probably be considered only a partial solution to issue PR cli/25956. The colours of the style are no longer hard coded, however, it is still impossible to change the styling of the version string displayed during startup, so in one sense, the styling of that string is still "hard coded". A later patch will hopefully extend GDB to allow it to adjust the version styling before the initial version string is printed. gdb/ChangeLog: PR cli/25956 * cli/cli-style.c: Add 'cli/cli-setshow.h' include. (version_style): Define. (cli_style_option::cli_style_option): Add intensity parameter, and use as appropriate. (_initialize_cli_style): Register version style set/show commands. * cli/cli-style.h (cli_style_option): Add intensity parameter. (version_style): Declare. * top.c (print_gdb_version): Use version_stype, and styled_string to print the GDB version string. gdb/doc/ChangeLog: PR cli/25956 * gdb.texinfo (Output Styling): Document version style. gdb/testsuite/ChangeLog: PR cli/25956 * gdb.base/style.exp (run_style_tests): Add version string test. (test_startup_version_string): Use version style name. * lib/gdb-utils.exp (style): Handle version style name.
2021-01-22gdb: don't print escape characters when a style is disabledAndrew Burgess4-208/+315
While working on another patch I noticed that if I disable a single style with, for example: set style filename background none set style filename foreground none set style filename intensity normal Then in some places escape characters are still injected into the output stream. This is a bit of an edge case, and I can't think when this would actually cause problems, but it still felt like a bit of an annoyance. One place where this does impact is in testing, where it becomes harder to write tight test patterns if it is not obvious when GDB will decide to inject escape sequences. It's especially annoying because depending on how something is printed then GDB might, or might not, add escape characters. So this would not add escape characters if the filename style was disabled: fprintf_filtered (file, "%ps", styled_string (file_name_style.style (), "This is a test")); But this would add escape characters: fprintf_styled (file, file_name_style.style (), "%s", "This is a test"); I tracked this down to some calls to set_output_style in utils.c. Currently some calls to set_output_style (in utils.c) are guarded like this: if (!STYLE.is_default ()) set_output_style (stream, STYLE); But some calls are not. It is the calls that are NOT guarded that cause the extra escape sequences to be emitted. My initial proposal to resolve this issue was simply to ensure that all calls to set_output_style were guarded. The patch I posted for this can be found here: https://sourceware.org/pipermail/gdb-patches/2021-January/175096.html The feedback on this proposal was that it might be better to guard against the escape sequences being emitted at a later lever, right down at emit_style_escape. So this is what this version does. In emit_style_escape we already track the currently applied style, so if the style we are being asked to switch to is the same as the currently applied style then no escape sequence needs to be emitted. Making this change immediately exposed some issues in fputs_maybe_filtered related to line wrapping. The best place to start to understand what's going on with the styling and wrapping is look at the test: gdb.base/style.exp: all styles enabled: frame when width=20 If you run this test and then examine the output in an editor so the escape sequences can be seen you'll see the duplicate escape sequences that are emitted before this patch, the compare to after this patch you'll see the set of escape sequences should be the minimum required. In order to test these changes I have rewritten the gdb.base/style.exp test script. The core of the script is now run multiple times. The first time the test is run things are as they were before, all styles are on. After that the test is rerun multiple times. Each time through a single style is disabled using the 3 explicit set calls listed above. I then repeat all the tests, however, I arrange so that the patterns for the disabled style now require no escape sequences. gdb/ChangeLog: * utils.c (emit_style_escape): Only emit an escape sequence if the requested style is different than the current applied style. (fputs_maybe_filtered): Adjust the juggling of the wrap_style, and current applied_style. (fputs_styled): Remove is_default check. (fputs_styled_unfiltered): Likewise. (vfprintf_styled_no_gdbfmt): Likewise. gdb/testsuite/ChangeLog: * gdb.base/style.exp (limited_style): New proc. (clean_restart_and_disable): New proc. (run_style_tests): New proc. Most of the old tests from this file are now in this proc. (test_startup_version_string): New proc. Reamining test from the old file is in this proc.
2021-01-22gdb/doc: don't rely on @menu item within the docsAndrew Burgess2-11/+20
The node 'Auto-loading extensions' currently relies on a @menu item to provide a set of cross-references to different parts of the manual. Additionally the menu is placed part way through the node and the text prior to the menu seems (to me) to assume that the menu will be formatted into the document. This is a bad idea as the menus are not always part of the final document (e.g. pdf output does not include the menu), when compared to the info page the pdf version of this node is less helpful as it lacks proper cross references. Menus should always be placed at the end of a node. In this commit I rewrite a paragraph to add extra cross references inline within the text. I then move the menu to the end of the node. gdb/doc/ChangeLog: * gdb.texinfo (Auto-loading extensions): Add additional cross references and move @menu to the end of the node.
2021-01-22gdb: add remote_debug_printfSimon Marchi5-150/+94
This is the next in the new-style debug macro series. For this one, I decided to omit the function name from the "Sending packet" / "Packet received" kind of prints, just because it's not very useful in that context and hinders readability more than anything else. This is completely arbitrary. This is with: [remote] putpkt_binary: Sending packet: $qTStatus#49... [remote] getpkt_or_notif_sane_1: Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: and without: [remote] Sending packet: $qTStatus#49... [remote] Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: A difference is that previously, the query packet and its reply would be printed on the same line, like this: Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes:: Now, they are printed on two lines, since each remote_debug_printf{,_nofunc} prints its own complete message including an end of line. It's probably a matter of taste, but I prefer the two-line version, it's easier to follow, especially when the query packet is long. As a result, lib/range-stepping-support.exp needs to be updated, as it currently expects the vCont packet and the reply to be on the same line. I think it's sufficient in that context to just expect the vCont packet and not the reply, since the goal is just to count how many vCont;r GDB sends. gdb/ChangeLog: * remote.h (remote_debug_printf): New. (remote_debug_printf_nofunc): New. (REMOTE_SCOPED_DEBUG_ENTER_EXIT): New. * remote.c: Use above macros throughout file. gdbsupport/ChangeLog: * common-debug.h (debug_prefixed_printf_cond_nofunc): New. * common-debug.c (debug_prefixed_vprintf): Handle a nullptr func. gdb/testsuite/ChangeLog: * lib/range-stepping-support.exp (exec_cmd_expect_vCont_count): Adjust to "set debug remote" changes. Change-Id: Ica6dead50d3f82e855c7d763f707cef74bed9fee
2021-01-22gdb: change remote_debug to boolSimon Marchi3-10/+17
As far as I can see, there are no more spots looking for a remote_debug other than true/false. If we ever want to revert to an int, we can always change it back later, but this makes things simpler for now. gdb/ChangeLog: * remote.h (remote_debug): Change to bool. * remote.c (remote_debug): Change to bool. (_initialize_remote): Adjust. Change-Id: I21aac5b4cff9dc4f75c8efaf47c23583ecabd2a6
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