Issue 340 in google-breakpad: Processor should include code address, not offset of instruction within line

[codesite...@google.com]

Status: Accepted
Owner: jimblandy

New issue 340 by jimblandy: Processor should include code address, not
offset of instruction within line
http://code.google.com/p/google-breakpad/issues/detail?id=340

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.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[codesite...@google.com]

Comment #1 on issue 340 by ted.mielczarek: Processor should include code

address, not offset of instruction within line
http://code.google.com/p/google-breakpad/issues/detail?id=340

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/minidump_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.

[codesite...@google.com]

Comment #2 on issue 340 by jimblandy: Processor should include code

address, not offset of instruction within line
http://code.google.com/p/google-breakpad/issues/detail?id=340

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.