[Elftoolchain-developers] changing text address to source *column*

[David Y. <dyo...@po...>]

I have a program that converts a target text address, `t`, to the
corresponding source filename, line and *column* number.  It works
similar to the the `addr2line` utility that comes with elftoolchain:

1 Fetch Dwarf_Lines with `dwarf_srclines`.
2 For each Dwarf_Line
        3 Fetch address, source filename, line number, and column
          number with dwarf_line{addr,no,off,src}.
        4 If the target address, `t`, equals the line address, then
                5 Set the result to the current Dwarf_Line's
                  filename, line & column number.  Stop searching.
        6 If `t` is greater than the prior Dwarf_Line's address,
          and less than the current Dwarf_Line's address, then
                7 Set the result to the prior Dwarf_Line's
                  filename, line & column number.  Stop searching.
        8 Remember the current address, source, line & column number.

(I have left out an outer loop that walks the "compile unit" DIEs.)

This algorithm seems to agree with the interpretation of the .debug_line
matrix that "DWARF Debugging Information Format, Version 4" describes,
where the row for an instruction is omitted from the matrix if its
content is the same as the prior row.

This produces the right line numbers every time.  The column number,
however, is frequently wrong.  It appears to me that if `t` matches a
line record's address precisely, then that record's column corresponds
to `t`.  However, if the prior record's address and the current record's
address bracket `t`, then the current record's column, rather than the
prior's, corresponds to the target address.

I am using Clang 4.0 and elftoolchain release 0.7.  Maybe this
is just a bug in the way that Clang 4.0 saves columns in the
.debug_line matrix?  It appears that when I enable coverage (--coverage
-fprofile-instr-generate), target addresses (such as function return
addresses) do not match addresses in .debug_line rows precisely.  If I
disable coverage, then there are precise matches.

What do you think, am I misinterpreting the column information?

Dave

-- 
David Young
dy...@po...    Urbana, IL    (217) 721-9981