aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2020-07-22gdb/jit: split jit_objfile_data in twoSimon Marchi4-31/+57
The jit_objfile_data is currently used to hold information about both objfiles that are the result of JIT compilation (JITed) and objfiles that can produce JITed objfiles (JITers). I think that this double use of the type is confusing, and that things would be more obvious if we had one type for each role. This patch splits it into: - jited_objfile_data: for data about an objfile that is the result of a JIT compilation - jiter_objfile_data: for data about an objfile which produces JITed objfiles There are now two JIT-related fields in an objfile, one for each kind. With this change, the following invariants hold: - an objfile has a non-null `jiter_data` field iff it defines the required symbols of the JIT interface - an objfile has a non-null `jited_data` field iff it is the product of JIT compilation (has been produced by some JITer) gdb/ChangeLog: 2020-07-22 Simon Marchi <simon.marchi@polymtl.ca> * jit.h (struct jit_objfile_data): Split into... (struct jiter_objfile_data): ... this ... (struct jited_objfile_data): ... and this. * objfiles.h (struct objfile) <jit_data>: Remove. <jiter_data, jited_data>: New fields. * jit.c (jit_objfile_data::~jit_objfile_data): Rename to ... (jiter_objfile_data::~jiter_objfile_data): ... this. (get_jit_objfile_data): Rename to ... (get_jiter_objfile_data): ... this. (add_objfile_entry): Update. (jit_read_descriptor): Use get_jiter_objfile_data. (jit_find_objf_with_entry_addr): Use objfile's jited_data field. (jit_breakpoint_re_set_internal): Use get_jiter_objfile_data. (jit_inferior_exit_hook): Use objfile's jited_data field.
2020-07-22gdb/jit: link to jit_objfile_data directly from the objfile structSimon Marchi4-61/+72
Remove the use of objfile_data to associate a jit_objfile_data with an objfile. Instead, directly link to a jit_objfile_data from an objfile struct. The goal is to eliminate unnecessary abstraction. The free_objfile_data function naturally becomes the destructor of jit_objfile_data. However, free_objfile_data accesses the objfile to which the data is attached, which the destructor of jit_objfile_data doesn't have access to. To work around this, add a backlink to the owning objfile in jit_objfile_data. This is however temporary, it goes away in a subsequent patch. gdb/ChangeLog: 2020-07-22 Simon Marchi <simon.marchi@polymtl.ca> * jit.h: Forward-declare `struct minimal_symbol`. (struct jit_objfile_data): Migrate to here from jit.c; also add a constructor, destructor, and an objfile* field. * jit.c (jit_objfile_data): Remove. (struct jit_objfile_data): Migrate from here to jit.h. (jit_objfile_data::~jit_objfile_data): New destructor implementation with code moved from free_objfile_data. (free_objfile_data): Delete. (get_jit_objfile_data): Update to use the jit_data field of objfile. (jit_find_objf_with_entry_addr): Ditto. (jit_inferior_exit_hook): Ditto. (_initialize_jit): Remove the call to register_objfile_data_with_cleanup. * objfiles.h (struct objfile) <jit_data>: New field.
2020-07-22gdb/jit: pass the jiter objfile as an argument to jit_event_handlerTankut Baris Aktemur4-15/+34
This is a refactoring that adds a new parameter to the `jit_event_handler` function: the JITer objfile. The goal is to distinguish which JITer triggered the JIT event, in case there are multiple JITers -- a capability that is added in a subsequent patch. gdb/ChangeLog: 2020-07-22 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * jit.h: Forward-declare `struct objfile`. (jit_event_handler): Add a second parameter, the JITer objfile. * jit.c (jit_read_descriptor): Change the signature to take the JITer objfile as an argument instead of the jit_program_space_data. (jit_inferior_init): Update the call to jit_read_descriptor. (jit_event_handler): Use the new JITer objfile argument when calling jit_read_descriptor. * breakpoint.c (handle_jit_event): Update the call to jit_event_handler to pass the JITer objfile.
2020-07-21Retire the now-unused gdbarch handle_segmentation_fault hook.John Baldwin5-66/+9
* gdbarch.c: Regenerate. * gdbarch.h: Regenerate. * gdbarch.sh (handle_segmentation_fault): Remove method. * infrun.c (handle_segmentation_fault): Remove. (print_signal_received_reason): Remove call to handle_segmentation_fault.
2020-07-21Migrate the sparc64 ADI handle_segmentation_fault hook to report_signal_info.John Baldwin2-6/+14
gdb/ChangeLog: * sparc64-linux-tdep.c (sparc64_linux_handle_segmentation_fault): Rename to sparc64_linux_report_signal_info and add siggnal argument. (sparc64_linux_init_abi): Use sparc64_linux_report_signal_info instead of sparc64_linux_handle_segmentation_fault.
2020-07-21Migrate the x86 MPX handle_segmentation_fault hook to report_signal_info.John Baldwin4-10/+21
gdb/ChangeLog: * amd64-linux-tdep.c (amd64_linux_init_abi_common): Use i386_linux_report_signal_info instead of i386_linux_handle_segmentation_fault. * i386-linux-tdep.c (i386_linux_handle_segmentation_fault): Rename to i386_linux_report_signal_info and add siggnal argument. (i386_linux_init_abi): Use i386_linux_report_signal_info instead of i386_linux_handle_segmentation_fault. * i386-linux-tdep.h (i386_linux_handle_segmentation_fault): Rename to i386_linux_report_signal_info and add siggnal argument.
2020-07-21Report architecture-specific signal information for core files.John Baldwin2-1/+9
When opening a core file, if the process terminated due to a signal, invoke the gdbarch report_signal_info hook to report architecture-specific information about the signal. gdb/ChangeLog: * corelow.c (core_target_open): Invoke gdbarch report_signal_info hook if present.
2020-07-21Add a new gdbarch hook to report additional signal information.John Baldwin5-0/+60
This is a more general version of the existing handle_segmentation_fault hook that is able to report information for an arbitrary signal, not just SIGSEGV. gdb/ChangeLog: * gdbarch.c: Regenerate. * gdbarch.h: Regenerate. * gdbarch.sh (report_signal_info): New method. * infrun.c (print_signal_received_reason): Invoke gdbarch report_signal_info hook if present.
2020-07-21gdb/python: Reuse gdb.RegisterGroup objects where possibleAndrew Burgess4-11/+61
Only create one gdb.RegisterGroup Python object for each of GDB's reggroup objects. I could have added a field into the reggroup object to hold the Python object pointer for each reggroup, however, as reggroups are never deleted within GDB, and are global (not per-architecture) a simpler solution seemed to be just to hold a single global map from reggroup pointer to a Python object representing the reggroup. Then we can reuse the objects out of this map. After this commit it is possible for a user to tell that two gdb.RegisterGroup objects are now identical when previously they were unique, however, as both these objects are read-only I don't think this should be a problem. There should be no other user visible changes after this commit. gdb/ChangeLog: * python/py-registers.c : Add 'unordered_map' include. (gdbpy_new_reggroup): Renamed to... (gdbpy_get_reggroup): ...this. Update to only create register group descriptors when needed. (gdbpy_reggroup_iter_next): Update. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-groups.exp: Additional tests.
2020-07-21gdb/python: Reuse gdb.RegisterDescriptor objects where possibleAndrew Burgess4-13/+82
Instead of having the gdb.RegisterDescriptorIterator creating new gdb.RegisterDescriptor objects for each regnum, instead cache gdb.RegisterDescriptor objects on the gdbarch object and reuse these. This means that for every gdbarch/regnum pair there is a single unique gdb.RegisterDescriptor, this feels like a neater implementation than the existing one. It is possible for a user to see (in Python code) that the descriptors are now identical, but as the descriptors are read-only this should make no real difference. There should be no other user visible changes. gdb/ChangeLog: * python/py-registers.c (gdbpy_register_object_data): New static global. (gdbpy_register_object_data_init): New function. (gdbpy_new_register_descriptor): Renamed to... (gdbpy_get_register_descriptor): ...this, and update to reuse existing register descriptors where possible. (gdbpy_register_descriptor_iter_next): Update. (gdbpy_initialize_registers): Register new gdbarch data. gdb/testsuite/ChangeLog: * gdb.python/py-arch-reg-names.exp: Additional tests.
2020-07-21gdb, gdbserver: make stopped_pids global variables staticSimon Marchi2-1/+5
I noticed that my IDE was confusing the two stopped_pids variables. There is one in GDB and one in GDBserver. They should be static, make them so. gdb/ChangeLog: * linux-nat.c (stopped_pids): Make static. gdbserver/ChangeLog: * linux-low.cc (stopped_pids): Make static. Change-Id: If4a2bdcd45d32eb3a732d266a0f686a4e4c23672
2020-07-21gdb: handle undefined properties in ada_discrete_type_{low,high}_boundSimon Marchi2-2/+36
This patch fixes a failure in test `gdb.ada/access_to_packed_array.exp`. The failure was introduced by 8c2e4e0689ea24 ("gdb: add accessors to struct dynamic_prop"), but I think it in fact exposed a latent buglet. Note that to reproduce it, I had to use AdaCore's Ada "distribution" [1]. The one that comes with my distro doesn't have debug info for the standard library stuff, so the bug wouldn't trigger. The bug is that while executing the `maint print symbols` command, we are accessing the value of a range type's high bound dynamic prop as a "const" value (PROP_CONST), when it is actually undefined (PROP_UNDEFINED). It results in this failed assertion: /home/simark/src/binutils-gdb/gdb/gdbtypes.h:526: internal-error: LONGEST dynamic_prop::const_val() const: Assertion `m_kind == PROP_CONST' failed. `ada_discrete_type_high_bound` calls `resolve_dynamic_type`, which eventually calls `resolve_dynamic_range`. This one is responsible for evaluating a range type's dynamic bounds in the current context and returning static values. It returns a new range type with these static bounds. The resulting bounds are typically properties of the PROP_CONST kind. But when it's not possible to evaluate the properties, the properties are PROP_UNDEFINED. In the case we are looking at, it's not possible to evaluate the dynamic high bound, which is of type PROP_LOCLIST. It would require a target with registers and a frame, but we run `maint print symbols` without a live process. `ada_discrete_type_high_bound` then accesses the high bound unconditionally as a const value, which triggers the assert. Note that the previous code in resolve_dynamic_range (before commit 8c2e4e0689ea24) did this: prop = &TYPE_RANGE_DATA (dyn_range_type)->high; if (dwarf2_evaluate_property (prop, NULL, addr_stack, &value)) { high_bound.kind = PROP_CONST; high_bound.data.const_val = value; if (TYPE_RANGE_DATA (dyn_range_type)->flag_upper_bound_is_count) high_bound.data.const_val = low_bound.data.const_val + high_bound.data.const_val - 1; } else { high_bound.kind = PROP_UNDEFINED; high_bound.data.const_val = 0; } That did not really made sense, setting the kind to `PROP_UNDEFINED` but also setting the `const_val` field. The `const_val` field is only meaningful if the kind if `PROP_CONST`. The new code (post-8c2e4e0689ea24) simply calls `set_undefined ()`. Fix this by making the caller, `ada_discrete_type_high_bound`, consider that a range high bound could be of kind `PROP_UNDEFINED`, and return 0 in this case. I made the same change in ada_discrete_type_low_bound. I didn't encounter a problem with this function, but the same could in theory happen there. Returning 0 here is kind of a lie, but the goal here is just to restore the behavior of pre-8c2e4e0689ea24. The output of `maint print symbols` is: typedef <ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0; record ada__exceptions__exception_data__append_info_basic_exception_information__TTnameSP1: range 1 .. 0; end record; Instead of `1 .. 0`, which does not make sense, we could say something like `1 .. <dynamic>`. But that would require more changes than I'm willing to do at the moment. [1] https://www.adacore.com/download gdb/ChangeLog: PR ada/26235 * gdbtypes.c (ada_discrete_type_low_bound, ada_discrete_type_high_bound): Handle undefined bounds. Change-Id: Ia12167e61ef030941c0790f83294f3418e6a7c12
2020-07-21[gdb/testsuite] Fix gdb.reverse/solib-{precsave,reverse}.exp with gcc-8Tom de Vries3-6/+60
With gcc-8, we have the following FAILs, which are not there for gcc-7: ... FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function one FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function one FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main one FAIL: gdb.reverse/solib-precsave.exp: reverse-step into solib function two FAIL: gdb.reverse/solib-precsave.exp: reverse-step within solib function two FAIL: gdb.reverse/solib-precsave.exp: reverse-step back to main two FAIL: gdb.reverse/solib-precsave.exp: run until end part two FAIL: gdb.reverse/solib-precsave.exp: reverse-next over solib function one FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main one FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two FAIL: gdb.reverse/solib-reverse.exp: reverse-step back to main two FAIL: gdb.reverse/solib-reverse.exp: run until end part two FAIL: gdb.reverse/solib-reverse.exp: reverse-next over solib function one ... Looking at the first FAIL for gdb.reverse/solib-precsave.exp, we have: ... (gdb) PASS: reverse-next first shr1 reverse-next^M 40 b[0] = 6; b[1] = 9; /* generic statement, end part two */^M (gdb) PASS: reverse-next generic reverse-step^M -shr2 (x=17) at gdb.reverse/shr2.c:23^M -23 }^M -(gdb) PASS: reverse-step into solib function one +38 b[1] = shr2(17); /* middle part two */^M +(gdb) FAIL: reverse-step into solib function one ... There's a difference in line number info for line 38, where for gcc-7 we have: ... Line number Starting address View Stmt 38 0x4005c6 x ... and for gcc-8: ... 38 0x4005c1 x 38 0x4005cb x ... which explains why we don't step directly into "solib function one". Fix this by recognizing the extra "recommended breakpoint location" and issuing an additional reverse-next/step. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.reverse/solib-precsave.exp: Handle additional "recommended breakpoint locations". * gdb.reverse/solib-reverse.exp: Same.
2020-07-21[gdb/testsuite] Fix step-reverse.c with gcc-10Tom de Vries2-1/+5
The file gdb.reverse/step-reverse.c is used in test-cases: - gdb.reverse/step-reverse.exp - gdb.reverse/next-reverse-bkpt-over-sr.exp - gdb.reverse/step-precsave.exp With gcc-7, there are only PASSes (apart from one KFAIL), but with gcc-10, we have the following FAILs: ... FAIL: gdb.reverse/step-reverse.exp: reverse stepi from a function call \ (start statement) FAIL: gdb.reverse/step-reverse.exp: simple reverse stepi FAIL: gdb.reverse/step-reverse.exp: reverse step out of called fn FAIL: gdb.reverse/step-reverse.exp: reverse next over call FAIL: gdb.reverse/step-reverse.exp: reverse step test 1 FAIL: gdb.reverse/step-reverse.exp: reverse next test 1 FAIL: gdb.reverse/step-reverse.exp: reverse step test 2 FAIL: gdb.reverse/step-reverse.exp: reverse next test 2 FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \ (start statement) FAIL: gdb.reverse/step-precsave.exp: simple reverse stepi FAIL: gdb.reverse/step-precsave.exp: reverse step out of called fn FAIL: gdb.reverse/step-precsave.exp: reverse next over call FAIL: gdb.reverse/step-precsave.exp: reverse step test 1 FAIL: gdb.reverse/step-precsave.exp: reverse next test 1 FAIL: gdb.reverse/step-precsave.exp: reverse step test 2 FAIL: gdb.reverse/step-precsave.exp: reverse next test 2 ... Looking at the first step-precsave.exp FAIL, we have: ... (gdb) stepi^M 26 myglob++; return 0; /* ARRIVED IN CALLEE */^M (gdb) PASS: gdb.reverse/step-precsave.exp: reverse stepi thru function return stepi^M 0x000000000040055f 26 myglob++; return 0; /* ARRIVED IN CALLEE */^M (gdb) FAIL: gdb.reverse/step-precsave.exp: reverse stepi from a function call \ (start statement) ... There's a difference in line info for callee: ... 25 int callee() { /* ENTER CALLEE */ 26 myglob++; return 0; /* ARRIVED IN CALLEE */ 27 } /* RETURN FROM CALLEE */ ... between gcc-7: ... Line number Starting address View Stmt 25 0x400557 x 26 0x40055b x 27 0x40056f x ... and gcc-10: ... 25 0x400552 x 26 0x400556 x 26 0x400565 x 27 0x40056a x ... The two "recommend breakpoint location" entries at line 26 are for the two statements ("myglob++" and "return 0"), but the test-case expects to hit line 26 only once. Fix this by rewriting the two statements into a single statement: ... - myglob++; return 0; /* ARRIVED IN CALLEE */ + return myglob++; /* ARRIVED IN CALLEE */ ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.reverse/step-reverse.c (callee): Merge statements.
2020-07-21Enable multi-process mode in the NetBSD native target.Kamil Rytarowski3-0/+16
This enables proper support for multiple inferiors and ptrace(2) assisted management of the inferior processes and their threads. (gdb) info inferior Num Description Connection Executable * 1 process 14952 1 (native) /usr/bin/dig 2 <null> 1 (native) 3 process 25684 1 (native) /bin/ls 4 <null> 1 (native) /bin/ls Without this patch, additional inferiors can be added, but not properly controlled. gdb/ChangeLog: * nbsd-nat.h (nbsd_nat_target::supports_multi_process): New declaration. * nbsd-nat.c (nbsd_nat_target::supports_multi_process): New function.
2020-07-21[gdb/testsuite] Fix gdb.fortran/info-modules.exp with gcc-8Tom de Vries2-2/+7
When using test-case gdb.fortran/info-modules.exp with gcc 8.4.0, I run into: ... FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \ 'info-types.f90', '35', 'Type m1t1 mod1::__def_init_mod1_M1t1;' FAIL: gdb.fortran/info-modules.exp: info module variables: check for entry \ 'info-types.f90', '35', 'Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1;' ... This is caused by this change in gdb output: ... (gdb) info module variables ... File gdb.fortran/info-types.f90: -35: Type m1t1 mod1::__def_init_mod1_M1t1; + Type m1t1 mod1::__def_init_mod1_M1t1; -35: Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1; + Type __vtype_mod1_M1t1 mod1::__vtab_mod1_M1t1; 21: real(kind=4) mod1::mod1_var_1; 22: integer(kind=4) mod1::mod1_var_2; ... caused by a change in debug info. Fix this by allowing those entries without line number. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.fortran/info-modules.exp (info module variables): Allow missing line numbers for some variables.
2020-07-21[gdb/testsuite] Make inline-locals.c deterministicTom de Vries3-1/+16
When running testcase gdb.opt/inline-locals.exp on openSUSE Tumbleweed, I get: ... (gdb) info locals^M array = {0 <repeats 48 times>, 15775231, 0, 194, 0, -11497, 32767, 4199061, \ 0, 0, 0, 0, 0, 4198992, 0, 4198432, 0}^M (gdb) FAIL: gdb.opt/inline-locals.exp: info locals above bar 2 ... Fix this by: - completely initializing array before printing any value - updating the pattern to match "array = {0 <repeats 64 times>}" Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.opt/inline-locals.c (init_array): New func. (func1): Use init_array. * gdb.opt/inline-locals.exp: Update pattern.
2020-07-21[gdb/testsuite] Don't leak env vars in gdb.debuginfod/fetch_src_and_symbols.expTom de Vries2-89/+125
Test-case gdb.debuginfod/fetch_src_and_symbols.exp leaks env vars DEBUGINFOD_URLS, DEBUGINFOD_TIMEOUT and DEBUGINFOD_CACHE_PATH, causing timeouts in subsequent tests. Fix this by using save_vars. Also, fix PATH and DUPLICATE errors. Finally, cleanup whitespace. gdb/testsuite/ChangeLog: 2020-07-21 Tom de Vries <tdevries@suse.de> * gdb.debuginfod/fetch_src_and_symbols.exp: Use save_vars for env vars. Fix PATH and DUPLICATE errors. Cleanup whitespace.
2020-07-20Implement the skip_solib_resolver gdbarch hook for FreeBSD architectures.John Baldwin4-0/+44
The ELF runtime linker on all FreeBSD architectures uses the "_rtld_bind" entry point for unresolved PTL entries. FreeBSD/mips has an additional entry point called "_mips_rtld_bind". gdb/ChangeLog: * fbsd-tdep.c (fbsd_skip_solib_resolver): New function. (fbsd_init_abi): Install gdbarch "skip_solib_resolver" method. * fbsd-tdep.h (fbsd_skip_solib_resolver): New prototype. * mips-fbsd-tdep.c (mips_fbsd_skip_solib_resolver): New function. (mips_fbsd_init_abi): Install gdbarch "skip_solib_resolver" method.
2020-07-20guile: Add support for Guile 3.0.Ludovic Courtès10-10/+29
gdb/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * guile/scm-math.c (vlscm_integer_fits_p): Use 'uintmax_t' and 'intmax_t' instead of 'scm_t_uintmax' and 'scm_t_intmax', which are deprecated in Guile 3.0. * configure.ac (try_guile_versions): Add "guile-3.0". * configure (try_guile_versions): Regenerate. * NEWS: Update entry. gdb/testsuite/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * gdb.guile/source2.scm: Add #f first argument to 'format'. * gdb.guile/types-module.exp: Remove "ERROR:" from regexps since Guile 3.0 no longer prints that. gdb/doc/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * doc/guile.texi (Guile Introduction): Mention Guile 3.0. Change-Id: Iff116c2e40f334e4e0ca4e759a097bfd23634679
2020-07-20guile: Add support for Guile 2.2.Ludovic Courtès9-175/+542
This primarily updates code that uses the I/O port API of Guile. gdb/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> Doug Evans <dje@google.com> PR gdb/21104 * guile/scm-ports.c (USING_GUILE_BEFORE_2_2): New macro. (ioscm_memory_port)[read_buf_size, write_buf_size]: Wrap in #if USING_GUILE_BEFORE_2_2. (stdio_port_desc, memory_port_desc) [!USING_GUILE_BEFORE_2_2]: Change type to 'scm_t_port_type *'. (natural_buffer_size) [!USING_GUILE_BEFORE_2_2]: New variable. (ioscm_open_port) [USING_GUILE_BEFORE_2_2]: Add 'stream' parameter and honor it. Update callers. (ioscm_open_port) [!USING_GUILE_BEFORE_2_2]: New function. (ioscm_read_from_port, ioscm_write) [!USING_GUILE_BEFORE_2_2]: New functions. (ioscm_fill_input, ioscm_input_waiting, ioscm_flush): Wrap in #if USING_GUILE_BEFORE_2_2. (ioscm_init_gdb_stdio_port) [!USING_GUILE_BEFORE_2_2]: Use 'ioscm_read_from_port'. Call 'scm_set_port_read_wait_fd'. (ioscm_init_stdio_buffers) [!USING_GUILE_BEFORE_2_2]: New function. (gdbscm_stdio_port_p) [!USING_GUILE_BEFORE_2_2]: Use 'SCM_PORTP' and 'SCM_PORT_TYPE'. (gdbscm_memory_port_end_input, gdbscm_memory_port_seek) (ioscm_reinit_memory_port): Wrap in #if USING_GUILE_BEFORE_2_2. (gdbscm_memory_port_read, gdbscm_memory_port_write) (gdbscm_memory_port_seek, gdbscm_memory_port_close) [!USING_GUILE_BEFORE_2_2]: New functions. (gdbscm_memory_port_print): Remove use of 'SCM_PTOB_NAME'. (ioscm_init_memory_port_type) [!USING_GUILE_BEFORE_2_2]: Use 'gdbscm_memory_port_read'. Wrap 'scm_set_port_end_input', 'scm_set_port_flush', and 'scm_set_port_free' calls in #if USING_GUILE_BEFORE_2_2. (gdbscm_get_natural_buffer_sizes) [!USING_GUILE_BEFORE_2_2]: New function. (ioscm_init_memory_port): Remove. (ioscm_init_memory_port_stream): New function (ioscm_init_memory_port_buffers) [USING_GUILE_BEFORE_2_2]: New function. (gdbscm_memory_port_read_buffer_size) [!USING_GUILE_BEFORE_2_2]: Return scm_from_uint (0). (gdbscm_set_memory_port_read_buffer_size_x) [!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'. (gdbscm_memory_port_write_buffer_size) [!USING_GUILE_BEFORE_2_2]: Return scm_from_uint (0). (gdbscm_set_memory_port_write_buffer_size_x) [!USING_GUILE_BEFORE_2_2]: Call 'scm_setvbuf'. * configure.ac (try_guile_versions): Add "guile-2.2". * configure: Regenerate. * NEWS: Add entry. gdb/testsuite/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * gdb.guile/scm-error.exp ("source $remote_guile_file_1"): Relax error regexp to match on Guile 2.2. gdb/doc/ChangeLog 2020-06-28 Ludovic Courtès <ludo@gnu.org> * guile.texi (Memory Ports in Guile): Mark 'memory-port-read-buffer-size', 'set-memory-port-read-buffer-size!', 'memory-port-write-buffer-size', 'set-memory-port-read-buffer-size!' as deprecated. * doc/guile.texi (Guile Introduction): Clarify which Guile versions are supported. Change-Id: Ib119b10a2787446e0ae482a5e1b36d809c44bb31
2020-07-20Skip tests requiring "alignof (void)" when compiling using clangGary Benson2-1/+17
As an extension, GCC allows void pointer arithmetic, with sizeof(void) and alignof(void) both 1. GDB supports this extension, but clang does not, and fails to compile the generated output of gdb.cp/align.exp with the following error: gdb compile failed, /gdbtest/build/gdb/testsuite/outputs/gdb.cp/align/align.cc:28:23: error: invalid application of 'alignof' to an incomplete type 'void' unsigned a_void = alignof (void); ^ ~~~~~~ 1 error generated. This commit adds preprocessor conditionals to the generated output, to omit the unsupported code when using clang, and supplies the expected value so the test can complete. gdb/testsuite/ChangeLog: * gdb.cp/align.exp: Fix "alignof (void)" tests when compiling with clang.
2020-07-20[gdb/testsuite] Stabilize execution order in omp-par-scope.cTom de Vries2-0/+55
In openmp test-case gdb.threads/omp-par-scope.exp we xfail and kfail dependent on omp_get_thread_num (). Since execution order of the threads can vary from execution to execution, this can cause changes in test results. F.i., we can see this difference between two test runs: ... -KFAIL: single_scope: first thread: print i3 (PRMS: gdb/22214) +PASS: single_scope: first thread: print i3 -PASS: single_scope: second thread: print i3 +KFAIL: single_scope: second thread: print i3 (PRMS: gdb/22214) ... In both cases, the KFAIL is for omp_get_thread_num () == 1, but in one case that corresponds to the first thread executing that bit of code, and in the other case to the second thread. Get rid of this difference by stabilizing execution order. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-20 Tom de Vries <tdevries@suse.de> * gdb.threads/omp-par-scope.c (lock, lock2): New variable. (omp_set_lock_in_order): New function. (single_scope, multi_scope, nested_func, nested_parallel): Use omp_set_lock_in_order and omp_unset_lock. (main): Init and destroy lock and lock2.
2020-07-20[gdb/testsuite] Fix valgrind-infcall-2.exp without libc debug infoTom de Vries2-1/+5
When running test-case gdb.base/valgrind-infcall-2.exp on a system without libc debug info installed, I run into: ... (gdb) p printf ("bla")^M 'printf' has unknown return type; cast the call to its declared return type^M (gdb) FAIL: gdb.base/valgrind-infcall-2.exp: do printf ... Fix this by casting the result of the printf call to int. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-20 Tom de Vries <tdevries@suse.de> * gdb.base/valgrind-infcall-2.exp: Handle printf unknown return type.
2020-07-20[gdb/testsuite] Bail out after gdb_start error in ↵Tom de Vries2-1/+10
gdb.threads/attach-slow-waitpid.exp When building gdb using CFLAGS/CXXFLAGS+=-fsanitizer=address and LDFLAGS+=-lasan, and running test-case gdb.threads/attach-slow-waitpid.exp, we get: ... spawn gdb -nw -nx -data-directory data-directory^M ==16079==ASan runtime does not come first in initial library list; \ you should either link runtime to your application or manually preload \ it with LD_PRELOAD.^M ERROR: (eof) GDB never initialized. ERROR: : spawn id exp10 not open while executing "expect { -i exp10 -timeout 120 -re "Kill the program being debugged. .y or n. $" { send_gdb "y\n" answer verbose "\t\tKilling previous pro..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE : spawn id exp10 not open WARNING: remote_expect statement without a default case ERROR: : spawn id exp10 not open while executing "expect { -i exp10 -timeout 120 -re "Reading symbols from.*LZMA support was disabled.*$gdb_prompt $" { verbose "\t\tLoaded $arg into $GDB; .gnu_..." ("uplevel" body line 1) invoked from within "uplevel $body" NONE : spawn id exp10 not open ERROR: Couldn't load attach-slow-waitpid into GDB (eof). ERROR: Couldn't send attach 16070 to GDB. UNRESOLVED: gdb.threads/attach-slow-waitpid.exp: attach to target ... Bail out at the first ERROR, such that we have instead: ... ERROR: (eof) GDB never initialized. UNTESTED: gdb.threads/attach-slow-waitpid.exp: \ Couldn't start GDB with preloaded lib ... Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-20 Tom de Vries <tdevries@suse.de> * gdb.threads/attach-slow-waitpid.exp: Bail out if gdb_start fails.
2020-07-18Remove "linux_multi_process" globalTom Tromey2-6/+6
The "linux_multi_process" is initialized but never modified. I discussed this with Pedro on irc, and he said that, while it was useful when developing this feature, it is now no longer needed. So, this removes it. gdb/ChangeLog 2020-07-18 Tom Tromey <tom@tromey.com> * linux-nat.c (linux_multi_process): Remove. (linux_nat_target::supports_multi_process): Return true.
2020-07-17gdb/riscv: delete target descriptions when gdb exitsAndrew Burgess4-15/+21
It was pointed out on IRC that the RISC-V target allocates target descriptions and stores them in a global map, and doesn't delete these target descriptions when GDB shuts down. This isn't a particular problem, the total number of target descriptions we can create is very limited so creating these on demand and holding them for the entire run on GDB seems reasonable. However, not deleting these objects on GDB exit means extra warnings are printed from tools like valgrind, and the address sanitiser, making it harder to spot real issues. As it's reasonably easy to have GDB correctly delete these objects on exit, lets just do that. I started by noticing that we already have a target_desc_up type, a wrapper around unique_ptr that calls a function that will correctly delete target descriptions, so I want to use that, but.... ...that type is declared in gdb/target-descriptions.h. If I try to include that file in gdb/arch/riscv.c I run into a problem, that file is compiled into both GDB and GDBServer. OK, I could guard the include with #ifdef, but surely we can do better. So then I decided to move the target_desc_up type into gdbsupport/tdesc.h, this is the interface file for generic code shared between GDB and GDBserver (relating to target descriptions). The actual implementation for the delete function still lives in gdb/target-description.c, but now gdb/arch/riscv.c can see the declaration. Problem solved.... ... but, though RISC-V doesn't use it I've now exposed the target_desc_up type to gdbserver, so in future someone _might_ start using it, which is fine, except right now there's no definition of the delete function - remember the delete I used is only defined in GDB code. No problem, I add an implementation of the delete operator into gdbserver/tdesc.cc, and all is good..... except.... I start getting this error from GCC: tdesc.cc:109:10: error: deleting object of polymorphic class type ‘target_desc’ which has non-virtual destructor might cause undefined behavior [-Werror=delete-non-virtual-dtor] Which is caused because gdbserver's target_desc type inherits from tdesc_element which has a virtual method, and so GCC worries that target_desc might be used as a base class. The solution is to declare gdbserver's target_desc class as final. This is fine so long as we never intent to inherit from target_desc (in gdbserver). But if we did then we'd want to make target_desc's destructor virtual anyway, so the error above would be resolved, and there wouldn't be an issue. gdb/ChangeLog: * arch/riscv.c (riscv_tdesc_cache): Change map type. (riscv_lookup_target_description): Return pointer out of unique_ptr. * target-descriptions.c (allocate_target_description): Add comment. (target_desc_deleter::operator()): Likewise. * target-descriptions.h (struct target_desc_deleter): Moved to gdbsupport/tdesc.h. (target_desc_up): Likewise. gdbserver/ChangeLog: * tdesc.cc (allocate_target_description): Add header comment. (target_desc_deleter::operator()): New function. * tdesc.h (struct target_desc): Declare as final. gdbsupport/ChangeLog: * tdesc.h (struct target_desc_deleter): Moved here from gdb/target-descriptions.h, extend comment. (target_desc_up): Likewise.
2020-07-17[gdb/testsuite] Add gdb.base/valgrind-infcall-2.expTom de Vries4-13/+131
In commit ee3c5f8968 "Fix GDB crash when registers cannot be modified", we fix a GDB crash: ... $ valgrind /usr/bin/sleep 10000 ==31595== Memcheck, a memory error detector ==31595== Command: /usr/bin/sleep 10000 ==31595== $ gdb /usr/bin/sleep (gdb) target remote | vgdb --pid=31595 Remote debugging using | vgdb --pid=31595 ... $hex in __GI___nanosleep () at nanosleep.c:27 27 return SYSCALL_CANCEL (nanosleep, requested_time, remaining); (gdb) p printf ("bla") terminate called after throwing an instance of 'gdb_exception_error' Aborted (core dumped) ... This patch adds a test-case for it. Unfortunately, I was not able to trigger the error condition using a regular vgdb_start, so I've added a parameter active_at_startup, and when set to 0 this causes valgrind to be started without --vgdb-error=0. Tested on x86_64-linux. Tested with the commit mentioned above reverted, resulting in: ... (gdb) p printf ("bla")^M terminate called after throwing an instance of 'gdb_exception_error'^M ERROR: GDB process no longer exists GDB process exited with wait status 6152 exp10 0 0 CHILDKILLED SIGABRT SIGABRT UNRESOLVED: gdb.base/valgrind-infcall-2.exp: do printf ... gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * gdb.base/valgrind-infcall-2.c: New test. * gdb.base/valgrind-infcall-2.exp: New file. * lib/valgrind.exp (vgdb_start): Add and handle active_at_startup.
2020-07-17Use boolean literals in linux-nat.cTom Tromey2-4/+11
I noticed a couple of spots in linux-nat.c that use 0/1 where boolean literals would be more idiomatic. This patch makes this change. gdb/ChangeLog 2020-07-17 Tom Tromey <tromey@adacore.com> * linux-nat.c (linux_nat_target::supports_non_stop) (linux_nat_target::always_non_stop_p): Use "true". (linux_nat_target::supports_disable_randomization): Use "true" and "false".
2020-07-17[gdb/testsuite] Use MACRO_AT_{func,range}Tom de Vries23-198/+64
Use dwarf assembly procs MACRO_AT_func and MACRO_AT_range in test-cases where that's appropriate. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * gdb.dlang/circular.c (found): Use found_label as label name. * gdb.dwarf2/arr-subrange.c (main): Use main_label as label name. * gdb.dwarf2/comp-unit-lang.c (func): Use func_label as label name. * gdb.dlang/circular.exp: Use MACRO_AT_func and MACRO_AT_range. * gdb.dwarf2/ada-linkage-name.exp: Same. * gdb.dwarf2/arr-subrange.exp: Same. * gdb.dwarf2/atomic-type.exp: Same. * gdb.dwarf2/comp-unit-lang.exp: Same. * gdb.dwarf2/cpp-linkage-name.exp: Same. * gdb.dwarf2/dw2-bad-mips-linkage-name.exp: Same. * gdb.dwarf2/dw2-lexical-block-bare.exp: Same. * gdb.dwarf2/dw2-regno-invalid.exp: Same. * gdb.dwarf2/implptr-64bit.exp: Same. * gdb.dwarf2/imported-unit-abstract-const-value.exp: Same. * gdb.dwarf2/imported-unit-runto-main.exp: Same. * gdb.dwarf2/imported-unit.exp: Same. * gdb.dwarf2/main-subprogram.exp: Same. * gdb.dwarf2/missing-type-name.exp: Same. * gdb.dwarf2/nonvar-access.exp: Same. * gdb.dwarf2/struct-with-sig.exp: Same. * gdb.dwarf2/typedef-void-finish.exp: Same. * gdb.dwarf2/void-type.exp: Same.
2020-07-17[gdb/testsuite] Drop src arg of MACRO_AT_{func,range}Tom de Vries17-45/+47
The dwarf assembly procs MACRO_AT_func and MACRO_AT_range have a src parameter, which is set to $srcdir/$subdir/$srcfile in every single call. Drop the src parameter and hardcode usage of $srcdir/$subdir/$srcfile in the procs. Build and reg-tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * lib/dwarf.exp (Dwarf::MACRO_AT_func, Dwarf::MACRO_AT_range): Drop src parameter. * gdb.dlang/watch-loc.exp: Update MACRO_AT_{func,range} calls. * gdb.dwarf2/bitfield-parent-optimized-out.exp: Same. * gdb.dwarf2/dw2-ifort-parameter.exp: Same. * gdb.dwarf2/dw2-opt-structptr.exp: Same. * gdb.dwarf2/dwz.exp: Same. * gdb.dwarf2/implptr-optimized-out.exp: Same. * gdb.dwarf2/implref-array.exp: Same. * gdb.dwarf2/implref-const.exp: Same. * gdb.dwarf2/implref-global.exp: Same. * gdb.dwarf2/implref-struct.exp: Same. * gdb.dwarf2/info-locals-optimized-out.exp: Same. * gdb.dwarf2/opaque-type-lookup.exp: Same. * gdb.dwarf2/var-access.exp: Same. * gdb.dwarf2/varval.exp: Same. * gdb.trace/entry-values.exp: Same.
2020-07-17[gdb/testsuite] Remove Dwarf::externTom de Vries12-28/+14
The file lib/dwarf.exp contains: ... # Declare a global label. This is typically used to refer to # labels defined in other files, for example a function defined in # a .c file. proc extern {args} { foreach name $args { _op .global $name } } ... The assembler directive to refer to labels defined in other files is not .global, but .extern, and that one is ignored by gas. Since we require gas for all dwarf assembly test-cases, remove the proc and all it's uses. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-17 Tom de Vries <tdevries@suse.de> * lib/dwarf.exp (Dwarf::extern): Remove. * gdb.compile/compile-ops.exp: Remove use of Dwarf::extern. * gdb.dlang/circular.exp: Same. * gdb.dwarf2/comp-unit-lang.exp: Same. * gdb.dwarf2/dw2-ifort-parameter.exp: Same. * gdb.dwarf2/dw2-symtab-includes.exp: Same. * gdb.dwarf2/dwz.exp: Same. * gdb.dwarf2/imported-unit-abstract-const-value.exp: Same. * gdb.dwarf2/imported-unit-runto-main.exp: Same. * gdb.dwarf2/imported-unit.exp: Same. * gdb.dwarf2/opaque-type-lookup.exp: Same.
2020-07-16Fix POSIX-isms in gdb.base/shell.expSandra Loosemore2-10/+21
Some recent tests added to gdb.base/shell.exp have been failing on Windows host due to assumptions that the shell is a POSIX variant. On Windows, GDB uses CMD.EXE via the system() call to run shell commands instead. There seems to be no obvious CMD.EXE equivalent for "kill -2 $$" to signal the shell process, so this patch skips those tests on Windows host. The second problem addressed here is that CMD.EXE only recognizes double quotes, not single quotes; that change can be made unconditionally since POSIX shells recognize double quotes as well. 2020-07-16 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.base/shell.exp: Skip pipe tests dependent on sh on Windows host. Use double quotes instead of single quotes.
2020-07-16gdb: fix issues with handling DWARF v5 rnglists & .dwo files.Caroline Tice5-48/+398
While experimenting with GDB on DWARF 5 with split debug (dwo files), I discovered that GDB was not reading the rnglist index properly (it needed to be reprocessed in the same way the loclist index does), and that there was no code for reading rnglists out of dwo files at all. Also, the rnglist address reading function (dwarf2_rnglists_process) was adding the base address to all rnglist entries, when it's only supposed to add it to the DW_RLE_offset_pair entries (http://dwarfstd.org/doc/DWARF5.pdf, p. 53), and was not handling several entry types. - Added 'reprocessing' for reading rnglist index (as is done for loclist index). - Added code for reading rnglists out of .dwo files. - Added several missing rnglist forms to dwarf2_rnglists_process. - Fixed bug that was alwayas adding base address for rnglists (only one form needs that). - Updated dwarf2_rnglists_process to read rnglist out of dwo file when appropriate. - Added new functions cu_debug_rnglist_section & read_rnglist_index. - Added new testcase, dw5-rnglist-test.{cc,exp} Special note about the new testcase: In order for the test case to test anything meaningful, it must be compiled with clang, not GCC. The way to do this is as follows: $ make check RUNTESTFLAGS="CC_FOR_TARGET=/path/to/clang CXX_FOR_TARGET=/path/to/clang++ dw5-rnglist-test.exp" This following version of clang was used for this testing: clang version 9.0.1-11 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Change-Id: I3053c5ddc345720b8ed81e23a88fe537ab38748d
2020-07-16[gdb/testsuite] Add pseudo line number program instruction: lineTom de Vries8-99/+100
There's an idiom in dwarf assembly test-cases: ... set line1 [gdb_get_line_number "line 1"] set line2 [gdb_get_line_number "line 2"] set line3 [gdb_get_line_number "line 3"] ... {DW_LNS_advance_line [expr $line1 - 1]} ... {DW_LNS_advance_line [expr $line2 - $line1]} ... {DW_LNS_advance_line [expr $line3 - $line2]} ... Add a pseudo line number program instruction "line", such that we can simply write: ... {line $line1} ... {line $line2} ... {line $line3} ... Build and reg-tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-16 Tom de Vries <tdevries@suse.de> * lib/dwarf.exp (program): Initialize _line. (DW_LNE_end_sequence): Reinitialize _line. (DW_LNS_advance_line): Update _line. (line): New proc. * gdb.dwarf2/dw2-inline-many-frames.exp: Use line. * gdb.dwarf2/dw2-inline-small-func.exp: Same. * gdb.dwarf2/dw2-inline-stepping.exp: Same. * gdb.dwarf2/dw2-is-stmt-2.exp: Same. * gdb.dwarf2/dw2-is-stmt.exp: Same. * gdb.dwarf2/dw2-ranges-func.exp: Same.
2020-07-15gdb/testsuite: Update test pattern in ptype-on-functions.expAndrew Burgess2-1/+6
It was pointed out that the recently added test gdb.fortran/ptype-on-functions.exp fails on older versions of gfortran. This is because the ABI for passing string lengths changed from a 4-byte to 8-byte value (on some targets). This change is documented here: https://gcc.gnu.org/gcc-8/changes.html. Character variables longer than HUGE(0) elements are now possible on 64-bit targets. Note that this changes the procedure call ABI for all procedures with character arguments on 64-bit targets, as the type of the hidden character length argument has changed. The hidden character length argument is now of type INTEGER(C_SIZE_T). This commit just relaxes the pattern to accept any size of integer for the string length argument. gdb/testsuite/ChangeLog: * gdb.fortran/ptype-on-functions.exp: Make the result pattern more generic.
2020-07-15[gdb/testsuite] Handle callq -> call disassembly changeTom de Vries2-2/+5
We're currently running into: ... FAIL: gdb.trace/entry-values.exp: disassemble bar ... Since commit 36938cabf0 "x86: avoid attaching suffixes to unambiguous insns", "callq" is disassembled as "call", and the test-case expects "callq". Fix this by expecting "call" instead. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-15 Tom de Vries <tdevries@suse.de> * gdb.trace/entry-values.exp: Expect "call" instead of "callq" if is_amd64_regs_target.
2020-07-15gdb/fortran: Handle dynamic string types when printing typesAndrew Burgess5-4/+47
After commit: commit 8c2e4e0689ea244d0ed979171a3d09c9176b8175 Date: Sun Jul 12 22:58:51 2020 -0400 gdb: add accessors to struct dynamic_prop An existing bug was exposed in the Fortran type printing code. When GDB is asked to print the type of a function that takes a dynamic string argument GDB will try to read the upper bound of the string. The read of the upper bound is written as: if (type->bounds ()->high.kind () == PROP_UNDEFINED) // Treat the upper bound as unknown. else // Treat the upper bound as known and constant. However, this is not good enough. When printing a function type the dynamic argument types will not have been resolved. As a result the dynamic property is not PROP_UNDEFINED, but nor is it constant. By rewriting this code to specifically check for the PROP_CONST case, and treating all other cases as the upper bound being unknown we avoid incorrectly treating the dynamic property as being constant. gdb/ChangeLog: * f-typeprint.c (f_type_print_base): Allow for dynamic types not being resolved. gdb/testsuite/ChangeLog: * gdb.fortran/ptype-on-functions.exp: Add more tests. * gdb.fortran/ptype-on-functions.f90: Likewise.
2020-07-14gdb/testsuite/lib/dwarf.exp: fix addr_size parameter commentsSimon Marchi2-3/+8
The comments modified in this patch claim that the addr_size parameters can take the value 32 or 64 (suggesting the value is in bits). In fact, the expected value is in bytes, either 4 or 8. The actual value in the DWARF info is in bytes. And we can see that the default values used (if addr_size == "default") are: if {$_cu_addr_size == "default"} { if {[is_64_target]} { set _cu_addr_size 8 } else { set _cu_addr_size 4 } } gdb/testsuite/ChangeLog: * lib/dwarf.exp (Dwarf::cu, Dwarf::tu, Dwarf::lines): Change valid values in documentation for addr_size to 4 and 8. Change-Id: I4a02dca2bb7992198864e545ef099f020f54ff2f
2020-07-14gdb: Improve formatting of 'show endian' messagesAndrew Burgess3-23/+23
This commit changes the output of 'show endian'. Here is a session before this commit: (gdb) show endian The target endianness is set automatically (currently little endian) (gdb) set endian big The target is assumed to be big endian (gdb) show endian The target is assumed to be big endian (gdb) After this commit the session now looks like this: (gdb) show endian The target endianness is set automatically (currently little endian). (gdb) set endian big The target is set to big endian. (gdb) show endian The target is set to big endian. (gdb) The changes are: 1. Each line ends with '.', and 2. After setting the endianness GDB is now a little more assertive; 'target is set to' not 'target is assumed to be', the user did just tell us after all!
2020-07-14gdb: Improve formatting of 'show architecture' messagesAndrew Burgess12-20/+36
This commit changes the output of 'show architecture'. Here is a session before this commit: (gdb) show architecture The target architecture is set automatically (currently i386) (gdb) set architecture mips The target architecture is assumed to be mips (gdb) show architecture The target architecture is assumed to be mips (gdb) After this commit the session now looks like this: (gdb) show architecture The target architecture is set to "auto" (currently "i386"). (gdb) set architecture mips The target architecture is set to "mips". (gdb) show architecture The target architecture is set to "mips". (gdb) The changes are: 1. The value is now enclosed in quotes, 2. Each line ends with '.', and 3. After setting the architecture GDB is now a little more assertive; 'architecture is set to' not 'is assumed to be', the user did just tell us after all! gdb/ChangeLog: * arch-utils.c (show_architecture): Update formatting of messages. gdb/testsuite/ChangeLog: * gdb.arch/amd64-osabi.exp: Update. * gdb.arch/arm-disassembler-options.exp: Update. * gdb.arch/powerpc-disassembler-options.exp: Update. * gdb.arch/ppc64-symtab-cordic.exp: Update. * gdb.arch/s390-disassembler-options.exp: Update. * gdb.base/all-architectures.exp.tcl: Update. * gdb.base/attach-pie-noexec.exp: Update. * gdb.base/catch-syscall.exp: Update. * gdb.xml/tdesc-arch.exp: Update.
2020-07-14[gdb/testsuite] Fix clone-new-thread-event.c with glibc 2.30Tom de Vries2-2/+8
Starting glibc 2.30, unistd.h declares gettid (for _GNU_SOURCE). This clashes with a static gettid in test source clone-new-thread-event.c: ... gdb compile failed, gdb.threads/clone-new-thread-event.c:46:1: error: \ static declaration of 'gettid' follows non-static declaration 46 | gettid (void) | ^~~~~~ In file included from /usr/include/unistd.h:1170, from gdb.threads/clone-new-thread-event.c:27: /usr/include/bits/unistd_ext.h:34:16: note: previous declaration of 'gettid' \ was here 34 | extern __pid_t gettid (void) __THROW; | ^~~~~~ ... Fix this by renaming the static gettid to local_gettid. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-14 Tom de Vries <tdevries@suse.de> * gdb.threads/clone-new-thread-event.c (gettid): Rename to ... (local_gettid): ... this. (fn): Update.
2020-07-13Fix frame-apply.html collision in GDB manual.Paul Carroll2-3/+9
The addition of an anchor for the "frame apply" command was causing the HTML documentation to include files named both "frame-apply.html" and "Frame-Apply.html", which collide on case-insensitive file systems. This patch removes the redundant anchor and adjusts the two xrefs to it. 2020-07-13 Paul Carroll <pcarroll@codesourcery.com> PR gdb/25716 gdb/doc/ * gdb.texinfo (Frame Apply): Remove anchor for 'frame apply' and adjust xrefs to it.
2020-07-13Skip directory tests in gdb.base/info_sources.exp on remote hostSandra Loosemore2-3/+12
When testing on a remote host, source files from build are copied to an arbitrary location on host. Tests that try to pattern-match host pathnames against directory prefixes on build don't generally work. 2020-07-13 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.base/info_sources.exp: Skip directory match tests on remote hosts.
2020-07-13Fix gdb.base/savedregs.exp with clangGary Benson2-1/+6
gdb.base/savedregs.exp fails to run with clang, because of: gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.base/savedregs.c:36:37: warning: operator '<<' has lower precedence than '+'; '+' will be evaluated first [-Wshift-op-parentheses] return callee (a1 << a2 * a3 / a4 + a6 & a6 % a7 - a8) + done; ~~ ~~~~~~~~~~~~~^~~~ /gdbtest/build/gdb/testsuite/gdb.base/savedregs.c:36:37: note: place parentheses around the '+' expression to silence this warning return callee (a1 << a2 * a3 / a4 + a6 & a6 % a7 - a8) + done; ^ ( ) 1 warning generated. This commit fixes it by adding the suggested parentheses. gdb/testsuite/ChangeLog: * gdb.base/savedregs.exp (caller): Use parentheses to make expected expression evaluation ordering explicit.
2020-07-13Fix gdb.arch/i386-sse.exp with clangGary Benson2-1/+5
gdb.arch/i386-sse.exp fails to run with clang, because of: gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.arch/i386-sse.c:56:40: warning: passing 'int *' to parameter of type 'unsigned int *' converts between pointers to integer types with different sign [-Wpointer-sign] if (!x86_cpuid (1, NULL, NULL, NULL, &edx)) ^~~~ /gdbtest/src/gdb/testsuite/../nat/x86-cpuid.h:35:41: note: passing argument to parameter '__edx' here unsigned int *__ecx, unsigned int *__edx) ^ 1 warning generated. Fix it by declaring edx unsigned. gdb/testsuite/ChangeLog: * gdb.arch/i386-sse.c (have_sse) <edx>: Make unsigned.
2020-07-13Use volatile pointers when attempting to trigger SIGSEGVsGary Benson6-5/+14
Clang fails to compile a number of files with the following warning: indirection of non-volatile null pointer will be deleted, not trap [-Wnull-dereference]. This commit qualifies the relevant pointers with 'volatile'. gdb/testsuite/ChangeLog: * gdb.base/bigcore.c (main): Use a volatile pointer when attempting to trigger a SIGSEGV. * gdb.base/gcore-relro-pie.c (break_here): Likewise. * gdb.base/gcore-tls-pie.c (break_here): Likewise. * gdb.base/savedregs.c (thrower): Likewise. * gdb.mi/mi-syn-frame.c (bar): Likewise.
2020-07-13Skip VLA structure field tests when compiling with clangGary Benson5-77/+180
Clang fails to compile gdb.base/vla-datatypes.c with the following error: fields must have a constant size: 'variable length array in structure' extension will never be supported. This commit factors the affected tests out into a new testcase, vla-struct-fields.{exp,c}, which is skipped when the testcase is compiled using clang, gdb/testsuite/ChangeLog: * gdb.base/vla-datatypes.c (vla_factory): Factor out sections defining and using VLA structure fields into... * gdb.base/vla-struct-fields.c: New file. * gdb.base/vla-datatypes.exp: Factor out VLA structure field tests into... * gdb.base/vla-struct-fields.exp: New file.
2020-07-13[gdb/testsuite] Handle missing gold linker in gdb.base/morestack.expTom de Vries5-2/+29
When running test-case gdb.base/morestack.exp without the gold linker installed, we run into: ... Running src/gdb/testsuite/gdb.base/morestack.exp ... gdb compile failed, collect2: fatal error: cannot find 'ld' compilation terminated. FAIL: gdb.base/morestack.exp: continue === gdb Summary === nr of expected passes 1 nr of unexpected failures 1 nr of untested testcases 1 ... The test-case needs the gold linker to run correctly (as explained in commit b8d38ee425 "testsuite: Fix false FAIL for gdb.base/morestack.exp"), but only prefers it, and doesn't require it. Fix this by requiring the gold linker in the test-case. Furthermore, silence the compilation error by introducing a caching proc have_fuse_ld_gold and using it in this and other test-cases that use -fuse-ld=gold. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2020-07-13 Tom de Vries <tdevries@suse.de> * lib/gdb.exp (have_fuse_ld_gold): New caching proc. * gdb.base/gcore-tls-pie.exp: Use have_fuse_ld_gold. * gdb.base/gold-gdb-index.exp: Same. * gdb.base/morestack.exp: Same.
2020-07-12gdb: make type::bounds work for array and string typesSimon Marchi17-44/+69
Getting the bounds of an array (or string) type is a common operation, and is currently done through its index type: my_array_type->index_type ()->bounds () I think it would make sense to let the `type::bounds` methods work for arrays and strings, as a shorthand for this. It's natural that when asking for the bounds of an array, we get the bounds of the range type used as its index type. In a way, it's equivalent as the now-removed TYPE_ARRAY_{LOWER,UPPER}_BOUND_IS_UNDEFINED and TYPE_ARRAY_{LOWER,UPPER}_BOUND_VALUE, except it returns the `range_bounds` object. The caller is then responsible for getting the property it needs in it. I updated all the spots I could find that could take advantage of this. Note that this also makes `type::bit_stride` work on array types, since `type::bit_stride` uses `type::bounds`. `my_array_type->bit_stride ()` now returns the bit stride of the array's index type. So some spots are also changed to take advantage of this. gdb/ChangeLog: * gdbtypes.h (struct type) <bounds>: Handle array and string types. * ada-lang.c (assign_aggregate): Use type::bounds on array/string type. * c-typeprint.c (c_type_print_varspec_suffix): Likewise. * c-varobj.c (c_number_of_children): Likewise. (c_describe_child): Likewise. * eval.c (evaluate_subexp_for_sizeof): Likewise. * f-typeprint.c (f_type_print_varspec_suffix): Likewise. (f_type_print_base): Likewise. * f-valprint.c (f77_array_offset_tbl): Likewise. (f77_get_upperbound): Likewise. (f77_print_array_1): Likewise. * guile/scm-type.c (gdbscm_type_range): Likewise. * m2-typeprint.c (m2_array): Likewise. (m2_is_long_set_of_type): Likewise. * m2-valprint.c (get_long_set_bounds): Likewise. * p-typeprint.c (pascal_type_print_varspec_prefix): Likewise. * python/py-type.c (typy_range): Likewise. * rust-lang.c (rust_internal_print_type): Likewise. * type-stack.c (type_stack::follow_types): Likewise. * valarith.c (value_subscripted_rvalue): Likewise. * valops.c (value_cast): Likewise. Change-Id: I5c0c08930bffe42fd69cb4bfcece28944dd88d1f
generated by cgit v1.1 at 2024-11-19 01:16:43 +0000