aboutsummaryrefslogtreecommitdiff
path: root/gdb
AgeCommit message (Collapse)AuthorFilesLines
2021-01-06Fix fixed-point binary operation type handlingTom Tromey9-60/+152
Testing showed that gdb was not correctly handling some fixed-point binary operations correctly. Addition and subtraction worked by casting the result to the type of left hand operand. So, "fixed+int" had a different type -- and different value -- from "int+fixed". Furthermore, for multiplication and division, it does not make sense to first cast both sides to the fixed-point type. For example, this can prevent "f * 1" from yielding "f", if 1 is not in the domain of "f". Instead, this patch changes gdb to use the value. (This is somewhat different from Ada semantics, as those can yield a "universal fixed point".) This includes a new test case. It is only run in "minimal" mode, as the old-style fixed point works differently, and is obsolete, so I have no plans to change it. gdb/ChangeLog 2021-01-06 Tom Tromey <tromey@adacore.com> * ada-lang.c (ada_evaluate_subexp) <BINOP_ADD, BINOP_SUB>: Do not cast result. * valarith.c (fixed_point_binop): Handle multiplication and division specially. * valops.c (value_to_gdb_mpq): New function. (value_cast_to_fixed_point): Use it. gdb/testsuite/ChangeLog 2021-01-06 Tom Tromey <tromey@adacore.com> * gdb.ada/fixed_points/pck.ads (Delta4): New constant. (FP4_Type): New type. (FP4_Var): New variable. * gdb.ada/fixed_points/fixed_points.adb: Update. * gdb.ada/fixed_points.exp: Add tests for binary operators.
2021-01-06gdb/testsuite: fix race in ↵Simon Marchi3-3/+28
gdb.threads/signal-while-stepping-over-bp-other-thread.exp Commit 3ec3145c5dd6 ("gdb: introduce scoped debug prints") updated some tests using "set debug infrun" to handle the fact that a debug print is now shown after the prompt, after an inferior stop. The same issue happens in gdb.threads/signal-while-stepping-over-bp-other-thread.exp. If I run it in a loop, it eventually fails like these other tests. The problem is that the testsuite expects to see $gdb_prompt followed by the end of the buffer. It happens that expect reads $gdb_prompt and the debug print at the same time, in which case the regexp never matches and we get a timeout. The fix is the same as was done in 3ec3145c5dd6, make the testsuite believe that the prompt is the standard GDB prompt followed by that debug print. Since that test uses gdb_test_sequence, and the expected prompt is in gdb_test_sequence, add a -prompt switch to gdb_test_sequence to override the prompt used for that call. gdb/testsuite/ChangeLog: * lib/gdb.exp (gdb_test_sequence): Accept -prompt switch. * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Pass prompt containing debug print to gdb_test_sequence. Change-Id: I33161c53ddab45cdfeadfd50b964f8dc3caa9729
2021-01-05Prevent flickering when redrawing the TUI source windowHannes Domani2-1/+8
tui_win_info::refresh_window simply calls wrefresh, which internally does a doupdate. This redraws the source background window without the source pad. Then prefresh of the source pad draws the actual source code on top, which flickers. By changing this to wnoutrefresh, the actual drawing on the screen is only done once in the following prefresh, without flickering. gdb/ChangeLog: 2021-01-05 Hannes Domani <ssbssa@yahoo.de> * tui/tui-winsource.c (tui_source_window_base::refresh_window): Call wnoutrefresh instead of tui_win_info::refresh_window.
2021-01-05Redraw both spaces between line numbers and source codeHannes Domani2-1/+8
There a 2 spaces between the numbers and source code, but only one of them was redrawn. So if you increase the source window height, the second space keeps the character of the border rectangle. With this both spaces are redrawn, so the border rectangle character is overwritten. gdb/ChangeLog: 2021-01-05 Hannes Domani <ssbssa@yahoo.de> * tui/tui-source.c (tui_source_window::show_line_number): Redraw second space after line number.
2021-01-05Fix TUI source window drawingHannes Domani2-2/+11
The smaxrow and smaxcol parameters of prefresh are the bottom right corner of the text area inclusive, not exclusive. And if the source window grows bigger in height, the pad has to grow as well. gdb/ChangeLog: 2021-01-05 Hannes Domani <ssbssa@yahoo.de> PR tui/26927 * tui/tui-winsource.c (tui_source_window_base::refresh_window): Fix source pad size in prefresh. (tui_source_window_base::show_source_content): Grow source pad if necessary.
2021-01-04gdb: bfin: use align helperMike Frysinger2-3/+8
2021-01-04[gdb/symtab] Remove superfluous end-of-sequence markerTom de Vries4-2/+110
While working on PR26935 I noticed that when running test-case gdb.base/morestack.exp with target board unix/-m32/-fPIE/-pie and ld linker, I get this linetable fragment for morestack.S using readelf -wL: ... CU: ../../../../libgcc/config/i386/morestack.S: Line number Starting address View Stmt 109 0xc9c x ... 838 0xe03 x - 0xe04 636 0 x 637 0x3 x - 0x4 ... but with "maint info line-table" I get: ... INDEX LINE ADDRESS IS-STMT 0 END 0x00000004 Y 1 109 0x00000c9c Y ... 110 838 0x00000e03 Y 111 END 0x00000e04 Y ... So, apparently the entries with addresses 0x0 and 0x3 are filtered out because the addresses are out of range, but the same doesn't happen with the end-of-seq terminator. Fix this by filtering out end-of-seq terminators that do not actually terminate anything. Tested on x86_64-linux. gdb/ChangeLog: 2021-01-04 Tom de Vries <tdevries@suse.de> * buildsym.c (buildsym_compunit::record_line): Filter out end-of-seq terminators that do not terminate anything. gdb/testsuite/ChangeLog: 2021-01-04 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/dw2-out-of-range-end-of-seq.exp: New file.
2021-01-04gdb: introduce scoped debug printsSimon Marchi9-10/+65
I spent a lot of time reading infrun debug logs recently, and I think they could be made much more readable by being indented, to clearly see what operation is done as part of what other operation. In the current format, there are no visual cues to tell where things start and end, it's just a big flat list. It's also difficult to understand what caused a given operation (e.g. a call to resume_1) to be done. To help with this, I propose to add the new scoped_debug_start_end structure, along with a bunch of macros to make it convenient to use. The idea of scoped_debug_start_end is simply to print a start and end message at construction and destruction. It also increments/decrements a depth counter in order to make debug statements printed during this range use some indentation. Some care is taken to handle the fact that debug can be turned on or off in the middle of such a range. For example, a "set debug foo 1" command in a breakpoint command, or a superior GDB manually changing the debug_foo variable. Two macros are added in gdbsupport/common-debug.h, which are helpers to define module-specific macros: - scoped_debug_start_end: takes a message that is printed both at construction / destruction, with "start: " and "end: " prefixes. - scoped_debug_enter_exit: prints hard-coded "enter" and "exit" messages, to denote the entry and exit of a function. I added some examples in the infrun module to give an idea of how it can be used and what the result looks like. The macros are in capital letters (INFRUN_SCOPED_DEBUG_START_END and INFRUN_SCOPED_DEBUG_ENTER_EXIT) to mimic the existing SCOPE_EXIT, but that can be changed if you prefer something else. Here's an excerpt of the debug statements printed when doing "continue", where a displaced step is started: [infrun] proceed: enter [infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT [infrun] global_thread_step_over_chain_enqueue: enqueueing thread Thread 0x7ffff75a5640 (LWP 2289301) in global step over chain [infrun] start_step_over: enter [infrun] start_step_over: stealing global queue of threads to step, length = 1 [infrun] start_step_over: resuming [Thread 0x7ffff75a5640 (LWP 2289301)] for step-over [infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [Thread 0x7ffff75a5640 (LWP 2289301)] at 0x5555555551bd [displaced] displaced_step_prepare_throw: displaced-stepping Thread 0x7ffff75a5640 (LWP 2289301) now [displaced] prepare: selected buffer at 0x5555555550c2 [displaced] prepare: saved 0x5555555550c2: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 [displaced] amd64_displaced_step_copy_insn: copy 0x5555555551bd->0x5555555550c2: c7 45 fc 00 00 00 00 eb 13 8b 05 d4 2e 00 00 83 [displaced] displaced_step_prepare_throw: prepared successfully thread=Thread 0x7ffff75a5640 (LWP 2289301), original_pc=0x5555555551bd, displaced_pc=0x5555555550c2 [displaced] resume_1: run 0x5555555550c2: c7 45 fc 00 [infrun] infrun_async: enable=1 [infrun] prepare_to_wait: prepare_to_wait [infrun] start_step_over: [Thread 0x7ffff75a5640 (LWP 2289301)] was resumed. [infrun] operator(): step-over queue now empty [infrun] start_step_over: exit [infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop [infrun] proceed: resuming Thread 0x7ffff7da7740 (LWP 2289296) [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7da7740 (LWP 2289296)] at 0x7ffff7f7d9b7 [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: resuming Thread 0x7ffff7da6640 (LWP 2289300) [infrun] resume_1: thread Thread 0x7ffff7da6640 (LWP 2289300) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0). [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: [Thread 0x7ffff75a5640 (LWP 2289301)] resumed [infrun] proceed: resuming Thread 0x7ffff6da4640 (LWP 2289302) [infrun] resume_1: thread Thread 0x7ffff6da4640 (LWP 2289302) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0). [infrun] prepare_to_wait: prepare_to_wait [infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop [infrun] proceed: exit We can easily see where the call to `proceed` starts and end. We can also see why there are a bunch of resume_1 calls, it's because we are resuming threads, emulating all-stop on top of a non-stop target. We also see that debug statements nest well with other modules that have been migrated to use the "new" debug statement helpers (because they all use debug_prefixed_vprintf in the end. I think this is desirable, for example we could see the debug statements about reading the DWARF info of a library nested under the debug statements about loading that library. Of course, modules that haven't been migrated to use the "new" helpers will still print without indentations. This will be one good reason to migrate them. I think the runtime cost (when debug statements are disabled) of this is reasonable, given the improvement in readability. There is the cost of the conditionals (like standard debug statements), one more condition (if (m_must_decrement_print_depth)) and the cost of constructing a stack object, which means copying a fews pointers. Adding the print in fetch_inferior_event breaks some tests that use "set debug infrun", because it prints a debug statement after the prompt. I adapted these tests to cope with it, by using the "-prompt" switch of gdb_test_multiple to as if this debug statement is part of the expected prompt. It's unfortunate that we have to do this, but I think the debug print is useful, and I don't want a few tests to get in the way of adding good debug output. gdbsupport/ChangeLog: * common-debug.h (debug_print_depth): New. (struct scoped_debug_start_end): New. (scoped_debug_start_end): New. (scoped_debug_enter_exit): New. * common-debug.cc (debug_prefixed_vprintf): Print indentation. gdb/ChangeLog: * debug.c (debug_print_depth): New. * infrun.h (INFRUN_SCOPED_DEBUG_START_END): New. (INFRUN_SCOPED_DEBUG_ENTER_EXIT): New. * infrun.c (start_step_over): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT. (proceed): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT and INFRUN_SCOPED_DEBUG_START_END. (fetch_inferior_event): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT. gdbserver/ChangeLog: * debug.cc (debug_print_depth): New. gdb/testsuite/ChangeLog: * gdb.base/ui-redirect.exp: Expect infrun debug print after prompt. * gdb.threads/ia64-sigill.exp: Likewise. * gdb.threads/watchthreads-reorder.exp: Likewise. Change-Id: I7c3805e6487807aa63a1bae318876a0c69dce949
2021-01-04gdb: use infrun_debug_printf in print_target_wait_resultsSimon Marchi2-25/+15
The code in print_target_wait_results uses a single call to debug_printf in order to make sure a single timestamp is emitted, despite printing multiple lines. The result is: 941502.043284 [infrun] target_wait (-1.0.0, status) = [infrun] 649832.649832.0 [process 649832], [infrun] status->kind = stopped, signal = GDB_SIGNAL_TRAP I find this decision a bit counter productive, because it messes up the alignment of the three lines. We don't care that three (slightly different) timestamps are printed. I suggest to change this function to use infrun_debug_printf, with this result: 941601.425771 [infrun] print_target_wait_results: target_wait (-1.0.0 [process -1], status) = 941601.425824 [infrun] print_target_wait_results: 651481.651481.0 [process 651481], 941601.425867 [infrun] print_target_wait_results: status->kind = stopped, signal = GDB_SIGNAL_TRAP Note that the current code only prints the waiton_ptid as a string between square brackets if pid != -1. I don't think this complexity is needed in a debug print. I made it so it's always printed, which I think results in a much simpler function. gdb/ChangeLog: * infrun.c (print_target_wait_results): Use infrun_debug_printf. Change-Id: I817bd10286b8e641a6c751ac3a1bd1ddf9b18ce0
2021-01-04gdb: make "set debug timestamp" work nice with new debug printoutsSimon Marchi2-15/+24
New in v2: - implement by modifying vprintf_unfiltered rather than debug_prefixed_vprintf. I tried enabling debug timestamps, and realized that it doesn't play well with the revamp of the debug printouts I've been working on: $ ./gdb -q -nx --data-directory=data-directory -ex "set debug infrun" -ex "set debug timestamp" a.out Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x1131: file test.c, line 2. Starting program: /home/smarchi/build/binutils-gdb-all-targets/gdb/a.out 939897.769338 [infrun] infrun_async: 939897.769383 enable=1 939897.769409 939897.915218 [infrun] proceed: 939897.915281 addr=0x7ffff7fd0100, signal=GDB_SIGNAL_0 939897.915315 939897.915417 [infrun] start_step_over: 939897.915464 stealing global queue of threads to step, length = 0 939897.915502 939897.915567 [infrun] operator(): 939897.915601 step-over queue now empty 939897.915633 939897.915690 [infrun] proceed: 939897.915729 resuming process 636244 939897.915768 939897.915892 [infrun] resume_1: 939897.915954 step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [process 636244] at 0x7ffff7fd0100 939897.915991 939897.916119 [infrun] prepare_to_wait: 939897.916153 prepare_to_wait 939897.916201 939897.916661 [infrun] target_wait (-1.0.0, status) = [infrun] 636244.636244.0 [process 636244], [infrun] status->kind = stopped, signal = GDB_SIGNAL_TRAP 939897.916734 [infrun] handle_inferior_event: 939897.916768 status->kind = stopped, signal = GDB_SIGNAL_TRAP 939897.916799 This is due to debug_prefixed_vprintf being implemented as three separate calls to debug_printf / debug_vprintf. Each call gets its own timestamp and newline, curtesy of vprintf_unfiltered. My first idea was to add a "line_start" parameter to debug_vprintf, allowing the caller to say whether the print is the start of the line. A debug timestamp would only be printed if line_start was true. However, that was much more invasive than the simple fix implemented in this patch. My second idea was to make debug_prefixed_vprintf use string_printf and issue a single call to debug_printf. That would however prevent future use of styling in the debug messages. What is implemented in this patch is the same as is implemented in GDBserver: the timestamp-printing code in GDB tracks whether the last debug output ended with a newline. If so, it prints a timestamp on the next debug output. After the fix, it looks like this: $ ./gdb -q -nx --data-directory=data-directory -ex "set debug infrun" -ex "set debug timestamp" a.out Reading symbols from a.out... (gdb) start Temporary breakpoint 1 at 0x1131: file test.c, line 2. Starting program: /home/smarchi/build/binutils-gdb-all-targets/gdb/a.out 941112.135662 [infrun] infrun_async: enable=1 941112.279930 [infrun] proceed: addr=0x7ffff7fd0100, signal=GDB_SIGNAL_0 941112.280064 [infrun] start_step_over: stealing global queue of threads to step, length = 0 941112.280125 [infrun] operator(): step-over queue now empty 941112.280194 [infrun] proceed: resuming process 646228 941112.280332 [infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [process 646228] at 0x7ffff7fd0100 941112.280480 [infrun] prepare_to_wait: prepare_to_wait 941112.281004 [infrun] target_wait (-1.0.0, status) = [infrun] 646228.646228.0 [process 646228], [infrun] status->kind = stopped, signal = GDB_SIGNAL_TRAP 941112.281078 [infrun] handle_inferior_event: status->kind = stopped, signal = GDB_SIGNAL_TRAP gdb/ChangeLog: * utils.c (vfprintf_unfiltered): Print timestamp only when previous debug output ended with a newline. Change-Id: Idcfe3acc7e3d0f526a5f0a43a5e0884bf93c41ae
2021-01-04gdb/testsuite: avoid reading files through the remote protocol in ↵Simon Marchi18-48/+208
gdb.server/*.exp When I run some tests in gdb.server (fox example gdb.server/ext-attach.exp) on Ubuntu 20.04 with separate debug info for glibc installed, they often time out. This is because GDB reads the debug info through the remote protocol which is particularly slow: attach 316937 Attaching to program: /home/smarchi/build/binutils-gdb-all-targets/gdb/testsuite/outputs/gdb.server/ext-attach/ext-attach, process 316937 Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target... warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. Reading /lib64/ld-linux-x86-64.so.2 from remote target... Reading symbols from target:/lib/x86_64-linux-gnu/libc.so.6... Reading /lib/x86_64-linux-gnu/libc-2.31.so from remote target... Reading /lib/x86_64-linux-gnu/.debug/libc-2.31.so from remote target... Reading /usr/lib/debug//lib/x86_64-linux-gnu/libc-2.31.so from remote target... FAIL: gdb.server/ext-attach.exp: attach to remote program 1 (timeout) This is avoided in gdbserver boards by adding "set sysroot" to GDBFLAGS (see boards/local-board.exp), which makes GDB read files from the local filesystem. But gdb.server tests spawn GDBserver directly, so are ran even when using the default unix board, where the "set sysroot" isn't used. Modify these tests to append "set sysroot" to the GDBFLAGS, a bit like lib/local-board.exp does. One special case is gdb.server/sysroot.exp, whose intent is to test different "set sysroot" values. For this one, increase the timeout when testing the "target:" sysroot. gdb/testsuite/ChangeLog: * gdb.server/abspath.exp: Append "set sysroot" to GDBFLAGS. * gdb.server/connect-without-multi-process.exp: Likewise. * gdb.server/exit-multiple-threads.exp: Likewise. * gdb.server/ext-attach.exp: Likewise. * gdb.server/ext-restart.exp: Likewise. * gdb.server/ext-run.exp: Likewise. * gdb.server/ext-wrapper.exp: Likewise. * gdb.server/multi-ui-errors.exp: Likewise. * gdb.server/no-thread-db.exp: Likewise. * gdb.server/reconnect-ctrl-c.exp: Likewise. * gdb.server/run-without-local-binary.exp: Likewise. * gdb.server/server-kill.exp: Likewise. * gdb.server/server-run.exp: Likewise. * gdb.server/solib-list.exp: Likewise. * gdb.server/stop-reply-no-thread.exp: Likewise. * gdb.server/wrapper.exp: Likewise. * gdb.server/sysroot.exp: Increase timeout when testing the target: sysroot. Change-Id: I7451bcc737f90e2cd0b977e9f09da3710774b0bf
2021-01-04gdb/testsuite: use clean_restart in gdb.server/server-run.expSimon Marchi2-4/+5
I think this sequence of commands can be replaced with clean_restart. gdb/testsuite/ChangeLog: * gdb.server/server-run.exp: Use clean_restart. Change-Id: If8c3eaa89f4ee58901282f5f1d5d4e1100ce7ac5
2021-01-04gdb/testsuite: use clean_restart in gdb.server/ext-run.expSimon Marchi2-7/+7
I think the sequence of commands here could be replaced with clean_restart. The test starts with GDB not started, so it should not be started when we reach gdb_skip_xml_test. gdb/testsuite/ChangeLog: * gdb.server/ext-run.exp: Use clean_restart. Change-Id: I8c033bad6c52f3d58d6aa377b8355fc633c7aede
2021-01-04gdb/testsuite: use build_executable in gdb.server/stop-reply-no-thread.expSimon Marchi2-1/+6
This test uses prepare_for_testing, then does a clean_restart for each test configuration. prepare_for_testing does a build_executable plus a clean_restart. So the clean_restart inside prepare_for_testing is done for nothing. Change prepare_for_testing to just build_executable to avoid the unnecessary clean_restart. gdb/testsuite/ChangeLog: * gdb.server/stop-reply-no-thread.exp: Use build_executable instead of prepare_for_testing. Change-Id: I8b2a2e90353c57c39c49a3665083331b4882fdd0
2021-01-04gdb/testsuite: use clean_restart in gdb.server/solib-list.expSimon Marchi2-6/+5
I think this sequence of commands can be replaced by clean_restart, despite what the comment says, as long as we don't use the `binfile` argument to clean_restart. gdb/testsuite/ChangeLog: * gdb.server/solib-list.exp: Use clean_restart. Change-Id: I4930564c50a1865cbffe0d660a4296c9d2158084
2021-01-04[gdb/testsuite] Don't require gold for gdb.base/morestack.expTom de Vries3-11/+7
While working on PR26935 I noticed that the test-case requires the gold linker, but doesn't really need it. The -fuse-ld=gold was added to support the printf in the test-case, which prints some information but is not otherwise needed for the test-case. Fix this by removing the printf and the corresponding -fuse-ld=gold. Tested on x86_64-linux. Also checked that the test still fails when the fix from the commit that added the test-case is reverted. gdb/testsuite/ChangeLog: 2021-01-04 Tom de Vries <tdevries@suse.de> * gdb.base/morestack.c: Remove printf. * gdb.base/morestack.exp: Don't use -fuse-ld=gold.
2021-01-04Refactor struct trad_frame_saved_regsLuis Machado37-403/+555
The following patch drops the overloading going on with the trad_frame_saved_reg struct and defines a new struct with a KIND enum and a union of different fields. The new struct looks like this: struct trad_frame_saved_reg { setters/getters ... private: trad_frame_saved_reg_kind m_kind; union { LONGEST value; int realreg; LONGEST addr; const gdb_byte *value_bytes; } m_reg; }; And the enums look like this: /* Describes the kind of encoding a stored register has. */ enum class trad_frame_saved_reg_kind { /* Register value is unknown. */ UNKNOWN = 0, /* Register value is a constant. */ VALUE, /* Register value is in another register. */ REALREG, /* Register value is at an address. */ ADDR, /* Register value is a sequence of bytes. */ VALUE_BYTES }; The patch also adds setters/getters and updates all the users of the old struct. It is worth mentioning that due to the previous overloaded nature of the fields, some tdep files like to store negative offsets and indexes in the ADDR field, so I kept the ADDR as LONGEST instead of CORE_ADDR. Those cases may be better supported by a new enum entry. I have not addressed those cases in this patch to prevent unwanted breakage, given I have no way to test some of the targets. But it would be nice to clean those up eventually. The change to frame-unwind.* is to constify the parameter being passed to the unwinding functions, given we now accept a "const gdb_byte *" for value bytes. Tested on aarch64-linux/Ubuntu 20.04/18.04 and by building GDB with --enable-targets=all. gdb/ChangeLog: 2021-01-04 Luis Machado <luis.machado@linaro.org> Update all users of trad_frame_saved_reg to use the new member functions. Remote all struct keywords from declarations of trad_frame_saved_reg types, except on forward declarations. * aarch64-tdep.c: Update. * alpha-mdebug-tdep.c: Update. * alpha-tdep.c: Update. * arc-tdep.c: Update. * arm-tdep.c: Update. * avr-tdep.c: Update. * cris-tdep.c: Update. * csky-tdep.c: Update. * frv-tdep.c: Update. * hppa-linux-tdep.c: Update. * hppa-tdep.c: Update. * hppa-tdep.h: Update. * lm32-tdep.c: Update. * m32r-linux-tdep.c: Update. * m32r-tdep.c: Update. * m68hc11-tdep.c: Update. * mips-tdep.c: Update. * moxie-tdep.c: Update. * riscv-tdep.c: Update. * rs6000-tdep.c: Update. * s390-linux-tdep.c: Update. * s390-tdep.c: Update. * score-tdep.c: Update. * sparc-netbsd-tdep.c: Update. * sparc-sol2-tdep.c: Update. * sparc64-fbsd-tdep.c: Update. * sparc64-netbsd-tdep.c: Update. * sparc64-obsd-tdep.c: Update. * sparc64-sol2-tdep.c: Update. * tilegx-tdep.c: Update. * v850-tdep.c: Update. * vax-tdep.c: Update. * frame-unwind.c (frame_unwind_got_bytes): Make parameter const. * frame-unwind.h (frame_unwind_got_bytes): Likewise. * trad-frame.c: Update. Remove TF_REG_* enum. (trad_frame_alloc_saved_regs): Add a static assertion to check for a trivially-constructible struct. (trad_frame_reset_saved_regs): Adjust to use member function. (trad_frame_value_p): Likewise. (trad_frame_addr_p): Likewise. (trad_frame_realreg_p): Likewise. (trad_frame_value_bytes_p): Likewise. (trad_frame_set_value): Likewise. (trad_frame_set_realreg): Likewise. (trad_frame_set_addr): Likewise. (trad_frame_set_unknown): Likewise. (trad_frame_set_value_bytes): Likewise. (trad_frame_get_prev_register): Likewise. * trad-frame.h: Update. (trad_frame_saved_reg_kind): New enum. (struct trad_frame_saved_reg) <addr, realreg, data>: Remove. <m_kind, m_reg>: New member fields. <set_value, set_realreg, set_addr, set_unknown, set_value_bytes> <kind, value, realreg, addr, value_bytes, is_value, is_realreg> <is_addr, is_unknown, is_value_bytes>: New member functions.
2021-01-02gdb: fix typos in comments in target-float.cSimon Marchi2-2/+6
gdb/ChangeLog: * target-float.c: Fix typos. Change-Id: Ib65e90746d0a7c77c3fbead81139facb40b91977
2021-01-02Fix pretty printer of main_type.flds_bnds.boundsHannes Domani2-5/+10
In struct dynamic_prop the members kind and data were renamed to m_kind and m_data. And flag_upper_bound_is_count is actually in bounds directly, not in its high member. gdb/ChangeLog: 2021-01-02 Hannes Domani <ssbssa@yahoo.de> * gdb-gdb.py.in: Fix main_type.flds_bnds.bounds pretty printer.
2021-01-01Manual updates of copyright year range not covered by gdb/copyright.pyJoel Brobecker5-5/+13
gdb/ChangeLog: * gdbarch.sh: Update copyright year range. gdb/doc/ChangeLog: * gdb.texinfo, refcard.tex: Update copyright year range.
2021-01-01Update copyright year range in all GDB filesJoel Brobecker5433-5432/+5436
This commits the result of running gdb/copyright.py as per our Start of New Year procedure... gdb/ChangeLog Update copyright year range in copyright header of all GDB files.
2021-01-01gdb/copyright.py: Also update sources in "gdbserver" and "gdbsupport"Joel Brobecker2-1/+8
This commit adjusts GDB's copyright.py script, following two past changes: - gdb/gdbserver/ being move to the toplevel directory; - gdb/common/ being renamed to gdbsupport/. gdb/ChangeLog: * copyright.py (get_update_list): Add "gdbserver" and "gdbsupport" to the list of directories to update.
2021-01-01Update copyright year in version message for gdb, gdbserver and gdbreplayJoel Brobecker2-1/+5
gdb/ChangeLog: * top.c (print_gdb_version): Update copyright year. gdbserver/ChangeLog: * server.cc (gdbserver_version): Update copyright year. * gdbreplay.cc (gdbreplay_version): Likewise.
2021-01-01Rotate gdb/ChangeLogJoel Brobecker3-18741/+18755
As a results of the rotation, this introduces a new file which needed to be added to DJGPP's fnchange.lst. gdb/ChangeLog * config/djgpp/fnchange.lst: Add entry for gdb/ChangeLog-2020.
2020-12-31Update gdb.rust tests for Rust 1.49Tom Tromey2-4/+14
Rust 1.49 was released today, and it includes some library changes which caused some gdb.rust tests to fail. This patch adapts the test suite to the new output. I also verified that this continues to work with Rust 1.48. gdb/testsuite/ChangeLog 2020-12-31 Tom Tromey <tom@tromey.com> * gdb.rust/simple.exp: Update output for Rust 1.49.
2020-12-31Fix passing debug options for gccBernd Edlinger2-1/+5
Fix a bug in the test where we were missing "additional_flags=", causing -gstatement-frontiers not to be passed to the compiler. The issue was introduced in eb24648c453c28f2898fb599311ba004394a8b41 ("Fix gdb.cp/step-and-next-inline.exp with Clang"). gdb/testsuite: 2020-12-31 Bernd Edlinger <bernd.edlinger@hotmail.de> * gdb.cp/step-and-next-inline.exp: Fix test case.
2020-12-30gdb/testsuite: de-duplicate test names in gdb.python/py-frame-args.expSimon Marchi2-22/+30
Use with_test_prefix to de-duplicate test names. gdb/testsuite/ChangeLog: * gdb.python/py-frame-args.exp: De-duplicate test names. Change-Id: I5cc8bee692a0d071cb78258aca80ea642e00e7a8
2020-12-29Fix wrong method nameHannes Domani2-1/+5
The objects returned by FrameDecorator.frame_args need to implement a method named symbol, not argument. gdb/doc/ChangeLog: 2020-12-29 Hannes Domani <ssbssa@yahoo.de> * python.texi (Frame Decorator API): Fix method name.
2020-12-27Simplify MULTI_SUBSCRIPT implementationTom Tromey2-29/+12
The MULTI_SUBSCRIPT code in evaluate_subexp_standard has a comment saying that perhaps the EVAL_SKIP handling is incorrect. This patch simplifies this code. In particular, it precomputes all the indices in a separate loop and removes some complicated flow-control. Tested using the gdb.modula2 and gdb.dlang test suites, as these are the only parsers that emit MULTI_SUBSCRIPT. gdb/ChangeLog 2020-12-27 Tom Tromey <tom@tromey.com> * eval.c (evaluate_subexp_standard) <case MULTI_SUBSCRIPT>: Simplify.
2020-12-24gdb: avoid resolving dynamic properties for non-allocated arraysAndrew Burgess7-24/+240
In PR gdb/27059 an issue was discovered where GDB would sometimes trigger undefined behaviour in the form of signed integer overflow. The problem here is that GDB was reading random garbage from the inferior memory space, assuming this data was valid, and performing arithmetic on it. This bug raises an interesting general problem with GDB's DWARF expression evaluator, which is this: We currently assume that the DWARF expressions being evaluated are well formed, and well behaving. As an example, this is the expression that the bug was running into problems on, this was used as the expression for a DW_AT_byte_stride of a DW_TAG_subrange_type: DW_OP_push_object_address; DW_OP_plus_uconst: 88; DW_OP_deref; DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref; DW_OP_mul Two values are read from the inferior and multiplied together. GDB should not assume that any value read from the inferior is in any way sane, as such the implementation of DW_OP_mul should be guarding against overflow and doing something semi-sane here. However, it turns out that the original bug PR gdb/27059, is hitting a more specific case, which doesn't require changes to the DWARF expression evaluator, so I'm going to leave the above issue for another day. In the test mentioned in the bug GDB is actually trying to resolve the dynamic type of a Fortran array that is NOT allocated. A non-allocated Fortran array is one that does not have any data allocated for it yet, and even the upper and lower bounds of the array are not yet known. It turns out that, at least for gfortran compiled code, the data fields that describe the byte-stride are not initialised until the array is allocated. This leads me to the following conclusion: GDB should not try to resolve the bounds, or stride information for an array that is not allocated (or not associated, a similar, but slightly different Fortran feature). Instead, each of these properties should be set to undefined if the array is not allocated (or associated). That is what this commit does. There's a new flag that is passed around during the dynamic array resolution. When this flag is true the dynamic properties are resolved using the DWARF expressions as they currently are, but when this flag is false the expressions are not evaluated, and instead the properties are set to undefined. gdb/ChangeLog: PR gdb/27059 * eval.c (evaluate_subexp_for_sizeof): Handle not allocated and not associated arrays. * f-lang.c (fortran_adjust_dynamic_array_base_address_hack): Don't adjust arrays that are not allocated/associated. * gdbtypes.c (resolve_dynamic_range): Update header comment. Add new parameter which is used to sometimes set dynamic properties to undefined. (resolve_dynamic_array_or_string): Update header comment. Add new parameter which is used to guard evaluating dynamic properties. Resolve allocated/associated properties first. gdb/testsuite/ChangeLog: PR gdb/27059 * gdb.dwarf2/dyn-type-unallocated.c: New file. * gdb.dwarf2/dyn-type-unallocated.exp: New file.
2020-12-24gdb: include allocated/associated properties in 'maint print type'Andrew Burgess2-0/+23
Adds the allocated and associated dynamic properties into the output of the 'maintenance print type' command. gdb/ChangeLog: * gdbtypes (recursive_dump_type): Include allocated and associated properties.
2020-12-24gdb/gdbtypes.h: Fix comparison of uninitialized valuesLancelot SIX2-3/+10
When called with an array type of unknown dimensions, is_scalar_type_recursive ended up comparing uninitialized values. This was picked up by the following compiler warning: CXX gdbtypes.o /binutils-gdb/gdb/gdbtypes.c: In function int is_scalar_type_recursive(type*): /binutils-gdb/gdb/gdbtypes.c:3670:38: warning: high_bound may be used uninitialized in this function [-Wmaybe-uninitialized] 3670 | return high_bound == low_bound && is_scalar_type_recursive (elt_type); | ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /binutils-gdb/gdb/gdbtypes.c:3670:38: warning: low_bound may be used uninitialized in this function [-Wmaybe-uninitialized] This patch makes sure that when dealing with an array of unknown size (or an array of more than 1 element), is_scalar_type_recursive returns false. gdb/ChangeLog: * gdbtypes.c (is_scalar_type_recursive): Prevent comparison between uninitialized values. Change-Id: Ifc005ced166aa7a065fef3e652977bae67625bf4
2020-12-23Clarify language for the '?' packetAlex Bennée2-3/+8
Both QEMU and kgdb make the assumption that the '?' packet is only sent during the initial setup of a gdbstub connection. Both use that knowledge to reset breakpoints and ensure the gdbstub is in a clean-state on a resumed connection. This can cause confusion for others implementing clients that speak to gdbstub devices. To avoid that make the language clearer that this is a start-up query packet that you only expect to see once. Signed-off-by: Alex Bennée <alex.bennee@linaro.org> gdb/doc/ChangeLog: * gdb.texinfo (Packets): Clarify language for ? packet. Change-Id: Iae25d3110fe28b8d2467704962a6889e55224ca5
2020-12-23gdb: remove some uses of LA_PRINT_STRINGAndrew Burgess6-21/+33
This commit removes some, but not all, uses of LA_PRINT_STRING. In this commit I've removed those uses where there is an obvious language object on which I can instead call the printstr method. In the remaining 3 uses it is harder to know if the correct thing is to call printstr on the current language, or on a specific language. Currently obviously, we always call on the current language (as that's what LA_PRINT_STRING does), and clearly this behaviour is good enough right now, but is it "right"? I've left them for now and will give them more thought in the future. gdb/ChangeLog: * expprint.c (print_subexp_standard): Replace uses of LA_PRINT_STRING. * f-valprint.c (f_language::value_print_inner): Likewise. * guile/scm-pretty-print.c (ppscm_print_string_repr): Likewise. * p-valprint.c (pascal_language::value_print_inner): Likewise. * python/py-prettyprint.c (print_string_repr): Likewise.
2020-12-23gdb: move rust_language into rust-lang.hAndrew Burgess4-281/+346
Move the rust_language class declaration into the rust-lang.h header file. This allows for the function implementations called directly in rust-lang.c and rust-exp.y without the need for trampoline functions. There should be no user visible changes after this commit. gdb/ChangeLog: * rust-exp.y (rust_parse): Rename to... (rust_language::parser): ...this. * rust-lang.c (-rust_printstr): Rename to... (rust_language::printstr): ...this. (rust_value_print_inner): Delete declaration. (val_print_struct): Rename to... (rust_language::val_print_struct): ...this. Update calls to member functions. (rust_print_enum): Rename to... (rust_language::print_enum): ...this. Update calls to member functions. (rust_value_print_inner): Rename to... (rust_language::value_print_inner): ...this. Update calls to member functions. (exp_descriptor_rust): Rename to... (rust_language::exp_descriptor_tab): ...this. (class rust_language): Move to rust-lang.h. (rust_language::language_arch_info): Implementation moved to here from class declaration. (rust_language::print_type): Likewise. (rust_language::emitchar): Likewise. (rust_language::is_string_type_p): Likewise. * rust-lang.h: Add 'demangle.h', 'language.h', 'value.h', and 'c-lang.h' includes. (rust_parse): Delete declaration. (class rust_language): Class declaration moved here from rust-lang.c.
2020-12-23gdb/objc: fix bug in objc_language::opcode_print_tableAndrew Burgess2-1/+6
In this commit: commit b7c6e27dbbbbe678b2e2f0bf617605e055e1b378 Date: Tue Aug 4 17:07:59 2020 +0100 gdb: Convert language_data::la_op_print_tab to a method A bug was introduced, the objc language now returns the wrong op_print table. Fixed in this commit. gdb/ChangeLog: * objc-lang.c (objc_language::opcode_print_table): Return objc_op_print_tab.
2020-12-23gdb: move pascal_language into p-lang.hAndrew Burgess6-436/+506
Move the pascal_language class declaration into the p-lang.h header file. This allows for the function implementations to be spread over the different p-*.c files without the need for global trampoline functions. As a consequence of this change many of the Pascal value and type printing helper functions have become member functions within the pascal_language class. There should be no user visible changes after this commit. gdb/ChangeLog: * p-exp.y (exp): Update call to pascal_is_string_type. (pascal_parse): Rename to... (pascal_language::parser): ...this. * p-lang.c (is_pascal_string_type): Rename to... (pascal_is_string_type): ...this. (pascal_one_char): Rename to... (pascal_language::print_one_char): ...this. (pascal_printchar): Rename to... (pascal_language::printchar): ...this. Update call to print_one_char member function. (pascal_op_print_tab): Rename to... (pascal_language::op_print_tab): ...this. (class pascal_language): Moved to p-lang.h. (pascal_language::language_arch_info): Function implementation moved out of class declaration. (pascal_language::printstr): Likewise. * p-lang.h (pascal_parse): Delete declaration. (pascal_is_string_type): Declare. (pascal_print_type): Delete declaration. (pascal_print_typedef): Delete declaration. (pascal_value_print_inner): Delete declaration. (pascal_value_print): Delete declaration. (pascal_type_print_method_args): Delete declaration. (is_pascal_string_type): Delete declaration. (pascal_printchar): Delete declaration. (pascal_builtin_types): Delete declaration. (pascal_type_print_base): Delete declaration. (pascal_type_print_varspec_prefix): Delete declaration. (class pascal_language): Moved here from p-lang.c. * p-typeprint.c (pascal_type_print_varspec_suffix): Delete declaration. (pascal_type_print_derivation_info): Delete declaration. (pascal_print_type): Rename to... (pascal_language::print_type): ...this. Update calls to member functions. (pascal_print_typedef): Rename to... (pascal_language::print_typedef): ...this. Update calls to member functions. (pascal_type_print_derivation_info): Rename to... (pascal_language::type_print_derivation_info): ...this. (pascal_type_print_method_args): Rename to... (pascal_language::type_print_method_args): ...this. (pascal_type_print_varspec_prefix): Rename to... (pascal_language::type_print_varspec_prefix): ...this. Update calls to member functions. (pascal_print_func_args): Rename to... (pascal_language::print_func_args): ...this. Update calls to member functions. (pascal_type_print_func_varspec_suffix): Rename to... (pascal_language::type_print_func_varspec_suffix): ...this. Update calls to member functions. (pascal_type_print_varspec_suffix): Rename to... (pascal_language::type_print_varspec_suffix): ...this. Update calls to member functions. (pascal_type_print_base): Rename to... (pascal_language::type_print_base): ...this. Update calls to member functions. * p-valprint.c (pascal_value_print_inner): Rename to... (pascal_language::value_print_inner): ...this. Update calls to member functions. (pascal_value_print): Rename to... (pascal_language::value_print): ...this. Update calls to member functions.
2020-12-23gdb: move go_language class declaration into header fileAndrew Burgess7-140/+161
Move the go_language class into go-lang.h, this allows us to have member functions implemented directly in the different go-*.c files instead of having to trampoline out to global functions. There should be no user visible changes after this commit. gdb/ChangeLog: * go-exp.y (go_parse): Rename to... (go_language::parser): ...this. * go-lang.c (go_demangle): Rename to... (go_language::demangle_symbol): ...this. (go_language::expression_ops): Implementation moved here out of class declaration. (go_op_print_tab): Rename to... (go_language::op_print_tab): ...this, update comment. (class go_language): Declaration moved to go-lang.h. (go_language::language_arch_info): Implementation moved here out of class declaration. * go-lang.h (go_parse): Delete declaration. (go_demangle): Delete declaration. (go_print_type): Delete declaration. (go_value_print_inner): Delete declaration. (class go_language): Declaration moved here from go-lang.c. * go-typeprint.c (go_print_type): Rename to... (go_language::print_type): ...this. * go-valprint.c (go_value_print_inner): Rename to... (go_language::value_print_inner): ...this. * symtab.c (demangle_for_lookup): Call demangle_symbol method on the go_language object.
2020-12-23gdb: remove LA_EMIT_CHAR macroAndrew Burgess5-5/+12
Now that every use of the LA_EMIT_CHAR macro is within a language_defn member function we can simply call the emitchar member function directly instead of using the LA_EMIT_CHAR macro. If we are ever inside a language object, for example, cplus_language, while current_language points at something other than cplus_language then this commit will result in a change in behaviour. However, I believe if we did have such a difference then this would be a bug in GDB. AS such I'm going to claim there _should_ be no user visible changes from this commit. gdb/ChangeLog: * c-lang.c (language_defn::printchar): Call emitchar, not LA_EMIT_CHAR. * f-lang.h (f_language::printchar): Likewise. * language.h (LA_EMIT_CHAR): Delete macro. * rust-lang.c (rust_language::printchar): Call emitchar, not LA_EMIT_CHAR.
2020-12-23gdb: rename c_printchar as language_defn::printcharAndrew Burgess4-12/+12
This commit removes the global function c_printchar and moves the implementation into language_defn::printchar. There should be no user visible changes after this commit. gdb/ChangeLog: * c-lang.c (c_printchar): Rename to... (language_defn::printchar): ...this. * c-lang.h (c_printchar): Delete declaration. * language.c (language_defn::printchar): Delete this implementation. Is now implemented in c-lang.c.
2020-12-23gdb: avoid accessing global C++ language implementation functionsAndrew Burgess2-3/+9
The function c_printchar is called from two places; it provides the implementation of language_defn::printchar and it is called from dwarf2_compute_name. It would be nice to rename c_printchar as language_defn::printchar and so avoid the trampoline. To achieve this, instead of calling c_printchar directly from the DWARF code, I lookup the C++ language object and call the printchar member function. In a later commit I can then rename c_printchar. There should be no user visible changes after this commit. gdb/ChangeLog: * dwarf2/read.c (dwarf2_compute_name): Call methods on C++ language object instead of calling global functions directly.
2020-12-23gdb: delete unused function print_char_charsAndrew Burgess3-40/+5
Spotted that print_char_chars appears to be unused, delete it. There should be no user visible changes after this commit. gdb/ChangeLog: * valprint.c (print_char_chars): Delete definition. * valprint.h (print_char_chars): Delete declaration.
2020-12-23Add myself to gdb/MAINTAINERSSamuel Thibault2-0/+3
gdb/ChangeLog: * MAINTAINERS (Write After Approval): Add myself.
2020-12-23hurd: Add changelog for dca11eb872c9Samuel Thibault1-0/+8
2020-12-23hurd: Fix getting VM_MIN/MAX_ADDRESSSamuel Thibault1-0/+1
gnu-nat.c was getting the inclusion of vm_param.h only by luck. We need to explicitly include it to be sure to get the definitions of VM_MIN/MAX_ADDRESS. gdb/ChangeLog: * gnu-nat.c: Include <mach/vm_param.h>.
2020-12-23Remove trailing white spaces in gdb/frame.{c,h}Shahab Vahedi3-8/+13
gdb/ChangeLog: * frame.c: Remove trailing white spaces. * frame.h: Likewise.
2020-12-22arc: Make variable name in comments uppercaseShahab Vahedi2-2/+6
The word "regnum" in comments should be uppercase, because it reflects a variable name in the code. gdb/ChangeLog * arc-linux-tdep.c: Replace "regnum" with "REGNUM" in comments.
2020-12-22gdb: Add native support for ARC in GNU/LinuxAnton Kolesov5-0/+335
With this patch in place it is possible to build a GDB that can run on ARC (GNU/Linux) hosts for debugging ARC targets. The "arc-linux-nat.c" is a rather small one that mostly deals with registers and a few thread related hooks. v2 [1]: - Remove "void" from the input of "_initialize_arc_linux_nat ()" [1] Tom's remark after the first patch https://sourceware.org/pipermail/gdb-patches/2020-November/173223.html gdb/ChangeLog: * Makefile.in (ALLDEPFILES): Add arc-linux-nat.c. * configure.host (host to gdb names): Add arc*-*-linux*. * configure.nat (gdb_host_cpu): Add arc. * arc-linux-nat.c: New.
2020-12-22arc: Take into account the REGNUM in supply/collect gdb hooksShahab Vahedi2-9/+38
All the arc_linux_supply_*() target operations and the arc_linux_collect_v2_regset() in arc-linux-tdep.c were supplying/collecting all the registers in regcache as if the REGNUM was set to -1. The more efficient behavior is to examine the REGNUM and act accordingly. That is what this patch does. gdb/ChangeLog: * arc-linux-tdep.c (supply_register): New. (arc_linux_supply_gregset, arc_linux_supply_v2_regset, arc_linux_collect_v2_regset): Consider REGNUM.
2020-12-22arc: Add support for signal frames for Linux targetsAnton Kolesov2-0/+188
Implement functions needed to unwind signal frames on ARC Linux targets. gdb/ChangeLog * arc-linux-tdep.c (arc_linux_sc_reg_offsets): New static variable. (arc_linux_is_sigtramp): New function. (arc_linux_sigcontext_addr): Likewise. (arc_linux_init_osabi): Use them.
generated by cgit v1.1 at 2024-10-12 14:00:34 +0000