From d8cc8af6a1787f9c2eafc62a36ac86cf4d08c89c Mon Sep 17 00:00:00 2001 From: Tom de Vries Date: Mon, 6 Jul 2020 14:28:58 +0200 Subject: [gdb/symtab] Fix line-table end-of-sequence sorting Consider test-case gdb.dwarf2/dw2-ranges-base.exp. It has (ignoring non-sensical entries that are filtered out by buildsym_compunit::record_line) a line-table for dw2-ranges-base.c like this: ... Line Number Statements: [0x0000014e] Extended opcode 2: set Address to 0x4004ba [0x00000159] Advance Line by 10 to 11 [0x0000015b] Copy [0x0000015c] Advance PC by 12 to 0x4004c6 [0x0000015e] Extended opcode 1: End of Sequence [0x00000161] Extended opcode 2: set Address to 0x4004ae [0x0000016c] Advance Line by 20 to 21 [0x0000016e] Copy [0x0000016f] Advance PC by 12 to 0x4004ba [0x00000171] Extended opcode 1: End of Sequence [0x00000174] Extended opcode 2: set Address to 0x4004a7 [0x0000017f] Advance Line by 30 to 31 [0x00000181] Copy [0x00000182] Advance PC by 7 to 0x4004ae [0x00000184] Extended opcode 1: End of Sequence ... If we disable the sorting in buildsym_compunit::end_symtab_with_blockvector, we have the unsorted line table: ... INDEX LINE ADDRESS IS-STMT 0 11 0x00000000004004ba Y 1 END 0x00000000004004c6 Y 2 21 0x00000000004004ae Y 3 END 0x00000000004004ba Y 4 31 0x00000000004004a7 Y 5 END 0x00000000004004ae Y ... It contains 3 sequences, 11/END, 21/END and 31/END. We want to sort the 3 sequences relative to each other, while sorting on address, to get: ... INDEX LINE ADDRESS IS-STMT 0 31 0x00000000004004a7 Y 1 END 0x00000000004004ae Y 2 21 0x00000000004004ae Y 3 END 0x00000000004004ba Y 4 11 0x00000000004004ba Y 5 END 0x00000000004004c6 Y ... However, if we re-enable the sorting, we have instead: ... INDEX LINE ADDRESS IS-STMT 0 31 0x00000000004004a7 Y 1 21 0x00000000004004ae Y 2 END 0x00000000004004ae Y 3 11 0x00000000004004ba Y 4 END 0x00000000004004ba Y 5 END 0x00000000004004c6 Y ... This is a regression since commit 3d92a3e313 "gdb: Don't reorder line table entries too much when sorting", that introduced sorting on address while keeping entries with the same address in pre-sort order. Indeed the entries 1 and 2 are in pre-sort order (they map to entries 2 and 5 in the unsorted line table), but entry 1 does not belong in the sequence terminated by 2. Fix this by handling End-Of-Sequence entries in the sorting function, such that they are sorted before other entries with the same address. Also, revert the find_pc_sect_line workaround introduced in commit 3d92a3e313, since that's no longer necessary. Tested on x86_64-linux. gdb/ChangeLog: 2020-07-06 Tom de Vries * buildsym.c (buildsym_compunit::end_symtab_with_blockvector): Handle End-Of-Sequence in lte_is_less_than. * symtab.c (find_pc_sect_line): Revert change from commit 3d92a3e313 "gdb: Don't reorder line table entries too much when sorting". gdb/testsuite/ChangeLog: 2020-07-06 Tom de Vries * gdb.dwarf2/dw2-ranges-base.exp: Test line-table order. --- gdb/symtab.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) (limited to 'gdb/symtab.c') diff --git a/gdb/symtab.c b/gdb/symtab.c index 19f078e..f96ad95 100644 --- a/gdb/symtab.c +++ b/gdb/symtab.c @@ -3236,12 +3236,7 @@ find_pc_sect_line (CORE_ADDR pc, struct obj_section *section, int notcurrent) struct linetable_entry *last = item + len; item = std::upper_bound (first, last, pc, pc_compare); if (item != first) - { - /* Found a matching item. Skip backwards over any end of - sequence markers. */ - for (prev = item - 1; prev->line == 0 && prev != first; prev--) - /* Nothing. */; - } + prev = item - 1; /* Found a matching item. */ /* At this point, prev points at the line whose start addr is <= pc, and item points at the next line. If we ran off the end of the linetable -- cgit v1.1