git.ipfire.org Git - thirdparty/binutils-gdb.git/log

Set GDB version number to 8.2.1.

gdb/ChangeLog:

* version.in: Set GDB version number to 8.2.1.
* PROBLEMS: Likewise.

Automatic date update in version.in

gdb: Fix "info os <unknown>" command

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.

Automatic date update in version.in

Fix SYMBOL_LANGUAGE assertion failure on AIX.

PR gdb/23999
* xcoffread.c (read_xcoff_symtab): Pass deduced language to
symtab_start instead of always using language_unknown.

Automatic date update in version.in

Fix dwarf2read.c:dwarf2_find_containing_comp_unit's binary search

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.

Automatic date update in version.in

Make command-repeat work after gdb.execute

Since commit

56bcdbea2bed ("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.

Automatic date update in version.in

gdb.base/warning.exp tweaks

#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.

Avoid crash when calling warning too early

I noticed that if you pass the name of an existing file (not a
directory) as the argument to --data-directory, gdb will crash:

    $ ./gdb -nx  --data-directory  ./gdb
    ../../binutils-gdb/gdb/target.c:590:56: runtime error: member call on null pointer of type 'struct target_ops'

This was later reported as PR gdb/23838.

This happens because warning ends up calling
target_supports_terminal_ours, which calls current_top_target, which
returns nullptr this early.

This fixes the problem by handling this case specially in
target_supports_terminal_ours.  I also changed
target_supports_terminal_ours to return bool.

2018-11-08  Tom Tromey  <tom@tromey.com>

PR gdb/23555:
PR gdb/23838:
* target.h (target_supports_terminal_ours): Return bool.
* target.c (target_supports_terminal_ours): Handle case where
current_top_target returns nullptr.  Return bool.

gdb/testsuite/ChangeLog
2018-11-08  Tom Tromey  <tom@tromey.com>

PR gdb/23555:
PR gdb/23838:
* gdb.base/warning.exp: New file.

Automatic date update in version.in