- 23 Dec, 2018 2 commits
-
-
Joel Brobecker authored
gdb/ChangeLog: * version.in: Set GDB version number to 8.2.1. * PROBLEMS: Likewise.
-
GDB Administrator authored
-
- 22 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 21 Dec, 2018 2 commits
-
-
Paul Marechal authored
Running `info os someUnknownOsType` is crashing when gdb is built with -D_GLIBCXX_DEBUG: /usr/include/c++/5/debug/vector:439:error: attempt to access an element in an empty container. In target_read_stralloc from target.c, the call to target_read_alloc_1 can return an empty vector, we then call vector::back on this vector, which is invalid. This commit adds a check for emptiness before trying to call vector::back on it. It also adds test to check for `info os <unknown>` to return the proper error message. This is a regression in gdb 8.2 and this patch restores the behavior of previous versions. gdb/ChangeLog: PR gdb/23974 * target.c (target_read_stralloc): Check for empty vector. gdb/testsuite/ChangeLog: PR gdb/23974 * gdb.base/info-os.exp: Check return for unknown "info os" type.
-
GDB Administrator authored
-
- 20 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 19 Dec, 2018 2 commits
-
-
Sangamesh Mallayya authored
PR gdb/23999 * xcoffread.c (read_xcoff_symtab): Pass deduced language to symtab_start instead of always using language_unknown.
-
GDB Administrator authored
-
- 18 Dec, 2018 2 commits
-
-
Sergio Durigan Junior authored
First of all, I would like to express my gratitude to Keith Seitz, Jan Kratochvil and Tom Tromey, who were really kind and helped a lot with this bug. The patch itself was authored by Jan. This all began with: https://bugzilla.redhat.com/show_bug.cgi?id=1639242 py-bt is broken, results in exception In summary, the error reported by the bug above is: $ gdb -args python3 GNU gdb (GDB) Fedora 8.1.1-3.fc28 (...) Reading symbols from python3...Reading symbols from /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug...done. done. Dwarf Error: could not find partial DIE containing offset 0x316 [in module /usr/lib/debug/usr/bin/python3.6-3.6.6-1.fc28.x86_64.debug] After a long investigation, and after thinking that the problem might actually be on DWZ's side, we were able to determine that there's something wrong going on when dwarf2read.c:dwarf2_find_containing_comp_unit performs a binary search over all of the CUs belonging to an objfile in order to find the CU which contains a DIE at an specific offset. The current algorithm is: static struct dwarf2_per_cu_data * dwarf2_find_containing_comp_unit (sect_offset sect_off, unsigned int offset_in_dwz, struct dwarf2_per_objfile *dwarf2_per_objfile) { struct dwarf2_per_cu_data *this_cu; int low, high; const sect_offset *cu_off; low = 0; high = dwarf2_per_objfile->all_comp_units.size () - 1; while (high > low) { struct dwarf2_per_cu_data *mid_cu; int mid = low + (high - low) / 2; mid_cu = dwarf2_per_objfile->all_comp_units[mid]; cu_off = &mid_cu->sect_off; if (mid_cu->is_dwz > offset_in_dwz || (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off)) high = mid; else low = mid + 1; } For the sake of this example, let's consider that "sect_off = 0x7d". There are a few important things going on here. First, "dwarf2_per_objfile->all_comp_units ()" will be sorted first by whether the CU is a DWZ CU, and then by cu->sect_off. In this specific bug, "offset_in_dwz" is false, which means that, for the most part of the loop, we're going to do "high = mid" (i.e, we'll work with the lower part of the vector). In our particular case, when we reach the part where "mid_cu->is_dwz == offset_in_dwz" (i.e, both are false), we end up with "high = 2" and "mid = 1". I.e., there are only 2 elements in the vector who are not DWZ. The vector looks like this: #0: cu->sect_off = 0; length = 114; is_dwz = false <-- low #1: cu->sect_off = 114; length = 7796; is_dwz = false <-- mid #2: cu->sect_off = 0; length = 28; is_dwz = true <-- high ... The CU we want is #1, which is exactly where "mid" is. Also, #1 is not DWZ, which is also exactly what we want. So we perform the second comparison: (mid_cu->is_dwz == offset_in_dwz && *cu_off >= sect_off) ^^^^^^^^^^^^^^^^^^^ Because "*cu_off = 114" and "sect_off = 0x7d", this evaluates to false, so we end up with "low = mid + 1 = 2", which actually gives us the wrong CU (i.e., a CU that is DWZ). Next in the code, GDB does: gdb_assert (low == high); this_cu = dwarf2_per_objfile->all_comp_units[low]; cu_off = &this_cu->sect_off; if (this_cu->is_dwz != offset_in_dwz || *cu_off > sect_off) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ { if (low == 0 || this_cu->is_dwz != offset_in_dwz) error (_("Dwarf Error: could not find partial DIE containing " "offset %s [in module %s]"), sect_offset_str (sect_off), bfd_get_filename (dwarf2_per_objfile->objfile->obfd)); ... Triggering the error we saw in the original bug report. It's important to notice that we see the error message because the selected CU is a DWZ one, but we're looking for a non-DWZ CU here. However, even when the selected CU is *not* a DWZ (and we don't see any error message), we still end up with the wrong CU. For example, suppose that the vector had: #0: cu->sect_off = 0; length = 114; is_dwz = false #1: cu->sect_off = 114; length = 7796; is_dwz = false #2: cu->sect_off = 7910; length = 28; is_dwz = false ... I.e., #2's "is_dwz" is false instead of true. In this case, we still want #1, because that's where the DIE is located. After the loop ends up in #2, we have "is_dwz" as false, which is what we wanted, so we compare offsets. In this case, "7910 >= 0x7d", so we set "mid = high = 2". Next iteration, we have "mid = 0 + (2 - 0) / 2 = 1", and thus we examining #1. "is_dwz" is still false, but "114 >= 0x7d" also evaluates to false, so "low = mid + 1 = 2", which makes the loop stop. Therefore, we end up choosing #2 as our CU, even though #1 is the right one. The problem here is happening because we're comparing "sect_off" directly against "*cu_off", while we should actually be comparing against "*cu_off + mid_cu->length" (i.e., the end offset): ... || (mid_cu->is_dwz == offset_in_dwz && *cu_off + mid_cu->length >= sect_off)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... And this is what the patch does. The idea is that if GDB is searching for an offset that falls above the *end* of the CU being analyzed (i.e., "mid"), then the next iteration should try a higher-offset CU next. The previous algorithm was using the *beginning* of the CU. Unfortunately, I could not devise a testcase for this problem, so I am proposing a fix with this huge explanation attached to it in the hope that it is sufficient. After talking a bit to Keith (our testcase guru), it seems that one would have to create an objfile with both DWZ and non-DWZ sections, which may prove very hard to do, I think. I ran this patch on our BuildBot, and no regressions were detected. gdb/ChangeLog: 2018-11-30 Jan Kratochvil <jan.kratochvil@redhat.com> Keith Seitz <keiths@redhat.com> Tom Tromey <tom@tromey.com> Sergio Durigan Junior <sergiodj@redhat.com> https://bugzilla.redhat.com/show_bug.cgi?id=1613614 PR gdb/24003 * dwarf2read.c (dwarf2_find_containing_comp_unit): Add 'mid_cu->length' to '*cu_off' when checking if 'sect_off' is inside the CU.
-
GDB Administrator authored
-
- 17 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 16 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 15 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 14 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 13 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 12 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 11 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 10 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 09 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 08 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 07 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 06 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 05 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 04 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 03 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 02 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 01 Dec, 2018 1 commit
-
-
GDB Administrator authored
-
- 30 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 29 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 28 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 27 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 26 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 25 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 24 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 23 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 22 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 21 Nov, 2018 2 commits
-
-
Benno Fünfstück authored
Since commit 56bcdbea ("Let gdb.execute handle multi-line commands") command repetition after using the `gdb.execute` Python function fails (the previous command is not repeated anymore). This happens because read_command_lines_1 sets dont_repeat, but the call to prevent_dont_repeat in execute_gdb_command is later. The fix is to move the call to prevent_dont_repeat to the beginning of the function. Tested on my laptop (ArchLinux-x86_64). gdb/ChangeLog: PR python/23714 * gdb/python/python.c (execute_gdb_command): Call prevent_dont_repeat earlier to avoid affecting dont_repeat. gdb/testuite/ChangeLog: PR python/23714 * gdb.python/python.exp: Test command repetition after gdb.execute.
-
GDB Administrator authored
-
- 20 Nov, 2018 1 commit
-
-
GDB Administrator authored
-
- 19 Nov, 2018 1 commit
-
-
Pedro Alves authored
#1- Check that the warning is emitted. #2- Avoid overriding INTERNAL_GDBFLAGS, as per documentated in gdb/testsuite/README: ~~~ The testsuite does not override a value provided by the user. ~~~ We don't actually need to tweak INTERNAL_GDBFLAGS, we just need to append out -data-directory to GDBFLAGS, because each passed -data-directory option leads to a call to the warning: $ ./gdb -data-directory=foo -data-directory=bar Warning: foo: No such file or directory. Warning: bar: No such file or directory. [...] 2018-11-19 Pedro Alves <palves@redhat.com> * gdb.base/warning.exp: Don't override INTERNAL_FLAGS. Use gdb_spawn_with_cmdline_opts instead of gdb_start. Check that we see the expected warning.
-