aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-10-24Bump GDB version number to 10.1.90.DATE-git.Joel Brobecker4-2/+10
gdb/ChangeLog: * version.in: Set GDB version number to 10.1.90.DATE-git. gdb/testsuite/ChangeLog: * gdb.base/default.exp: Change $_gdb_minor to 2.
2020-10-24Document the GDB 10.1 release in gdb/ChangeLogJoel Brobecker1-0/+4
gdb/ChangeLog: GDB 10.1 released.
2020-10-24Set GDB version number to 10.1.gdb-10.1-releaseJoel Brobecker2-1/+5
gdb/ChangeLog: * version.in: Set GDB version number to 10.1.
2020-10-24Automatic date update in version.inGDB Administrator1-1/+1
2020-10-23Automatic date update in version.inGDB Administrator1-1/+1
2020-10-22Don't create _Complex type name if there is no target type nameHannes Domani2-1/+5
This causes gdb to crash in strlen. Happens if init_complex_type is called for a type created by dbx_init_float_type in stabsread.c. gdb/ChangeLog: 2020-10-22 Hannes Domani <ssbssa@yahoo.de> * gdbtypes.c (init_complex_type): Check target type name.
2020-10-22opcodes/csky: return the default disassembler when there is no bfdAndrew Burgess2-15/+22
The disassembler function should return a valid disassembler function even when there is no BFD present. This is implied (I believe) by the comment in dis-asm.h which says the BFD may be NULL. Further, it makes sense when considering that the disassembler is used in GDB, and GDB may connect to a target and perform debugging even without a BFD being supplied. This commit makes the csky_get_disassembler function return the default disassembler configuration when no bfd is supplied, this is the same default configuration as is used when a BFD is supplied, but the BFD has no attributes section. Before the change configuring GDB with --enable-targets=all and running the tests gdb.base/all-architectures-2.exp results in many errors, but after this change there are no failures. opcodes/ChangeLog: * csky-dis.c (csky_get_disassembler): Don't return NULL when there is no BFD.
2020-10-22gdb/dwarf: fix reading subprogram with DW_AT_specification (PR gdb/26693)Simon Marchi4-6/+107
Fix a regression introduced by commit 7188ed02d2a7 ("Replace dwarf2_per_cu_data::cu backlink with per-objfile map"). This patch targets both master and gdb-10-branch, since this is a regression from GDB 9. Analysis -------- The DWARF generated by the included test case looks like: 0x0000000b: DW_TAG_compile_unit DW_AT_language [DW_FORM_sdata] (4) 0x0000000d: DW_TAG_base_type DW_AT_name [DW_FORM_string] ("int") DW_AT_byte_size [DW_FORM_data1] (0x04) DW_AT_encoding [DW_FORM_sdata] (5) 0x00000014: DW_TAG_subprogram DW_AT_name [DW_FORM_string] ("apply") 0x0000001b: DW_TAG_subprogram DW_AT_specification [DW_FORM_ref4] (0x00000014 "apply") DW_AT_low_pc [DW_FORM_addr] (0x0000000000001234) DW_AT_high_pc [DW_FORM_data8] (0x0000000000000020) 0x00000030: DW_TAG_template_type_parameter DW_AT_name [DW_FORM_string] ("T") DW_AT_type [DW_FORM_ref4] (0x0000000d "int") 0x00000037: NULL 0x00000038: NULL Simply loading the file in GDB makes it crash: $ ./gdb -nx --data-directory=data-directory testsuite/outputs/gdb.dwarf2/pr26693/pr26693 [1] 15188 abort (core dumped) ./gdb -nx --data-directory=data-directory The crash happens here, where htab (a dwarf2_cu::die_hash field) is unexpectedly NULL while generating partial symbols: #0 0x000055555fa28188 in htab_find_with_hash (htab=0x0, element=0x7fffffffbfa0, hash=27) at /home/simark/src/binutils-gdb/libiberty/hashtab.c:591 #1 0x000055555cb4eb2e in follow_die_offset (sect_off=(unknown: 27), offset_in_dwz=0, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22951 #2 0x000055555cb4edfb in follow_die_ref (src_die=0x0, attr=0x7fffffffc130, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22968 #3 0x000055555caa48c5 in partial_die_full_name (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8441 #4 0x000055555caa4d79 in add_partial_symbol (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8469 #5 0x000055555caa7d8c in add_partial_subprogram (pdi=0x621000157e70, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8737 #6 0x000055555caa265c in scan_partial_symbols (first_die=0x621000157e00, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8230 #7 0x000055555ca98e3f in process_psymtab_comp_unit_reader (reader=0x7fffffffc6b0, info_ptr=0x60600009650d "\003int", comp_unit_die=0x621000157d10, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7614 #8 0x000055555ca9aa2c in process_psymtab_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, want_partial_unit=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7712 #9 0x000055555caa051a in dwarf2_build_psymtabs_hard (per_objfile=0x613000009f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8073 The special thing about this DWARF is that the subprogram at 0x1b is a template specialization described with DW_AT_specification, and has no DW_AT_name in itself. To compute the name of this subprogram, partial_die_full_name needs to load the full DIE for this partial DIE. The name is generated from the templated function name and the actual tempalate parameter values of the specialization. To load the full DIE, partial_die_full_name creates a dummy DWARF attribute of form DW_FORM_ref_addr that points to our subprogram's DIE, and calls follow_die_ref on it. This eventually causes load_full_comp_unit to be called for the exact same CU we are currently making partial symbols for: #0 load_full_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, skip_partial=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:9238 #1 0x000055555cb4e943 in follow_die_offset (sect_off=(unknown: 27), offset_in_dwz=0, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22942 #2 0x000055555cb4edfb in follow_die_ref (src_die=0x0, attr=0x7fffffffc130, ref_cu=0x7fffffffc110) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:22968 #3 0x000055555caa48c5 in partial_die_full_name (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8441 #4 0x000055555caa4d79 in add_partial_symbol (pdi=0x621000157e70, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8469 #5 0x000055555caa7d8c in add_partial_subprogram (pdi=0x621000157e70, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8737 #6 0x000055555caa265c in scan_partial_symbols (first_die=0x621000157e00, lowpc=0x7fffffffc5c0, highpc=0x7fffffffc5e0, set_addrmap=1, cu=0x615000023f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8230 #7 0x000055555ca98e3f in process_psymtab_comp_unit_reader (reader=0x7fffffffc6b0, info_ptr=0x60600009650d "\003int", comp_unit_die=0x621000157d10, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7614 #8 0x000055555ca9aa2c in process_psymtab_comp_unit (this_cu=0x621000155510, per_objfile=0x613000009f80, want_partial_unit=false, pretend_language=language_minimal) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:7712 #9 0x000055555caa051a in dwarf2_build_psymtabs_hard (per_objfile=0x613000009f80) at /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8073 load_full_comp_unit creates a cutu_reader for the CU. Since a dwarf2_cu object already exists for the CU, load_full_comp_unit is expected to find it and pass it to cutu_reader, so that cutu_reader doesn't create a new dwarf2_cu for the CU. And this is the difference between before and after the regression. Before commit 7188ed02d2a7, the dwarf2_per_cu_data -> dwarf2_cu link was a simple pointer in dwarf2_per_cu_data. This pointer was set up when starting the read the partial symbols. So it was already available at that point where load_full_comp_unit gets called. Post-7188ed02d2a7, this link is per-objfile, kept in the dwarf2_per_objfile::m_dwarf2_cus hash map. The entry is only put in the hash map once the partial symbols have been successfully read, when cutu_reader::keep is called. Therefore, it is _not_ set at the point load_full_comp_unit is called. As a consequence, a new dwarf2_cu object gets created and initialized by load_full_comp_unit (including initializing that dwarf2_cu::die_hash field). Meanwhile, the dwarf2_cu object created and used by the callers up the stack does not get initialized for full symbol reading, and the dwarf2_cu::die_hash field stays unexpectedly NULL. Solution -------- Since the caller of load_full_comp_unit knows about the existing dwarf2_cu object for the CU we are reading (the one load_full_comp_unit is expected to find), we can simply make it pass it down, instead of having load_full_comp_unit look up the per-objfile map. load_full_comp_unit therefore gets a new `existing_cu` parameter. All other callers get updated to pass `per_objfile->get_cu (per_cu)`, so the behavior shouldn't change for them, compared to the current HEAD. A test is added, which is the bare minimum to reproduce the issue. Notes ----- The original problem was reproduced by downloading https://github.com/oneapi-src/oneTBB/releases/download/v2020.3/tbb-2020.3-lin.tgz and loading libtbb.so in GDB. This code was compiled with the Intel C/C++ compiler. I was not able to reproduce the issue using GCC, I think because GCC puts a DW_AT_name in the specialized subprogram, so there's no need for partial_die_full_name to load the full DIE of the subprogram, and the faulty code doesn't execute. gdb/ChangeLog: PR gdb/26693 * dwarf2/read.c (load_full_comp_unit): Add existing_cu parameter. (load_cu): Pass existing CU. (process_imported_unit_die): Likewise. (follow_die_offset): Likewise. gdb/testsuite/ChangeLog: PR gdb/26693 * gdb.dwarf2/template-specification-full-name.exp: New test. Change-Id: I57c8042f96c45f15797a3848e4d384181c56bb44
2020-10-22Automatic date update in version.inGDB Administrator1-1/+1
2020-10-21Automatic date update in version.inGDB Administrator1-1/+1
2020-10-20Automatic date update in version.inGDB Administrator1-1/+1
2020-10-19gdb: get jiter objfile from a bound minsymMihails Strasuns2-8/+16
This fixes a regression introduced by the following commit: fe053b9e853 gdb/jit: pass the jiter objfile as an argument to jit_event_handler In the refactoring `handle_jit_event` function was changed to pass a matching objfile pointer to the `jit_event_handler` explicitly, rather using internal storage: ``` --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -5448,8 +5448,9 @@ handle_jit_event (void) frame = get_current_frame (); gdbarch = get_frame_arch (frame); + objfile *jiter = symbol_objfile (get_frame_function (frame)); - jit_event_handler (gdbarch); + jit_event_handler (gdbarch, jiter); ``` This was needed to add support for multiple jiters. However it has also introduced a regression, because `get_frame_function (frame)` here may return `nullptr`, resulting in a crash. A more resilient way would be to use an approach mirroring `jit_breakpoint_re_set` - to find a minimal symbol matching the breakpoint location and use its object file. We know that this breakpoint event comes from a breakpoint set by `jit_breakpoint_re_set`, thus using the reverse approach should be reliable enough. gdb/Changelog: 2020-10-14 Mihails Strasuns <mihails.strasuns@intel.com> * breakpoint.c (handle_jit_event): Add an argument, change how `jit_event_handler` is called.
2020-10-19Automatic date update in version.inGDB Administrator1-1/+1
2020-10-18Automatic date update in version.inGDB Administrator1-1/+1
2020-10-17Automatic date update in version.inGDB Administrator1-1/+1
2020-10-16Automatic date update in version.inGDB Administrator1-1/+1
2020-10-15Automatic date update in version.inGDB Administrator1-1/+1
2020-10-14Automatic date update in version.inGDB Administrator1-1/+1
2020-10-13gdb: don't pass TARGET_WNOHANG to targets that can't async (PR 26642)Simon Marchi6-1/+88
Debugging with "maintenance set target-async off" on Linux has been broken since 5b6d1e4fa4f ("Multi-target support"). The issue is easy to reproduce: $ ./gdb -q --data-directory=data-directory -nx ./test Reading symbols from ./test... (gdb) maintenance set target-async off (gdb) start Temporary breakpoint 1 at 0x1151: file test.c, line 5. Starting program: /home/simark/build/binutils-gdb/gdb/test ... and it hangs there. The difference between pre-5b6d1e4fa4f and 5b6d1e4fa4f is that fetch_inferior_event now calls target_wait with TARGET_WNOHANG for non-async-capable targets, whereas it didn't before. For non-async-capable targets, this is how it's expected to work when resuming execution: 1. we call resume 2. the infrun async handler is marked in prepare_to_wait, to immediately wake up the event loop when we get back to it 3. fetch_inferior_event calls the target's wait method without TARGET_WNOHANG, effectively blocking until the target has something to report However, since we call the target's wait method with TARGET_WNOHANG, this happens: 1. we call resume 2. the infrun async handler is marked in prepare_to_wait, to immediately wake up the event loop when we get back to it 3. fetch_inferior_event calls the target's wait method with TARGET_WNOHANG, the target has nothing to report yet 4. we go back to blocking on the event loop 5. SIGCHLD finally arrives, but the event loop is not woken up, because we are not in async mode. Normally, we should have been stuck in waitpid the SIGCHLD would have unblocked us. We end up in this situation because these two necessary conditions are met: 1. GDB uses the TARGET_WNOHANG option with a target that can't do async. I don't think this makes sense. I mean, it's technically possible, the doc for TARGET_WNOHANG is: /* Return immediately if there's no event already queued. If this options is not requested, target_wait blocks waiting for an event. */ TARGET_WNOHANG = 1, ... which isn't in itself necessarily incompatible with synchronous targets. It could be possible for a target to support non-blocking polls, while not having a way to asynchronously wake up the event loop, which is also necessary to support async. But as of today, we don't expect GDB and sync targets to work this way. 2. The linux-nat target, even in the mode where it emulates a synchronous target (with "maintenance set target-async off") respects TARGET_WNOHANG. Other non-async targets, such as windows_nat_target, simply don't check / support TARGET_WNOHANG, so their wait method is always blocking. Fix the first issue by avoiding using TARGET_WNOHANG on non-async targets, in do_target_wait_1. Add an assert in target_wait to verify it doesn't happen. The new test gdb.base/maint-target-async-off.exp is a simple test that just tries running to main and then to the end of the program, with "maintenance set target-async off". gdb/ChangeLog: PR gdb/26642 * infrun.c (do_target_wait_1): Clear TARGET_WNOHANG if the target can't do async. * target.c (target_wait): Assert that we don't pass TARGET_WNOHANG to a target that can't async. gdb/testsuite/ChangeLog: PR gdb/26642 * gdb.base/maint-target-async-off.c: New test. * gdb.base/maint-target-async-off.exp: New test. Change-Id: I69ad3a14598863d21338a8c4e78700a58ce7ad86
2020-10-13Automatic date update in version.inGDB Administrator1-1/+1
2020-10-12Automatic date update in version.inGDB Administrator1-1/+1
2020-10-11Automatic date update in version.inGDB Administrator1-1/+1
2020-10-10Automatic date update in version.inGDB Administrator1-1/+1
2020-10-09gnulib: fix stat/fstat build errors on old Windows version or using old MinGWJoel Brobecker9-8/+229
This commit imports two commits from gnulib's master branch fixing a build error when building on a version of Windows that's older than Vista, or when using an mingw's MinGW. gnulib/ChangeLog: GDB PR build/26607 * patches/0002-stat-fstat-windows-older-vista: New patch. * patches/0003-stat-fstat-windows-old-mingw: New patch. * update-gnulib.sh: Update to use the two new patches above. * import/m4/fstat.m4: Update after applying patches above. * import/m4/stat.m4: Ditto. * import/stat-w32.c: Ditto. * config.in: Regenerate. * configure: Regenerate.
2020-10-09Automatic date update in version.inGDB Administrator1-1/+1
2020-10-08Update GDB NEWS with ARC support in GDBserverShahab Vahedi2-0/+6
gdb/ChangeLog: * NEWS: Mention ARC support in GDBserver.
2020-10-08Automatic date update in version.inGDB Administrator1-1/+1
2020-10-07arc: Add support for Linux coredump filesAnton Kolesov5-4/+270
With the implemenations in this patch, ARC gdb can handle coredump related matters. The binutils counter part of this patch has already been pushed [1]. v2 [2]: - arc_linux_collect_gregset: Use "reg <= ARC_LAST_REGNUM" instead of "reg < ARC_LAST_REGNUM" for the condition check of the for-loop. - arc-linux-tdep.c: Use "ARC_LAST_REGNUM < ARRAY_SIZE (...)" instead of "ARC_LAST_REGNUM <= ARRAY_SIZE (...)" for the "asserts". - Use "buf + arc_linux_core_reg_offsets[ARC_ERET_REGNUM]" instead of "buf + REG_OFF (6)". - Fix a few typos/indentation. v3 [3]: - Use gdb_assert_not_reached(text) instead of gdb_assert (!text). - Remove unnecessary braces in the for loop. [1] arc: Add support for ARC HS extra registers in core files https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2745674244d6aecddcf636475034bdb9c0a6b4a0 [2] First remarks https://sourceware.org/pipermail/gdb-patches/2020-September/171912.html [3] Second remarks https://sourceware.org/pipermail/gdb-patches/2020-October/172302.html gdb/ChangeLog: * arc-linux-tdep.h: New file. * arc-linux-tdep.c (arc_linux_core_reg_offsets, arc_linux_supply_gregset, arc_linux_supply_v2_regset, arc_linux_collect_gregset, arc_linux_collect_v2_regset, arc_linux_gregset, arc_linux_v2_regset, arc_linux_iterate_over_regset_sections, arc_linux_core_read_description): Implement. (arc_linux_init_osabi): Set iterate_over_regset_sections. * arc-tdep.h (ARC_OFFSET_NO_REGISTER): Declare. (arc_gdbarch_features_create): Add. * arc-tdep.c (arc_gdbarch_features_create): Not static anymore.
2020-10-07gdb/gdbserver: Add the missing ChangeLog entriesShahab Vahedi2-0/+13
I forgot to add the ChangeLog entries for these 2 patches: b13599da1ae gdbserver: Add GNU/Linux support for ARC e26d3e9b761 arc: Rename "arc_gdbarch_features" struct
2020-10-07gdbserver: Add GNU/Linux support for ARCAnton Kolesov3-0/+431
This gdbserver implementation supports ARC ABI v3 and v4 (older ARC ABI versions are not supported by other modern GNU tools or Linux itself). Gdbserver supports inspection of ARC HS registers R30, R58 and R59 - feature that has been added to Linux 4.12. Whether gdbserver build will actually support this feature depends on the version of Linux headers used to build the server. v2 [1]: - Use "this->read_memory ()" instead of "the_target->read_memory ()". - Remove the unnecessary "arch-arc.o:" target from the "Makefile.in". - Got rid of "ntohs()" function and added lots of comments about endianness. - Clarify why "pc" value is read from and saved to different fields in user regs struct. - In function "is_reg_name_available_p()", use a range-based iterator to loop over the registers. - Removed mentioning of issue number that was not related to sourceware. - A few typo's fixed. [1] Remarks https://sourceware.org/pipermail/gdb-patches/2020-September/171911.html https://sourceware.org/pipermail/gdb-patches/2020-September/171919.html gdbserver/ChangeLog: * configure.srv: Support ARC architecture. * Makefile.in: Add linux-arc-low.cc and arch/arc.o. * linux-arc-low.cc: New file.
2020-10-07arc: Rename "arc_gdbarch_features" structShahab Vahedi3-19/+19
"arc_gdbarch_features" is a data structure containing information about the ARC architecture: ISA version, register size, etc. This name is misleading, because although it carries the phrase "gdbarch", it has nothing to do with the type/interface in GDB. Traditionaly, "gdbarch" structures are only used for that purpose. To rectify this, this patch changes the name to "arc_arch_features". gdb/ChangeLog: * arch/arc.h: Rename "arc_gdbarch_features" to "arc_arch_features". * arc-tdep.h: Likewise. * arc-tdep.c: Likewise.
2020-10-07Automatic date update in version.inGDB Administrator1-1/+1
2020-10-06Automatic date update in version.inGDB Administrator1-1/+1
2020-10-05Automatic date update in version.inGDB Administrator1-1/+1
2020-10-04Automatic date update in version.inGDB Administrator1-1/+1
2020-10-03Automatic date update in version.inGDB Administrator1-1/+1
2020-10-02Automatic date update in version.inGDB Administrator1-1/+1
2020-10-01Automatic date update in version.inGDB Administrator1-1/+1
2020-09-30Automatic date update in version.inGDB Administrator1-1/+1
2020-09-29Automatic date update in version.inGDB Administrator1-1/+1
2020-09-28gdb: Fix from_tty argument to gdb.execute in Python.Gareth Rees4-4/+32
Prior to commit 56bcdbea2b, the from_tty keyword argument to the Python function gdb.execute controlled whether the command took input from the terminal. When from_tty=True, "starti" and similar commands prompted the user: (gdb) python gdb.execute("starti", from_tty=True) The program being debugged has been started already. Start it from the beginning? (y or n) y Starting program: /bin/true Program stopped. When from_tty=False, these commands did not prompt the user, and "yes" was assumed: (gdb) python gdb.execute("starti", from_tty=False) Program stopped. However, after commit 56bcdbea2b, the from_tty keyword argument no longer had this effect. For example, as of commit 7ade7fba75: (gdb) python gdb.execute("starti", from_tty=True) The program being debugged has been started already. Start it from the beginning? (y or n) [answered Y; input not from terminal] Starting program: /bin/true Program stopped. Note the "[answered Y; input not from terminal]" in the output even though from_tty=True was requested. Looking at commit 56bcdbea2b, it seems that the behaviour of the from_tty argument was changed accidentally. The commit message said: Let gdb.execute handle multi-line commands This changes the Python API so that gdb.execute can now handle multi-line commands, like "commands" or "define". and there was no mention of changing the effect of the from_tty argument. It looks as though the code for setting the instream to nullptr was accidentally moved from execute_user_command() to execute_control_commands() along with the other scoped restores. Accordingly, the simplest way to fix this is to partially reverse commit 56bcdbea2b by moving the code for setting the instream to nullptr back to execute_user_command() where it was to begin with. Additionally, add a test case to reduce the risk of similar breakage in future. gdb/ChangeLog: PR python/26586 * cli/cli-script.c (execute_control_commands): don't set instream to nullptr here as this breaks the from_tty argument to gdb.execute in Python. (execute_user_command): set instream to nullptr here instead. gdb/testsuite/ChangeLog: PR python/26586 * gdb.python/python.exp: add test cases for the from_tty argument to gdb.execute. (cherry picked from commit 8f9929bb97dc0f0fdf60269ac8c9a7d50746646f)
2020-09-28Automatic date update in version.inGDB Administrator1-1/+1
2020-09-27Automatic date update in version.inGDB Administrator1-1/+1
2020-09-26Automatic date update in version.inGDB Administrator1-1/+1
2020-09-25gdb/breakpoint: make a copy of the "commands" command's argumentTankut Baris Aktemur6-1/+103
When GDB reads commands from the input, its internal buffer is re-used for each line. This is usually just fine because commands are executed in order; by the time we read the next line, we are already done with the current line. However, a problematic case is breakpoint commands that are input from a script. The header (e.g. commands 1 2) is overwritten with the next line before the breakpoint numbers are processed completely. For example, suppose we have the following script: break main break main commands 1 2 print 100123 end and source this script: (gdb) source script.gdb Breakpoint 1 at 0x1245: file main.cpp, line 27. Breakpoint 2 at 0x1245: file main.cpp, line 27. No breakpoint number 123. Note the "No breakpoint number 123." error message. This happens because GDB first reads "commands 1 2" into its internal buffer buffer -> "commands 1 2" and then starts parsing the breakpoint numbers. After parsing the first token, the "next token" pointer is as below: buffer -> "commands 1 2" next-token -----------^ So, if we continue parsing, we would tokenize "2" correctly. However, before parsing the next number, GDB reads the commands to attach them to breakpoint 1. Reading the commands causes the buffer to be overwritten: buffer -> " print 100123" next-token -----------^ So, the next time we parse the breakpoint number, we read "123". To fix, simply create a copy of the arguments of the header. gdb/ChangeLog: 2020-09-25 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * breakpoint.c (commands_command_1): Make a copy of the 'arg' argument. gdb/testsuite/ChangeLog: 2020-09-25 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> * gdb.base/bp-cmds-sourced-script.c: New file. * gdb.base/bp-cmds-sourced-script.exp: New test. * gdb.base/bp-cmds-sourced-script.gdb: New file.
2020-09-25Automatic date update in version.inGDB Administrator1-1/+1
2020-09-24Don't let TUI focus on locatorTom Tromey6-8/+52
PR tui/26638 notes that the C-x o binding can put the focus on the locator window. However, this is not useful and did not happen historically. This patch changes the TUI to skip this window when switching focus. 2020-09-24 Tom Tromey <tromey@adacore.com> PR tui/26638: * tui/tui-stack.h (struct tui_locator_window) <can_focus>: New method. * tui/tui-data.h (struct tui_win_info) <can_focus>: New method. * tui/tui-data.c (tui_next_win): Exclude non-focusable windows. (tui_prev_win): Rewrite. gdb/testsuite/ChangeLog 2020-09-24 Tom Tromey <tromey@adacore.com> PR tui/26638: * gdb.tui/list.exp: Check output of "focus next".
2020-09-24Handle 64bit breakpoints of WOW64 processes as SIGINTHannes Domani7-9/+29
When a WOW64 process triggers a breakpoint exception in 64bit code (which happens when a 64bit gdb calls DebugBreakProcess for a 32bit target), gdb ignores the breakpoint (because Wow64GetThreadContext can only report the pc of 32bit code, and there is not int3 at this location). But if these 64bit breakpoint exceptions are handled as SIGINT, gdb doesn't check for int3, and always stops the target. gdb/ChangeLog: 2020-09-23 Hannes Domani <ssbssa@yahoo.de> * nat/windows-nat.c (handle_exception): Handle 64bit breakpoints in WOW64 processes as SIGINT. * nat/windows-nat.h: Make wow64_process a shared variable. * windows-nat.c: Remove static wow64_process variable. gdbserver/ChangeLog: 2020-09-23 Hannes Domani <ssbssa@yahoo.de> * win32-low.cc: Remove local wow64_process variable. * win32-low.h: Remove local wow64_process variable.
2020-09-24Automatic date update in version.inGDB Administrator1-1/+1
2020-09-23Automatic date update in version.inGDB Administrator1-1/+1
generated by cgit v1.1 at 2025-09-19 17:05:31 +0000