In python 3, itertools is a builtin module, so whether or not the
python you link against is a shared or a static one, importing it
works.
Change the import test to use ctypes which is a dynamic module in both
python 2 and 3.
gdb/ChangeLog:
PR python/26832
* configure: Regenerate.
* configure.ac: Check for python modules ctypes instead of
itertools.
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.
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.
Fix a regression introduced by commit 7188ed02d2 ("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 7188ed02d2, 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
This fixes a regression introduced by the following commit:
fe053b9e85 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.
