aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-11-17PR26882, --enable-textrel-check=warning test failures on powerpcAlan Modra8-9/+24
PR 26882 * testsuite/ld-powerpc/dotsym3.d: Add "-z notext" to ld options. * testsuite/ld-powerpc/dotsym4.d: Likewise. * testsuite/ld-powerpc/ppc476-shared.d: Likewise. * testsuite/ld-powerpc/ppc476-shared2.d: Likewise. * testsuite/ld-powerpc/powerpc.exp: Likewise for various tests. * testsuite/ld-undefined/weak-fundef.s: Add BLPLT variant. * testsuite/ld-undefined/weak-undef.exp: Define BLPLT for ppc32.
2020-11-17gdb/arc: fix print_one_insn selftestAndrew Burgess4-5/+15
I noticed that the ARC print_one_insn selftest was failing. The problem is that in print_one_insn_test the arc case falls through into the special case that handles nios2, score, and riscv. The special case for these targets hard codes the breakpoint kind to '4'. This is find for bare metal arc (see arc-tdep.c, arc_sw_breakpoint_from_kind), however, for arc/linux only breakpoint kind '2' is supported (see arc-linux-tdep.c, arc_linux_sw_breakpoint_from_kind). So the code in print_one_insn_test as it is currently written passed in an invalid breakpoint kind, this leads to GDB trying to disassemble unexpected memory. The fix is to reorder the code in print_one_insn_test so that the arc case falls through into the default case. In the default we no longer hard code the breakpoint kind, and everything should be good. Additionally, given the arc code only expects specific breakpoint kind values, I thought it would be nice to add some gdb_assert to validate things. This assert would have triggered in this case and made it easier to find the error. After this commit, configure GDB with --enable-targets=all, then run gdb.gdb/unittest.exp, there should no longer be any failures. gdb/ChangeLog: * arc-linux-tdep.c (arc_linux_sw_breakpoint_from_kind): Add an assert. * arc-tdep.c (arc_breakpoint_kind_from_pc): Likewise. * disasm-selftests.c (print_one_insn_test): Fall throough from ARC case to the default.
2020-11-17gdb/testsuite: prevent timeout in gdb.gdb/unittest.expAndrew Burgess2-0/+11
When GDB is compiled with --enable-targets=all I would sometimes see the 'maintenance selftest' in gdb.gdb/unittest.exp test timeout. This one command causes GDB to run many separate self tests, this can take some time. The output of this command basically follows this pattern: (gdb) maintenance selftest Running selftest aarch64-analyze-prologue. Running selftest aarch64-process-record. Running selftest arm-record. Running selftest arm_analyze_prologue. Running selftest array_view. Running selftest child_path. Running selftest cli_utils. ..... snip lots more lines .... Ran 79 unit tests, 0 failed Currently the expect script waits for the final summary line ("Ran 79 unit test, 0 failed") before declaring pass or fail. The problem is that if the summary line takes too long to appear the test will timeout. As this test makes use of gdb_test_multiple then all I've done is add an extra pattern that matches the 'Running selftest ....' lines and then calls exp_continue. Doing this means we find matches much more frequently, and each time we do the timeout timer resets, preventing the overall test from timing out. gdb/testsuite/ChangeLog: * gdb.gdb/unittest.exp: Spot 'Running...' lines.
2020-11-17gdb: improve command completion for 'print', 'x', and 'display'Andrew Burgess4-2/+121
The /FMT specification on the print command currently breaks command completion, so: (gdb) p var.<TAB><TAB> .... list of fields in var ..... But, (gdb) p/d var.<TAB><TAB> ..... list of all symbols ..... After this commit this issue is now resolved. There are some other details around tab-completion and /FMT which hopefully this commit improves. So, before: (gdb) p/<TAB><TAB> .... lists all symbols ..... After: (gdb) p/<TAB><TAB> # Nothing changes... The thinking here is that after a / the user must type a FMT, but we don't offer tab completion on FMT characters. Placing a symbol directly after a / will not do what the user expects, so offering that seems wrong. Similarly, before we had: (gdb) p/d<TAB><TAB> ... lists all symbols starting with 'd' .... But afterwards: (gdb) p/d<TAB><TAB> # Adds a single space, so we get: (gdb) p/d <CURSOR> As before, typing a symbol where FMT is expected will not do what the user expects. If the user has added a FMT string then upon tab completion GDB assumes the FMT string is complete and prepares the user to type an expression. In this commit I have also added completion functions for the 'x' and 'display' commands. These commands also support /FMT specifiers and so share some code with 'print'. gdb/ChangeLog: * printcmd.c: Include 'safe-ctype.c'. (skip_over_slash_fmt): New function. (print_command_completer): Call skip_over_slash_fmt. (display_and_x_command_completer): New function. (_initialize_printcmd): Add command completion for 'x' and 'display'. gdb/testsuite/ChangeLog: * gdb.base/completion.exp: Add new tests.
2020-11-17Automatic date update in version.inGDB Administrator1-1/+1
2020-11-16aarch64: Add +pauth flag for Pointer Authentication featurePrzemyslaw Wirkus6-1/+169
New -march option +pauth enables PAuth vel PAC (Pointer Authentication) feature.
2020-11-16aarch64: Extract Condition flag manipulation feature from Armv8.4-APrzemyslaw Wirkus10-6/+76
Extract FLAGM (Condition flag manipulation) feature from Armv8.4-A. Please note that FLAGM stays a Armv8.4-A feature but now can be assigned to other architectures or CPUs. New -march option +flagm is added to enable independently this feature.
2020-11-16arm: Add support for Cortex-A78CPrzemyslaw Wirkus6-0/+21
This patch adds support for -mcpu=cortex-a78c command line option. For more information about this processor, see [0]: [0] https://developer.arm.com/ip-products/processors/cortex-a/cortex-a78c
2020-11-16Update gdb.dwarf2/data-loc.expTom Tromey2-43/+11
Tom de Vries pointed out that the series to handle -fgnat-encodings=minimal regressed data-loc.exp: https://sourceware.org/pipermail/gdb-patches/2020-November/173035.html This was my oversight. Looking at the test, it mimics what GNAT emits. The patch series in question changed the approach that gdb takes to such arrays -- now they are transformed back into "old" style structures. (This is perhaps a step backward in a semantics sense, but on the other hand it more accurately reflects the underlying reality, and lets gdb continue to create objects of this type.) This patch updates the test case, by adjusting the expected output. It also removes the tests done in the C language, because they are now incorrect, and because (IMO) they don't add much value. gdb/testsuite/ChangeLog 2020-11-16 Tom Tromey <tromey@adacore.com> * gdb.dwarf2/data-loc.exp: Update expected output. Remove C tests.
2020-11-16Fix frame cycle detectionPedro Alves3-11/+26
The recent commit to make scoped_restore_current_thread's cdtors exception free regressed gdb.base/eh_return.exp: Breakpoint 1, 0x00000000004012bb in eh2 (gdb/frame.c:641: internal-error: frame_id get_frame_id(frame_info*): Assertion `stashed' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.base/eh_return.exp: hit breakpoint (GDB internal error) That testcase uses __builtin_eh_return and, before the regression, the backtrace at eh2 looked like this: (gdb) bt #0 0x00000000004006eb in eh2 (p=0x4006ec <continuation>) at src/gdb/testsuite/gdb.base/eh_return.c:54 Backtrace stopped: previous frame identical to this frame (corrupt stack?) That "previous frame identical to this frame" is caught by the cycle detection based on frame id. The assertion failing is this one: 638 /* Since this is the first frame in the chain, this should 639 always succeed. */ 640 bool stashed = frame_stash_add (fi); 641 gdb_assert (stashed); originally added by commit f245535cf583ae4ca13b10d47b3c7d3334593ece Author: Pedro Alves <palves@redhat.com> AuthorDate: Mon Sep 5 18:41:38 2016 +0100 Fix PR19927: Avoid unwinder recursion if sniffer uses calls parse_and_eval The assertion is failing because frame #1's frame id was stashed before the id of frame #0 is stashed. The frame id of frame #1 was stashed here: (top-gdb) bt #0 frame_stash_add (frame=0x1e24c90) at src/gdb/frame.c:276 #1 0x0000000000669c1b in get_prev_frame_if_no_cycle (this_frame=0x19f8370) at src/gdb/frame.c:2120 #2 0x000000000066a339 in get_prev_frame_always_1 (this_frame=0x19f8370) at src/gdb/frame.c:2303 #3 0x000000000066a360 in get_prev_frame_always (this_frame=0x19f8370) at src/gdb/frame.c:2319 #4 0x000000000066b56c in get_frame_unwind_stop_reason (frame=0x19f8370) at src/gdb/frame.c:3028 #5 0x000000000059f929 in dwarf2_frame_cfa (this_frame=0x19f8370) at src/gdb/dwarf2/frame.c:1462 #6 0x00000000005ce434 in dwarf_evaluate_loc_desc::get_frame_cfa (this=0x7fffffffc070) at src/gdb/dwarf2/loc.c:666 #7 0x00000000005989a9 in dwarf_expr_context::execute_stack_op (this=0x7fffffffc070, op_ptr=0x1b2a053 "\364\003", op_end=0x1b2a053 "\364\003") at src/gdb/dwarf2/expr.c:1161 #8 0x0000000000596af6 in dwarf_expr_context::eval (this=0x7fffffffc070, addr=0x1b2a052 "\234\364\003", len=1) at src/gdb/dwarf2/expr.c:303 #9 0x0000000000597b4e in dwarf_expr_context::execute_stack_op (this=0x7fffffffc070, op_ptr=0x1b2a063 "", op_end=0x1b2a063 "") at src/gdb/dwarf2/expr.c:865 #10 0x0000000000596af6 in dwarf_expr_context::eval (this=0x7fffffffc070, addr=0x1b2a061 "\221X", len=2) at src/gdb/dwarf2/expr.c:303 #11 0x00000000005c8b5a in dwarf2_evaluate_loc_desc_full (type=0x1b564d0, frame=0x19f8370, data=0x1b2a061 "\221X", size=2, per_cu=0x1b28760, per_objfile=0x1a84930, subobj_type=0x1b564d0, subobj_byte_offset=0) at src/gdb/dwarf2/loc.c:2260 #12 0x00000000005c9243 in dwarf2_evaluate_loc_desc (type=0x1b564d0, frame=0x19f8370, data=0x1b2a061 "\221X", size=2, per_cu=0x1b28760, per_objfile=0x1a84930) at src/gdb/dwarf2/loc.c:2444 #13 0x00000000005cb769 in locexpr_read_variable (symbol=0x1b59840, frame=0x19f8370) at src/gdb/dwarf2/loc.c:3687 #14 0x0000000000663137 in language_defn::read_var_value (this=0x122ea60 <c_language_defn>, var=0x1b59840, var_block=0x0, frame=0x19f8370) at src/gdb/findvar.c:618 #15 0x0000000000663c3b in read_var_value (var=0x1b59840, var_block=0x0, frame=0x19f8370) at src/gdb/findvar.c:822 #16 0x00000000008c7d9f in read_frame_arg (fp_opts=..., sym=0x1b59840, frame=0x19f8370, argp=0x7fffffffc470, entryargp=0x7fffffffc490) at src/gdb/stack.c:542 #17 0x00000000008c89cd in print_frame_args (fp_opts=..., func=0x1b597c0, frame=0x19f8370, num=-1, stream=0x1aba860) at src/gdb/stack.c:890 #18 0x00000000008c9bf8 in print_frame (fp_opts=..., frame=0x19f8370, print_level=0, print_what=SRC_AND_LOC, print_args=1, sal=...) at src/gdb/stack.c:1394 #19 0x00000000008c92b9 in print_frame_info (fp_opts=..., frame=0x19f8370, print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at src/gdb/stack.c:1119 #20 0x00000000008c75f0 in print_stack_frame (frame=0x19f8370, print_level=0, print_what=SRC_AND_LOC, set_current_sal=1) at src/gdb/stack.c:366 #21 0x000000000070250b in print_stop_location (ws=0x7fffffffc9e0) at src/gdb/infrun.c:8110 #22 0x0000000000702569 in print_stop_event (uiout=0x1a8b9e0, displays=true) at src/gdb/infrun.c:8126 #23 0x000000000096d04b in tui_on_normal_stop (bs=0x1bcd1c0, print_frame=1) at src/gdb/tui/tui-interp.c:98 ... Before the commit to make scoped_restore_current_thread's cdtors exception free, scoped_restore_current_thread's dtor would call get_frame_id on the selected frame, and we use scoped_restore_current_thread pervasively. That had the side effect of stashing the frame id of frame #0 before reaching the path shown in the backtrace. I.e., the frame id of frame #0 happened to be stashed before the frame id of frame #1. But that was by chance, not by design. This commit: commit 256ae5dbc73d1348850f86ee77a0dc3b04bc7cc0 Author: Kevin Buettner <kevinb@redhat.com> AuthorDate: Mon Oct 31 12:47:42 2016 -0700 Stash frame id of current frame before stashing frame id for previous frame Fixed a similar problem, by making sure get_prev_frame computes the frame id of the current frame before unwinding the previous frame, so that the cycle detection works properly. That fix misses the scenario we're now running against, because if you notice, the backtrace above shows that frame #4 calls get_prev_frame_always, not get_prev_frame. I.e., nothing is calling get_frame_id on the current frame. The fix here is to move Kevin's fix down from get_prev_frame to get_prev_frame_always. Or actually, a bit further down to get_prev_frame_always_1 -- note that inline_frame_this_id calls get_prev_frame_always, so we need to be careful to avoid recursion in that scenario. gdb/ChangeLog: * frame.c (get_prev_frame): Move get_frame_id call from here ... (get_prev_frame_always_1): ... to here. * inline-frame.c (inline_frame_this_id): Mention get_prev_frame_always_1 in comment. Change-Id: Id960c98ab2d072c48a436c3eb160cc4b2a5cfd1d
2020-11-16Update the Spanish translation for the ld/ subdirectory.Nick Clifton2-1781/+2031
* po/es.po: Updated Spanish translation.
2020-11-16ld: Fix the tls_ie-01 test for arcShahab Vahedi2-4/+11
The purpose of the test is to look for entries of "foo" and "bar" in the ".got". The old "objdump -s ..." has been replaced with "objdump -D ..." to inspect the final executable. A sample output looks like: ------------------------8<------------------------ $ arc-elf32-objdump -D -j .got tls_ie-01 tls_ie-01: file format elf32-littlearc Disassembly of section .got: 00002110 <_GLOBAL_OFFSET_TABLE_>: ... 211c: 08 00 00 00 .word 0x00000008 2120: 0c 00 00 00 .word 0x0000000c ------------------------>8------------------------ ld/ * testsuite/ld-arc/tls_ie-01.d: Update the dump command.
2020-11-16Automatic date update in version.inGDB Administrator1-1/+1
2020-11-15Add support for fixed-point type comparison operatorsJoel Brobecker6-2/+137
This patch adds support for binary comparison operators with fixed-point type values. gdb/ChangeLog: * valarith.c (fixed_point_binop): Add BINOP_EQUAL and BINOP_LESS handling. (value_less): Add fixed-point handling. gdb/testsuite/ChangeLog: * gdb.ada/fixed_cmp.exp: Add -fgnat-encodings=minimal testing. * gdb.dwarf2/dw2-fixed-point.c (pck__fp1_var2): New global. (main): Add reference to pck__fp1_var2. * gdb.dwarf2/dw2-fixed-point.exp: Add comparison operator testing.
2020-11-15Add support for fixed-point type arithmeticJoel Brobecker6-3/+196
This patch adds support for binary operations on fixed-point values, as well as for the negative unary operator. gdb/ChangeLog: * eval.c (binop_promote): Add fixed-point type handling. * valarith.c (fixed_point_binop): New function. (scalar_binop): Add fixed-point type handling. (value_neg): Add fixed-point type handling. * valops.c (value_cast_to_fixed_point): New function. (value_cast): Add fixed-point type handling. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-fixed-point.exp: Add arithmetic tests.
2020-11-15Add ptype support for DWARF-based fixed-point typesJoel Brobecker9-0/+128
Note that the ptype information printed for types described via pure DWARF debug info is slightly less informative as the one printed when the information is encoded in the type's name, via the GNAT encoding. As a result, the output in the case of DWARF-described fixed point types is slightly different. In pratice, this is no real loss because the information not available in DWARF has no bearing on how the type is actually stored in memory. gdb/ChangeLog: * ada-typeprint.c (ada_print_type): Add handing of fixed-point range types. * c-typeprint.c (c_type_print_varspec_prefix) (c_type_print_varspec_suffix, c_type_print_base_1): Add TYPE_CODE_FIXED_POINT handling. * p-typeprint.c (pascal_type_print_varspec_prefix) (pascal_type_print_varspec_suffix): Likewise. * typeprint.c (print_type_fixed_point): New function. * typeprint.h (print_type_fixed_point): Add declaration. gdb/testsuite/ChangeLog: * gdb.ada/fixed_points.exp: Add ptype tests. * gdb.dwarf2/dw2-fixed-point.exp: Likewise.
2020-11-15fix printing of DWARF fixed-point type objects with format modifierJoel Brobecker4-1/+23
Consider a fixed-point type such the scaling factor is 1/16, as the following Ada code snippet would create: type FP1_Type is delta 0.1 range -1.0 .. +1.0; FP1_Var : FP1_Type := 0.25; Printing the value of this variable with a format modifier yields the wrong value. E.g.: (gdb) p /x fp1_var $6 = 0x4 Since the real value is 0.25, we therefore expected... (gdb) p /x fp1_var $6 = 0x0 What happens, in this case, is that the value being printed is actually the "raw" value of our object, before the scaling factor gets applied. This commit fixes the issue by using approach as for float values, where we convert the value into an integer value, prior to printing, knowing that the conversion takes the scaling factor into account. gdb/ChangeLog: * printcmd.c (print_scalar_formatted): Add fixed-point type handling when options->format is set. gdb/testsuite/ChangeLog: * gdb.dwarf2/dw2-fixed-point.exp: Add "print /x" tests.
2020-11-15Add support for printing value of DWARF-based fixed-point type objectsJoel Brobecker16-18/+760
This commit introduces a new kind of type, meant to describe fixed-point types, using a new code added specifically for this purpose (TYPE_CODE_FIXED_POINT). It then adds handling of fixed-point base types in the DWARF reader. And finally, as a first step, this commit adds support for printing the value of fixed-point type objects. Note that this commit has a known issue: Trying to print the value of a fixed-point object with a format letter (e.g. "print /x NAME") causes the wrong value to be printed because the scaling factor is not applied. Since the fix for this issue is isolated, and this is not a regression, the fix will be made in a pach of its own. This is meant to simplify review and archeology. Also, other functionalities related to fixed-point type handling (ptype, arithmetics, etc), will be added piecemeal as well, for the same reasons (faciliate reviews and archeology). Related to this, the testcase gdb.ada/fixed_cmp.exp is adjusted to compile the test program with -fgnat-encodings=all, so as to force the use of GNAT encodings, rather than rely on the compiler's default to use them. The intent is to enhance this testcase to also test the pure DWARF approach using -fgnat-encodings=minimal as soon as the corresponding suport gets added in. Thus, the modification to the testcase is made in a way that it prepares this testcase to be tested in both modes. gdb/ChangeLog: * ada-valprint.c (ada_value_print_1): Add fixed-point type handling. * dwarf2/read.c (get_dwarf2_rational_constant) (get_dwarf2_unsigned_rational_constant, finish_fixed_point_type) (has_zero_over_zero_small_attribute): New functions. read_base_type, set_die_type): Add fixed-point type handling. * gdb-gdb.py.in: Add fixed-point type handling. * gdbtypes.c: #include "gmp-utils.h". (create_range_type, set_type_code): Add fixed-point type handling. (init_fixed_point_type): New function. (is_integral_type, is_scalar_type): Add fixed-point type handling. (print_fixed_point_type_info): New function. (recursive_dump_type, copy_type_recursive): Add fixed-point type handling. (fixed_point_type_storage): New typedef. (fixed_point_objfile_key): New static global. (allocate_fixed_point_type_info, is_fixed_point_type): New functions. (fixed_point_type_base_type, fixed_point_scaling_factor): New functions. * gdbtypes.h: #include "gmp-utils.h". (enum type_code) <TYPE_SPECIFIC_FIXED_POINT>: New enum. (union type_specific) <fixed_point_info>: New field. (struct fixed_point_type_info): New struct. (INIT_FIXED_POINT_SPECIFIC, TYPE_FIXED_POINT_INFO): New macros. (init_fixed_point_type, is_fixed_point_type) (fixed_point_type_base_type, fixed_point_scaling_factor) (allocate_fixed_point_type_info): Add declarations. * valprint.c (generic_val_print_fixed_point): New function. (generic_value_print): Add fixed-point type handling. * value.c (value_as_address, unpack_long): Add fixed-point type handling. gdb/testsuite/ChangeLog: * gdb.ada/fixed_cmp.exp: Force compilation to use -fgnat-encodings=all. * gdb.ada/fixed_points.exp: Add fixed-point variables printing tests. * gdb.ada/fixed_points/pck.ads, gdb.ada/fixed_points/pck.adb: New files. * gdb.ada/fixed_points/fixed_points.adb: Add use of package Pck. * gdb.dwarf2/dw2-fixed-point.c, gdb.dwarf2/dw2-fixed-point.exp: New files.
2020-11-15Move uinteger_pow gdb/valarith.c to gdb/utils.c and make it publicJoel Brobecker4-31/+43
This is a generic function which I would like to use in a followup patch adding support for fixed-point types. So this commit moves it out of valarith.c into util.c, and makes it non-static. gdb/ChangeLog: * utils.h (uinteger_pow): Add declaration. * utils.c (uinteger_pow): Moved here (without changes)... * valarith.c (uinteger_pow): ... from here.
2020-11-15gmp-utils: New API to simply use of GMP's integer/rational/float objectsJoel Brobecker5-0/+926
This API was motivated by a number of reasons: - GMP's API does not handle "long long" and "unsigned long long", so using LONGEST and ULONGEST is not straightforward; - Automate the need to initialize GMP objects before use, and clear them when no longer used. However, this API grew also to help with similar matter such as formatting to a string, and also reading/writing fixed-point values from byte buffers. Dedicated unit testing is also added. gdb/ChangeLog: * gmp-utils.h, gmp-utils.h: New file. * unittests/gmp-utils-selftests.c: New file. * Makefile.in (SUBDIR_UNITTESTS_SRCS): Add unittests/gmp-utils-selftests.c. (COMMON_SFILES) Add gmp-utils.c. (HFILES_NO_SRCDIR): Add gmp-utils.h.
2020-11-15gdb: Make GMP a required dependency for building GDBJoel Brobecker3-0/+12
This commit modifies gdb's configure script to trigger an error if we cannot find a usable libgmp. For the record, making this a requirement was discussed in March 2018: https://sourceware.org/pipermail/gdb-patches/2018-March/147373.html gdb/ChangeLog: * configure.ac: Generate an error if a usable GMP library could not be found. * configure: Regenerate.
2020-11-15gdb/configure: Add --with-libgmp-prefix optionJoel Brobecker5-1/+507
This patch allows a user to tell gdb's configure script where his GMP library is installed. gdb/ChangeLog: * configure.ac: Add support for --with-libgmp-prefix. * Makefile.in (LIBGMP): New variable. (CLIBS): Include $(LIBGMP). * configure, config.in: Regenerate
2020-11-15Automatic date update in version.inGDB Administrator1-1/+1
2020-11-14gdb: add tab completion of type field names for FortranAndrew Burgess5-4/+135
Add support for tab-completion on Fortran field names. Consider this test case: program test type my_type integer :: field_a integer :: other_field integer :: last_field end type my_type type(my_type) :: var print *, var end program test And the GDB session before this patch: (gdb) start ... (gdb) p var% <- Trigger TAB completion here. Display all 200 possibilities? (y or n) n (gdb) p var% And the GDB session with this patch: (gdb) start ... (gdb) p var% <- Trigger TAB completion here. field_a last_field other_field (gdb) p var% The implementation for this is basically copied from c-exp.y, I tweaked the parser patterns to be appropriate for Fortran, and it "just worked". gdb/ChangeLog: PR cli/26879 * f-exp.y (COMPLETE): New token. (exp): Two new rules for tab-completion. (saw_name_at_eof): New static global. (last_was_structop): Likewise. (yylex): Set new variables, and return COMPLETE token at the end of the input stream in some cases. gdb/testsuite/ChangeLog: PR cli/26879 * gdb.fortran/completion.exp: New file. * gdb.fortran/completion.f90: New file.
2020-11-14Use "bool" in fetch_inferior_eventTom Tromey2-1/+5
A while back I noticed that fetch_inferior_event used "int" for should_stop, whereas it can be bool. The method it is assigned from: should_stop = thread_fsm->should_stop (thr); ... already returns bool. Tested by rebuilding. gdb/ChangeLog 2020-11-14 Tom Tromey <tom@tromey.com> * infrun.c (fetch_inferior_event): Use "bool" for should_stop.
2020-11-14Add use of const in opencl-lang.cTom Tromey2-2/+6
I found another expression-related spot that could use constification. This patch adds it. Tested by rebuilding. gdb/ChangeLog 2020-11-14 Tom Tromey <tom@tromey.com> * opencl-lang.c (opencl_component_ref): Make "comps" const.
2020-11-14gdb: fix comment in arm-tdep.cSimon Marchi2-2/+5
gdb/ChangeLog: * arm-tdep.c (class arm_instruction_reader) <read>: Fix comment. Change-Id: I8f5355b314e8db643b645a6281042f514b46a908
2020-11-14x86: Ignore CS/DS/ES/SS segment-override prefixes in 64-bit modeBorislav Petkov43-401/+467
"In 64-bit mode, the CS, DS, ES, and SS segment-override prefixes have no effect. These four prefixes are not treated as segment-override prefixes for the purposes of multiple-prefix rules. Instead, they are treated as null prefixes." (AMD APM v2). However, objdump disassembles instructions containing those ignored prefixes by still generating that segment override: 66 66 2e 0f 1f 84 00 data16 nopw %cs:0x0(%rax,%rax,1) 00 00 00 00 Print those segment override prefixes as excessive ones: 66 66 2e 0f 1f 84 00 data16 cs nopw 0x0(%rax,%rax,1) 00 00 00 00 which is what they actually are - they have no effect and the decoding hardware ignores them. gas/ 2020-11-14 Borislav Petkov <bp@suse.de> * testsuite/gas/i386/x86-64-segovr.d: Adjust regexes. * testsuite/gas/i386/x86-64-nops.d: Likewise. * testsuite/gas/i386/x86-64-nops-1.d: Likewise. * testsuite/gas/i386/x86-64-nops-1-g64.d: Likewise. * testsuite/gas/i386/x86-64-nops-1-core2.d: Likewise. * testsuite/gas/i386/x86-64-nops-1-k8.d: Likewise. * testsuite/gas/i386/x86-64-nops-2.d: Likewise. * testsuite/gas/i386/x86-64-nops-3.d: Likewise. * testsuite/gas/i386/x86-64-nops-4.d: Likewise. * testsuite/gas/i386/x86-64-nops-4-core2.d: Likewise. * testsuite/gas/i386/x86-64-nops-4-k8.d: Likewise. * testsuite/gas/i386/x86-64-nops-5.d: Likewise. * testsuite/gas/i386/x86-64-nops-5-k8.d: Likewise. * testsuite/gas/i386/x86-64-nops-7.d: Likewise. * testsuite/gas/i386/x86-64-nop-1.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-1a.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-1b.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-1c.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-1d.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-1g.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-2c.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-6.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-7.d: Likewise. * testsuite/gas/i386/x86-64-align-branch-8.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-1-core2.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-1-k8.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-1.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-2.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-3.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-4-core2.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-4-k8.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-4.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-5-k8.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops-5.d: Likewise. * testsuite/gas/i386/ilp32/x86-64-nops.d:: Likewise. ld/ 2020-11-14 Borislav Petkov <bp@suse.de> * testsuite/ld-x86-64/pe-x86-64-4.od: Adjust regexes. * testsuite/ld-x86-64/tlsld3.dd: Likewise. * testsuite/ld-x86-64/tlsld4.dd: Likewise. opcodes/ 2020-11-14 Borislav Petkov <bp@suse.de> * i386-dis.c (ckprefix): Do not assign active_seg_prefix in 64-bit addressing mode. (NOTRACK_Fixup): Test prefixes for PREFIX_DS, instead of active_seg_prefix.
2020-11-13Use const more in c-lang.cTom Tromey2-14/+19
This changes a few functions in c-lang.c to add "const" to parameters and return types. Tested by rebuilding. gdb/ChangeLog 2020-11-13 Tom Tromey <tom@tromey.com> * c-lang.c (convert_ucn, convert_octal, convert_hex) (convert_escape, parse_one_string): Constify.
2020-11-14Automatic date update in version.inGDB Administrator1-1/+1
2020-11-13elf: Set rel_from_abs to 1 for __ehdr_startH.J. Lu5-0/+29
bfdlink.h has /* Symbol will be converted from absolute to section-relative. Set for symbols defined by a script from "dot" (also SEGMENT_START or ORIGIN) outside of an output section statement. */ unsigned int rel_from_abs : 1; linker.c has .{* Return TRUE if the symbol described by a linker hash entry H . is going to be absolute. Linker-script defined symbols can be . converted from absolute to section-relative ones late in the . link. Use this macro to correctly determine whether the symbol . will actually end up absolute in output. *} .#define bfd_is_abs_symbol(H) \ . (((H)->type == bfd_link_hash_defined \ . || (H)->type == bfd_link_hash_defweak) \ . && bfd_is_abs_section ((H)->u.def.section) \ . && !(H)->rel_from_abs) . Set rel_from_abs to 1 for __ehdr_start which will be converted from absolute to section-relative in assign_file_positions_for_load_sections. PR ld/26869 * ldelf.c (ldelf_before_allocation): Set rel_from_abs to 1 for __ehdr_start. * testsuite/ld-i386/i386.exp: Run pr26869. * testsuite/ld-i386/pr26869.d: New file. * testsuite/ld-i386/pr26869.s: Likewise.
2020-11-13Exclude debuginfo files from "outside of ELF segments" warningKeith Seitz2-1/+12
When GDB loads an ELF file, it will warn when a section is not located in an ELF segment: $ ./gdb -q -iex "set build-id-verbose 0" --ex "b systemctl_main" -ex "r" -batch --args systemctl kexec Breakpoint 1 at 0xc24d: file ../src/systemctl/systemctl.c, line 8752. warning: Loadable section ".note.gnu.property" outside of ELF segments in .gnu_debugdata for /lib64/libgcc_s.so.1 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". warning: Loadable section ".note.gnu.property" outside of ELF segments in .gnu_debugdata for /lib64/libcap.so.2 warning: Loadable section ".note.gnu.property" outside of ELF segments in .gnu_debugdata for /lib64/libacl.so.1 warning: Loadable section ".note.gnu.property" outside of ELF segments in .gnu_debugdata for /lib64/libcryptsetup.so.12 warning: Loadable section ".note.gnu.property" outside of ELF segments in .gnu_debugdata for /lib64/libgcrypt.so.20 warning: Loadable section ".note.gnu.property" outside of ELF segments in .gnu_debugdata for /lib64/libip4tc.so.2 [snip] This has feature has also been reported by various users, most notably the Fedora-EOL'd bug 1553086. Mark Wielaard explains the issue quite nicely in https://sourceware.org/bugzilla/show_bug.cgi?id=24717#c2 The short of it is, the ELF program headers for debuginfo files are not suited to this particular use case. Consequently, the warning generated above really is useless and should be ignored. This patch follows the same heuristic that BFD itself uses. gdb/ChangeLog 2020-11-13 Keith Seitz <keiths@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1553086 * elfread.c (elf_symfile_segments): Omit "Loadable section ... outside of ELF segments" warning for debugin
2020-11-13Add file name to "Loadable section ... outside of ELF segments" warningKeith Seitz2-2/+8
As requested in gdb/23034, I would like to extend the warning message GDB displays when it detects a loadable section that is outside any ELF segment. Before: $ gdb -q --ex "b systemctl_main" -ex "r" -batch --args systemctl kexec Breakpoint 1 at 0xc24d: file ../src/systemctl/systemctl.c, line 8752. warning: Loadable section ".note.gnu.property" outside of ELF segments [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments warning: Loadable section ".note.gnu.property" outside of ELF segments [snip] Breakpoint 1, systemctl_main (argv=0x7fffffffd348, argc=2) at ../src/systemctl/systemctl.c:8752 8752 r = systemctl_main(argc, argv); After: warning: Loadable section ".note.gnu.property" outside of ELF segments in .gnu_debugdata for /lib64/libcap.so.2 warning: Loadable section ".note.gnu.property" outside of ELF segments in .gnu_debugdata for /lib64/libacl.so.1 [snip] I think this is eminently more useful output. gdb/ChangeLog 2020-11-13 Keith Seitz <keiths@redhat.com> PR gdb/23034 * elfread.c (elf_symfile_segments): Output a BFD file name for the "Loadable section ... outside of ELF segments" warning.
2020-11-13gdb/arm: avoid undefined behavior shift when decoding immediate valueSimon Marchi2-23/+133
When loading the code file provided in PR 26828 and GDB is build with UBSan, we get: Core was generated by `./Foo'. Program terminated with signal SIGABRT, Aborted. #0 0xb6c3809c in pthread_cond_wait () from /home/simark/build/binutils-gdb/gdb/repo/lib/libpthread.so.0 [Current thread is 1 (LWP 29367)] (gdb) bt /home/simark/src/binutils-gdb/gdb/arm-tdep.c:1551:30: runtime error: shift exponent 32 is too large for 32-bit type 'unsigned int' The sequence of instructions at pthread_cond_wait, in the libpthread.so.0 library, contains this instruction with an immediate constant with a "rotate amount" of 0: e24dd044 sub sp, sp, #68 ; 0x44 Since arm_analyze_prologue shifts by "32 - rotate amount", it does a 32 bit shift of a 32 bit type, which is caught by UBSan. Fix it by factoring out the decoding of immediates in a new function, arm_expand_immediate. I added a selftest for arm_analyze_prologue that replicates the instruction sequence. Without the fix, it crashes GDB if it is build with --enable-ubsan. I initially wanted to re-use the abstract_memory_reader class already in arm-tdep.c, used to make arm_process_record testable. However, arm_process_record and arm_analyze_prologue don't use the same kind of memory reading functions. arm_process_record uses a function that returns an error status on failure while arm_analyze_prologue uses one that throws an exception. Since i didn't want to introduce any other behavior change, I decided to just introduce a separate interface (arm_instruction_reader). It is derived from abstract_instruction_reader in aarch64-tdep.c. gdb/ChangeLog: PR gdb/26835 * arm-tdep.c (class arm_instruction_reader): New. (target_arm_instruction_reader): New. (arm_analyze_prologue): Add instruction reader parameter and use it. Use arm_expand_immediate. (class target_arm_instruction_reader): Adjust. (arm_skip_prologue): Adjust. (arm_expand_immediate): New. (arm_scan_prologue): Adjust. (arm_analyze_prologue_test): New. (class test_arm_instruction_reader): New. Change-Id: Ieb1c1799bd66f8c7421384f44f5c2777b578ff8d
2020-11-13Fix Windows-target testing in gdb_file_cmdJoseph Myers2-0/+10
GCC for Windows target produces executables called foo.exe when given "-o foo". (More specifically, it's done that for native compilers for a long time, and for cross compilers to Windows target since GCC commit 5bc86b599054f494ec0a45e49b82749320eaa9c4, in GCC 8 and later.) This causes problems for many GDB tests expecting a program to have the exact file name passed to -o. Fix this by checking for the case where only the .exe exists in gdb_file_cmd and adjusting the name passed to the file command accordingly. There may well be other places with this issue in the GDB testsuite, but this fix allows many tests to succeed that previously fell over. 2020-11-12 Joseph Myers <joseph@codesourcery.com> * lib/gdb.exp (gdb_file_cmd): Check for case where $arg.exe exists but $arg does not.
2020-11-13Fix readelf's and objdump's dislplay of DWO links when multiple links are ↵Nick Clifton4-40/+87
present. PR 26829 * dwarf.c (struct dwo_info): Add cu_offset field. (add_dwo_info): Add cu_offset parameter. Record in new dwo_info struct. (add_dwo_name): Add cu_offset field. (add_dwo_dir): Add cu_offset field. (add_dwo_id): Add cu_offset field. (read_and_display_attr_value): Pass cu_offset to dwo recording functions. (load_separate_debug_files): Accumulate name, dir and id values and display once for each CU. * testsuite/binutils-all/dwo.sL Use a separate CU for the second dwo link. * testsuite/binutils-all/readelf.k2: Update expected output.
2020-11-13gdb: delete a couple of declarations from f-lang.hAndrew Burgess3-21/+24
One declaration in f-lang.h is for a function that doesn't even exist, another is for a function that is only used within f-lang.c. One declaration is deleted, the other function I make static in f-lang.c. gdb/ChangeLog: * f-lang.c (fortran_argument_convert): Add declaration. Add header comment, taken from f-lang.h. Make static. * f-lang.h (f77_get_dynamic_array_length): Delete declaration. (fortran_argument_convert): Delete declaration.
2020-11-13gas, arm: PR26858 Fix availability of single precision vmul/vmla in arm modeAndre Vieira3-2/+16
This patch fixes a mistake when enabling MVE instructions that disabled support for single precision vmla and vmul for arm mode. gas/ChangeLog: 2020-11-12 Andre Vieira <andre.simoesdiasvieira@arm.com> PR 26858 * config/tc-arm.c (asm_opcode insns): Fix vmul and vmla's ARM_VARIANT. * testsuite/gas/arm/pr26858.s: New test. * testsuite/gas/arm/pr26858.d: New test.
2020-11-13Automatic date update in version.inGDB Administrator1-1/+1
2020-11-12gdb: rewrite how per language primitive types are managedAndrew Burgess15-816/+630
Consider the following GDB session: $ gdb (gdb) set language c (gdb) ptype void type = void (gdb) set language fortran (gdb) ptype void No symbol table is loaded. Use the "file" command. (gdb) With no symbol file loaded GDB and the language set to C GDB knows about the type void, while when the language is set to Fortran GDB doesn't know about the void, why is that? In f-lang.c, f_language::language_arch_info, we do have this line: lai->primitive_type_vector [f_primitive_type_void] = builtin->builtin_void; where we add the void type to the list of primitive types that GDB should always know about, so what's going wrong? It turns out that the primitive types are stored in a C style array, indexed by an enum, so Fortran uses `enum f_primitive_types'. The array is allocated and populated in each languages language_arch_info member function. The array is allocated with an extra entry at the end which is left as a NULL value, and this indicates the end of the array of types. Unfortunately for Fortran, a type is not assigned for each element in the enum. As a result the final populated array has gaps in it, gaps which are initialised to NULL, and so every time we iterate over the list (for Fortran) we stop early, and never reach the void type. This has been the case since 2007 when this functionality was added to GDB in commit cad351d11d6c3f6487cd. Obviously I could just fix Fortran by ensuring that either the enum is trimmed, or we create types for the missing types. However, I think a better approach would be to move to C++ data structures and removed the fixed enum indexing into the array approach. After this commit the primitive types are pushed into a vector, and GDB just iterates over the vector in the obvious way when it needs to hunt for a type. After this commit all the currently defined primitive types can be found when the language is set to Fortran, for example: $ gdb (gdb) set language fortran (gdb) ptype void type = void (gdb) A new test checks this functionality. I didn't see any other languages with similar issues, but I could have missed something. gdb/ChangeLog: * ada-exp.y (find_primitive_type): Make parameter const. * ada-lang.c (enum ada_primitive_types): Delete. (ada_language::language_arch_info): Update. * c-lang.c (enum c_primitive_types): Delete. (c_language_arch_info): Update. (enum cplus_primitive_types): Delete. (cplus_language::language_arch_info): Update. * d-lang.c (enum d_primitive_types): Delete. (d_language::language_arch_info): Update. * f-lang.c (enum f_primitive_types): Delete. (f_language::language_arch_info): Update. * go-lang.c (enum go_primitive_types): Delete. (go_language::language_arch_info): Update. * language.c (auto_or_unknown_language::language_arch_info): Update. (language_gdbarch_post_init): Use obstack_new, use array indexing. (language_string_char_type): Add header comment, call function in language_arch_info. (language_bool_type): Likewise (language_arch_info::bool_type): Define. (language_lookup_primitive_type_1): Delete. (language_lookup_primitive_type): Rewrite as a templated function to call function in language_arch_info, then instantiate twice. (language_arch_info::type_and_symbol::alloc_type_symbol): Define. (language_arch_info::lookup_primitive_type_and_symbol): Define. (language_arch_info::lookup_primitive_type): Define twice with different signatures. (language_arch_info::lookup_primitive_type_as_symbol): Define. (language_lookup_primitive_type_as_symbol): Rewrite to call a member function in language_arch_info. * language.h (language_arch_info): Complete rewrite. (language_lookup_primitive_type): Make templated. * m2-lang.c (enum m2_primitive_types): Delete. (m2_language::language_arch_info): Update. * opencl-lang.c (OCL_P_TYPE): Delete. (enum opencl_primitive_types): Delete. (opencl_type_data): Delete. (builtin_opencl_type): Delete. (lookup_opencl_vector_type): Update. (opencl_language::language_arch_info): Update, lots of content moved from... (build_opencl_types): ...here. This function is now deleted. (_initialize_opencl_language): Delete. * p-lang.c (enum pascal_primitive_types): Delete. (pascal_language::language_arch_info): Update. * rust-lang.c (enum rust_primitive_types): Delete. (rust_language::language_arch_info): Update. gdb/testsuite/ChangeLog: * gdb.fortran/types.exp: Add more tests.
2020-11-12gdb/dwarf: fix call to dwarf2_queue_guard in dw2_do_instantiate_symtabSimon Marchi2-1/+6
It took me a while to understand why that would even compile: it looks like we pass a type name as a pointer, that makes no sense. By looking at the DWARF, I understood that the compiler actually interprets it as a function declaration. So the statement was doing nothing, no dwarf2_queue_guard was instantiated. Fix it by passing the right variable name. gdb/ChangeLog: * dwarf2/read.c (dw2_do_instantiate_symtab): Fix call to dwarf2_queue_guard. Change-Id: I3a7bdead9e8c39f8342a471f10181b85b8f0d801
2020-11-12sim: pru: Add support for LMBD instructionDimitar Dimitrov5-0/+88
Binutils support for LMBD instruction was merged [1]. So add it also to simulator. LMBD instruction does left-most-bit-detection. It returns 32 if the given bit value is not found in the provided word value. [1] https://sourceware.org/pipermail/binutils/2020-October/113901.html sim/pru/ChangeLog: * pru.h (RS1SEL): New macro. (RS1_WIDTH): New macro. * pru.isa: Describe the LMBD instruction. sim/testsuite/sim/pru/ChangeLog: * lmbd.s: New test.
2020-11-12gdb/dwarf: fix typo in dwarf2/read.cSimon Marchi2-1/+6
gdb/ChangeLog: * dwarf2/read.c (dw2_do_instantiate_symtab): Fix typo in comment. Change-Id: I6cb98768c04a537cf3d427648bddc57c631518e5
2020-11-12gdb: convert "set debug dwarf-read" to new styleSimon Marchi2-152/+119
Add dwarf_read_debug_printf and dwarf_read_debug_printf_v macros and use them throughout dwarf2/read.c. The second one is used for "verbose" prints, when the value of "set debug dwarf-read" is >= 2. gdb/ChangeLog: * dwarf2/read.c (dwarf_read_debug_printf, dwarf_read_debug_printf_v): New macros, use throughout the file. Change-Id: I694da69da2e1f2caa4c27a421a975790636411e2
2020-11-12MSP430: gas: Ignore -md option required for GCC backward compatibilityJozef Lawrynowicz5-0/+30
The redundant -md option was removed in e4ae357fe8, but it is required for backwards compatibility with GCC 10, which passes it to the assembler implicitly in certain situations. It is now silently ignored. gas/ChangeLog: * config/tc-msp430.c (OPTION_MOVE_DATA): Define. (md_parse_option): Ignore OPTION_MOVE_DATA. (md_longopts): Handle -md option. * testsuite/gas/msp430/msp430.exp: Run new test. * testsuite/gas/msp430/empty.s: New test. * testsuite/gas/msp430/ignore-md.d: New test.
2020-11-12arc: Write correct "eret" value during register collectionShahab Vahedi2-3/+12
In collect_register() function of arc-linux-tdep.c, the "eret" (exception return) register value was not being reported correctly. This patch fixes that. Background: When asked for the "pc" value, we have to update the "eret" register with GDB's STOP_PC. The "eret" instructs the kernel code where to jump back when an instruction has stopped due to a breakpoint. This is how collect_register() was doing so: --------------8<-------------- if (regnum == gdbarch_pc_regnum (gdbarch)) regnum = ARC_ERET_REGNUM; regcache->raw_collect (regnum, buf + arc_linux_core_reg_offsets[regnum]); -------------->8-------------- Root cause: Although this is using the correct offset (ERET register's), it is also changing the REGNUM itself. Therefore, raw_collect (regnum, ...) is not reading from "pc" anymore. v2: - Fix a copy/paste issue as rightfully addressed by Tom [1]. [1] https://sourceware.org/pipermail/gdb-patches/2020-November/173208.html gdb/ChangeLog: * arc-linux-tdep.c (collect_register): Populate "eret" by "pc" value from the regcache when asked for "pc" value.
2020-11-12Fix Rust regression with -readnowTom Tromey4-24/+52
PR rust/26799 points out that a certain test case fails with -readnow. This happens because, with -readnow, there are no partial symtabs; but find_symbol_at_address requires these. This patch fixes this problem by searching all of an objfile's compunit symtabs if it does not have partial symbols. Note that this test will still fail with .gdb_index. I don't think that is readily fixable. gdb/ChangeLog 2020-11-12 Tom Tromey <tom@tromey.com> PR rust/26799: * symtab.c (find_symbol_at_address): Search symtabs if no psymtabs exist. gdb/testsuite/ChangeLog 2020-11-12 Tom Tromey <tom@tromey.com> PR rust/26799: * gdb.rust/traits.exp: Remove kfails.
2020-11-12Fix gdb.threads/tls-so_extern.exp with ClangGary Benson2-0/+7
Clang fails to compile gdb.threads/tls-so_extern_main.c, giving the following error: /gdbtest/src/gdb/testsuite/gdb.threads/tls-so_extern_main.c:28:1: warning: non-void function does not return a value [-Wreturn-type] This commit adds a return statement to the offending function. gdb/testsuite/ChangeLog: * gdb.threads/tls-so_extern_main.c (tls_ptr): Add missing return statement.
2020-11-12Fix up changelog entry of previous deltaNick Clifton1-2/+4
2020-11-12m32r sim: Add prototypes for functions that pass/return DI valuesNick Clifton2-1/+18
* m32r-sim.h (m32rbf_h_accum_get_handler): Always provide a prototype for this function. (m32rbf_h_accum_set_handler): Likewise. (m32r2f_h_accums_get_handler): Prototype. (m32r2f_h_accums_set_handler): Prototype.
generated by cgit v1.1 at 2024-11-19 13:09:13 +0000