- 24 Oct, 2020 2 commits
-
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 10.1.
-
GDB Administrator authored
-
- 23 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 22 Oct, 2020 4 commits
-
-
Hannes Domani authored
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.
-
Andrew Burgess authored
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.
-
Simon Marchi authored
Fix a regression introduced by commit 7188ed02 ("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 7188ed02, 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-7188ed02, 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
-
GDB Administrator authored
-
- 21 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 20 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 19 Oct, 2020 2 commits
-
-
Mihails Strasuns authored
This fixes a regression introduced by the following commit: fe053b9e 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.
-
GDB Administrator authored
-
- 18 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 17 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 16 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 15 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 14 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 13 Oct, 2020 2 commits
-
-
Simon Marchi authored
Debugging with "maintenance set target-async off" on Linux has been broken since 5b6d1e4f ("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-5b6d1e4f and 5b6d1e4f 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
-
GDB Administrator authored
-
- 12 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 11 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 10 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 09 Oct, 2020 2 commits
-
-
Joel Brobecker authored
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.
-
GDB Administrator authored
-
- 08 Oct, 2020 2 commits
-
-
Shahab Vahedi authored
gdb/ChangeLog: * NEWS: Mention ARC support in GDBserver.
-
GDB Administrator authored
-
- 07 Oct, 2020 5 commits
-
-
Anton Kolesov authored
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.
-
Shahab Vahedi authored
I forgot to add the ChangeLog entries for these 2 patches: b13599da gdbserver: Add GNU/Linux support for ARC e26d3e9b arc: Rename "arc_gdbarch_features" struct
-
Anton Kolesov authored
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.
-
Shahab Vahedi authored
"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.
-
GDB Administrator authored
-
- 06 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 05 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 04 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 03 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 02 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 01 Oct, 2020 1 commit
-
-
GDB Administrator authored
-
- 30 Sep, 2020 1 commit
-
-
GDB Administrator authored
-
- 29 Sep, 2020 1 commit
-
-
GDB Administrator authored
-
- 28 Sep, 2020 2 commits
-
-
Gareth Rees authored
Prior to commit 56bcdbea, 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 56bcdbea, the from_tty keyword argument no longer had this effect. For example, as of commit 7ade7fba: (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 56bcdbea, 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 56bcdbea 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 8f9929bb)
-
GDB Administrator authored
-