Processor should include code address, not offset of instruction within line

[GoogleCodeExporter]

At the moment, the machine-readable processor output includes the offset of
the frame's current instruction within its source line:

        if (!frame->source_file_name.empty()) {
          printf("%c%s%c%d%c0x%" PRIx64,
                 kOutputSeparator,
                 StripSeparator(frame->source_file_name).c_str(),
                 kOutputSeparator,
                 frame->source_line,
                 kOutputSeparator,
                 frame->instruction - frame->source_line_base);
        } else {

but this is ambiguous: there may be many blocks of code corresponding to a
given source line --- that is, many line records in the symbol file for
different address ranges but whose source file and line number are the same
--- and there's no way to tell which of these lines that final field
describes an offset into.

The last field of the machine-readable output should simply be the address
of the instruction --- perhaps module-relative, but certainly not
thing-whose-address-is-not-given-relative.

Original issue reported on code.google.com by jimbla...@gmail.com on 27 Oct 2009 at 10:18

[GoogleCodeExporter]

I think I just copied what the non-machine-readable output was doing:
http://code.google.com/p/google-breakpad/source/browse/trunk/src/processor/minid
ump_stackwalk.cc#119
It makes more sense there, where it prints:
0  foo!bar() [ foo.c : 10 + 0x2 ]

The machine-readable code currently fills the last field with:
a) source line offset, if full source info is given, else
b) function offset, if function is known, else
c) module offset, if module is known, else
d) instruction pointer

I think b) is actually still useful, since bar() + 0x10 is nicer than bar() 
[foo +
0x1010], but you're right that a) isn't really useful.

Original comment by ted.mielczarek on 30 Oct 2009 at 6:50

[GoogleCodeExporter]

Okay, I see where it comes from now.  But I guess the human-readable 
line-relative
output has the same ambiguity.

The immediate motivation is that we have folks debugging crashes who want to see
which instruction was being executed.  For example, in a world of 30-line 
macros (not
naming any names, PROPERTY_CACHE_TEST), a segfault with the line number of the 
call
doesn't tell you much.  So anything that gets them an instruction in a
straightforward fashion is fine.  Function offsets are just fine.

Original comment by jimbla...@gmail.com on 30 Oct 2009 at 7:46

[GoogleCodeExporter]

If you want to change the machine readable output to only ever output function
offsets even if we have line info, that's fine with me.

Original comment by ted.mielczarek on 10 Nov 2009 at 3:48

[GoogleCodeExporter]

Okay --- I'll put together a patch.

Original comment by jimbla...@gmail.com on 10 Nov 2009 at 9:27