[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [valgrind] [Bug 356044] Dwarf line info reader misinterprets is_stmt register
From:       Josef Weidendorfer via KDE Bugzilla <bugzilla_noreply () kde ! org>
Date:       2015-11-30 9:28:26
Message-ID: bug-356044-17878-xShTEmg5nB () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=356044

--- Comment #3 from Josef Weidendorfer <josef.weidendorfer@gmx.de> ---
Am 28.11.2015 um 22:03 schrieb Ivo Raisr via KDE Bugzilla:
> DWARF v4 says about "is_stmt":
> A boolean indicating that the current instruction is a recommended breakpoint
> location. A recommended breakpoint location is intended to "represent" a line,
> a statement and/or a semantically distinct subpart of a statement.
> 
> However read_dwarf2_lineblock() interprets "is_stmt == 0" as: ignore opcodes in
> the current block until end of sequence or until "is_stmt = 1" again. This
> however has negative consequences: only instructions within the range covered
> by "is_stmt = 1" are considered a part of the line. Instructions belonging to
> the same line but covered by "is_stmt = 0" are not considered a part of the
> line.

I never noted this problem with callgrind/cachegrind, but of course it
would be
bad if some guest instructions are not attributed to the correct source
line in
profiling output.

Where did you notice this? Only with some compiler?
Or is this about future behavior of GCC/clang/whatever ?

Using "--dump-instr=yes", Callgrind adds detailed instruction/source
code relation
to the output, and one should be able to see issues when looking at the
machine code annotation view in {q,k]cachegrind).

Josef

> 
> There are some discussions about use cases for "is_stmt" in conjunction with
> line numbers and I think for debuggers it boils down to the following four:
> 1 - To set a breakpoint at the beginning of a source line.
> 2 - When stepping at the source level to identify when a new source line has
> been encountered.
> 3 - When displaying interspersed disassembled machine code with source code the
> line number tables are used to identify where to insert source code into the
> disassembly listing.
> 4 - When a hardware exception occurs, or when displaying a stack trace then the
> tables are used to identify the particular source line associated with an
> instruction address.
> 
> Valgrind itself is not a debugger and only 4) is therefore relevant. In that
> case, line numbers should correctly reflect all instructions belonging to a
> source line, regardless of is_stmt value.
> 
> Therefore I am proposing to eliminate tracking of is_stmt in readdwarf.c.
> I tested the patch on Linux Ubuntu 15.04 amd64+x86 and Solaris 12 amd64+x86.
> Regression testing is ok.
>

-- 
You are receiving this mail because:
You are watching all bug changes.=
[prev in list] [next in list] [prev in thread] [next in thread]