https://sourceware.org/bugzilla/show_bug.cgi?id=21958
Bug ID: 21958
Summary: addr2line incorrectly handles non-increasing sequences
in line table
Product: binutils
Version: 2.30 (HEAD)
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: philipjcraig at gmail dot com
Target Milestone: ---
The attached 'helloworld' file was compiled with rustc 1.18.
Running addr2line gives the following ouput:
$ echo 0x0002f5e0 | addr2line -e helloworld
/checkout/src/liballoc_jemalloc/../jemalloc/src/prof.c:2093
The expected output is:
/checkout/src/liballoc_jemalloc/../jemalloc/src/prof.c:1906
The problem is that the line table for prof.c has badly formed entries. Here's
some of them:
[0x0003215b] Extended opcode 2: set Address to 0x0
[0x00032166] Advance Line by 2082 to 2083
[0x00032169] Copy
[0x0003216a] Advance PC by 0 to 0x0
[0x0003216c] Extended opcode 1: End of Sequence
[0x0003216f] Extended opcode 2: set Address to 0x0
[0x0003217a] Advance Line by 2092 to 2093
[0x0003217d] Copy
[0x0003217e] Advance PC by 0 to 0x0
[0x00032180] Extended opcode 1: End of Sequence
[0x00032183] Extended opcode 2: set Address to 0x2f5f0
[0x0003218e] Advance Line by 2118 to 2119
[0x00032191] Copy
It appears that add_line_info() in bfd/dwarf2.c ends up creating a sequence
containing the addresses 0 and 0x2f5f0, so if an address matches the address
ranges for the prof.c unit, but is less than 0x2f5f0, then the line entry for
address 0 line 2093 will be matched.
I think the cause of the problem is that add_line_info() does not correctly
handle the end_sequence flag when adding info to the middle of a sequence.
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
bug-binutils mailing list
bug-binutils@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-binutils
