Handle stackwalking programs with the assignment operator smashed against the next token

Handle stackwalking programs with the assignment operator smashed against the
next token

[Ted Mielczarek]

I don't have time to review this. Mark, can you take a look?

[Mark Mentovai]

Benjamin, when do you see these smash-ups? What platform?

[jimb_red-bean.com]

Why can't we just fix the symbol writer, and let folks who need it take
this as a temporary patch?
On Feb 22, 2012 1:50 PM, <ted.mielczarek@gmail.com> wrote:

> I don't have time to review this. Mark, can you take a look?
>
> http://breakpad.appspot.com/**352001/<http://breakpad.appspot.com/352001/>
>
> --
> You received this message because you are subscribed to the Google Groups
> "google-breakpad-dev" group.
> To post to this group, send email to google-breakpad-dev@**
> googlegroups.com <google-breakpad-dev@googlegroups.com>.
> To unsubscribe from this group, send email to google-breakpad-dev+**
>
unsubscribe@googlegroups.com<google-breakpad-dev%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at http://groups.google.com/**
>
group/google-breakpad-dev?hl=**en<http://groups.google.com/group/google-breakpad-dev?hl=en>
> .
>
>

[Mark Mentovai]

Ha, beat you!

I was going to say what Jim said if the answer was “Linux” or “Mac,” where we
create the postfix string on our own. If the answer is Windows, where we just
pull the string as-is out from calls into MS’ library, it’s a toss-up. I think I
would have a preference for keeping the server side postfix evaluator more
simple and doing the rewriting once at dump_syms time, though.

[bsmedberg]

This is definitely Windows, the programs are embedded by MSVC10, and probably
only by MSVC10 in LTO mode, although I haven't spent time verifying that. It
seems to come up primarily on unusually-arranged stack frames with saved
registers and separate hot and cold sections.

We already have 5 weeks of .sym files in the old format, so I'm a little nervous
spending time recreating those, although I suppose we could do that with a
python script... I just figured that we'd take what MSVC gave us and deal with
it in the processor.

[jimb_red-bean.com]

On Thu, Feb 23, 2012 at 5:12 AM,  <bsmedberg@gmail.com> wrote:
> This is definitely Windows, the programs are embedded by MSVC10, and
> probably only by MSVC10 in LTO mode, although I haven't spent time
> verifying that. It seems to come up primarily on unusually-arranged
> stack frames with saved registers and separate hot and cold sections.

I agree with Mark that this affects the decision. Fixing this in the
dumper would, I guess, require us to parse something we're not
currently parsing, and that doesn't seem worth it.

[Mark Mentovai]

LGTM with these two minor changes, which I’ve made. I committed this patch as
r926.

http://breakpad.appspot.com/352001/diff/4001/src/processor/postfix_evaluator-...
File src/processor/postfix_evaluator-inl.h (right):

http://breakpad.appspot.com/352001/diff/4001/src/processor/postfix_evaluator-...
src/processor/postfix_evaluator-inl.h:72: DictionaryValidityType *assigned)
Style nit: this line hits 81 characters. There’s a better way to wrap the
arguments to avoid this.

http://breakpad.appspot.com/352001/diff/4001/src/processor/postfix_evaluator-...
src/processor/postfix_evaluator-inl.h:214: // $T0 $ebp 128 + =$eip $T0 4 + ^
=$ebp $T0 ^ =
You should comment here that this has been observed in at least MSVS 2010 in LTO
mode.

http://breakpad.appspot.com/352001/diff/4001/src/processor/postfix_evaluator_...
File src/processor/postfix_evaluator_unittest.cc (right):

http://breakpad.appspot.com/352001/diff/4001/src/processor/postfix_evaluator_...
src/processor/postfix_evaluator_unittest.cc:153: { "$rAdd3 2 2 + =$rMul2 9 6 *
=", true } // smashed-equals tokenization
Thank you for adding a test case for this.