aboutsummaryrefslogtreecommitdiff
path: root/gdb/compile/compile-object-run.c
diff options
context:
space:
mode:
authorTom Tromey <tromey@adacore.com>2019-10-08 14:35:24 -0600
committerTom Tromey <tromey@adacore.com>2019-10-25 08:29:44 -0600
commit93878f471745364756b9bad753c5052614fbcd7e (patch)
treef5a973353f040fb4dad40b80c5225eb24c9a5c23 /gdb/compile/compile-object-run.c
parent52c64cf72d40aace2d2fedca32e5c0373cd9a484 (diff)
downloadgdb-93878f471745364756b9bad753c5052614fbcd7e.zip
gdb-93878f471745364756b9bad753c5052614fbcd7e.tar.gz
gdb-93878f471745364756b9bad753c5052614fbcd7e.tar.bz2
Allow out-of-order reads of CIEs
Currently gdb has an assertion that requires CIEs to be read in the order in which they appear in the debug info: gdb_assert (n < 1 || cie_table->entries[n - 1]->cie_pointer < cie->cie_pointer); This assertion ensures that the table will be sorted, which is important because it is later searched using bsearch. However, a customer provided an executable that causes this assertion to trigger. This executable causes decode_frame_entry_1 to call decode_frame_entry to find the CIE, resulting in an out-of-order read. I don't know a good way to construct a reproducer, but this can happen if the FDE appears before its CIE. See https://sourceware.org/bugzilla/show_bug.cgi?id=16563 This patch fixes the problem by storing CIEs in an unordered map. The CIE table is discarded after the frame section is parsed, so this seemed both simple and straightforward. gdb/ChangeLog 2019-10-25 Tom Tromey <tromey@adacore.com> * dwarf2-frame.c (dwarf2_cie_table): Now a typedef. (bsearch_cie_cmp, add_cie): Remove. (find_cie): Reimplement. (decode_frame_entry_1, decode_frame_entry): Change type. Update. (dwarf2_build_frame_info): Update. Change-Id: I4a99597fa4b1398a9d105b683a36d992d506485c
Diffstat (limited to 'gdb/compile/compile-object-run.c')
0 files changed, 0 insertions, 0 deletions