aboutsummaryrefslogtreecommitdiff
path: root/gdb/buildsym.c
diff options
context:
space:
mode:
authorTom de Vries <tdevries@suse.de>2020-07-06 14:28:58 +0200
committerTom de Vries <tdevries@suse.de>2020-07-06 14:28:58 +0200
commitd8cc8af6a1787f9c2eafc62a36ac86cf4d08c89c (patch)
tree7942904c5a5af94729930977edccf909e1e189ca /gdb/buildsym.c
parentb5b098c2c9b0ea5588e4198740b8b6dfdb740ffd (diff)
downloadgdb-d8cc8af6a1787f9c2eafc62a36ac86cf4d08c89c.zip
gdb-d8cc8af6a1787f9c2eafc62a36ac86cf4d08c89c.tar.gz
gdb-d8cc8af6a1787f9c2eafc62a36ac86cf4d08c89c.tar.bz2
[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 <tdevries@suse.de> * 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 <tdevries@suse.de> * gdb.dwarf2/dw2-ranges-base.exp: Test line-table order.
Diffstat (limited to 'gdb/buildsym.c')
-rw-r--r--gdb/buildsym.c4
1 files changed, 4 insertions, 0 deletions
diff --git a/gdb/buildsym.c b/gdb/buildsym.c
index 0c4c300..bd0ca49 100644
--- a/gdb/buildsym.c
+++ b/gdb/buildsym.c
@@ -943,6 +943,10 @@ buildsym_compunit::end_symtab_with_blockvector (struct block *static_block,
= [] (const linetable_entry &ln1,
const linetable_entry &ln2) -> bool
{
+ if (ln1.pc == ln2.pc
+ && ((ln1.line == 0) != (ln2.line == 0)))
+ return ln1.line == 0;
+
return (ln1.pc < ln2.pc);
};