Mailing List Archive

[Bug 2931] Incorrect test against OPENSSL_VERSION_NUMBER

Ahmed Sayeed <> changed:

What |Removed |Added
CC| |

--- Comment #4 from Ahmed Sayeed <> ---
$ ./gdb -nx -q --data-directory=data-directory ~/a.out -ex "set confirm
off" -ex "file -readnow ~/a.out"
Reading symbols from /home/simark/a.out...
Reading symbols from ~/a.out...
internal-error: void create_all_comp_units(dwarf2_per_objfile*):
Assertion `per_objfile->per_bfd-
>all_comp_units.empty ()' failed.

This is a recurring problem that exposes a design issue in the DWARF
per-BFD sharing feature. Things work well when loading a binary
the same method (with/without index, with/without readnow) twice in a
row. But they don't work so well when loading a binary with
methods. See this previous fix, for example:

efb763a5ea35 ("gdb: check for partial symtab presence in

That one handled the case where the first load is normal (uses
symbols) and the second load uses an index.

The problem is that when loading an objfile with a method A, we
create a
dwarf2_per_bfd and some dwarf2_per_cu_data and initialize them with
data belonging to that method. When loading another obfile sharing
same BFD but with a different method B, it's not clear how to re-use
dwarf2_per_bfd/dwarf2_per_cu_data previously created, because they
contain the data specific to method A.

I think the most sensible fix would be to not share a
between two objfiles loaded with different methods. That means
that two
objfiles sharing the same BFD and loaded the same
way would share a
dwarf2_per_bfd. Two objfiles sharing the same BFD but loaded with
different methods would use two different dwarf2_per_bfd
However, this isn't a trivial change. So to fix the known issue
(including in the gdb 10 branch), this patch just disables all
dwarf2_per_bfd sharing for objfiles using READNOW.

Generalize the gdb.base/index-cache-load-twice.exp test to test all
the possible combinations of loading a file with partial symtabs,
and readnow. Move it to gdb.dwarf2, since it really
exercises features
of the DWARF reader.

You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.
openssh-bugs mailing list