Add MinidumpCrashpadInfo::simple_annotations

Add MinidumpCrashpadInfo::simple_annotations.

Some annotations will exist at a broader scope than per-module, which is
the only place that annotations can currently be stored. The product
name and version are not under the control of any module, but are
established when the first Crashpad client establishes a handler. These
annotations will be stored in a minidump’s MinidumpCrashpadInfo
structure, which applies to the entire minidump.

Within the snapshot interface, this data is carried within the
“process” snapshot because it is the top-level structure in that family.
Note that the data may not correspond directly with a process, however.

TEST=minidump_test MinidumpCrashpadInfoWriter.*
R=rsesek@chromium.org

Committed: https://chromium.googlesource.com/crashpad/crashpad/+/a0f5dc62a489a582b22f9ad21a8380a52392bfbc

[Mark Mentovai, 2015-02-17 19:31:55]

mark@chromium.org changed reviewers:
+ rsesek@chromium.org

[Robert Sesek, 2015-02-17 22:20:36]

https://codereview.chromium.org/924673003/diff/20001/snapshot/process_snapshot.h
File snapshot/process_snapshot.h (right):

https://codereview.chromium.org/924673003/diff/20001/snapshot/process_snapsho...
snapshot/process_snapshot.h:96: virtual std::map<std::string, std::string>
AnnotationsSimpleMap() const = 0;
This could be a const& instead, since the objects returned by the other methods
here are guaranteed to be owned by the snapshot.

[Mark Mentovai, 2015-02-17 22:22:01]

https://codereview.chromium.org/924673003/diff/20001/snapshot/process_snapshot.h
File snapshot/process_snapshot.h (right):

https://codereview.chromium.org/924673003/diff/20001/snapshot/process_snapsho...
snapshot/process_snapshot.h:96: virtual std::map<std::string, std::string>
AnnotationsSimpleMap() const = 0;
Robert Sesek wrote:
> This could be a const& instead, since the objects returned by the other
methods
> here are guaranteed to be owned by the snapshot.

Is it fair to impose that at the interface level, though? Or just let it stand
for now and drop it if it becomes a problem in the future?

[Robert Sesek, 2015-02-17 22:23:14]

https://codereview.chromium.org/924673003/diff/20001/snapshot/process_snapshot.h
File snapshot/process_snapshot.h (right):

https://codereview.chromium.org/924673003/diff/20001/snapshot/process_snapsho...
snapshot/process_snapshot.h:96: virtual std::map<std::string, std::string>
AnnotationsSimpleMap() const = 0;
On 2015/02/17 22:22:01, Mark Mentovai wrote:
> Robert Sesek wrote:
> > This could be a const& instead, since the objects returned by the other
> methods
> > here are guaranteed to be owned by the snapshot.
> 
> Is it fair to impose that at the interface level, though? Or just let it stand
> for now and drop it if it becomes a problem in the future?

I don't feel strongly, but the copy seems like it could be heavy, and it's
unnecessary with the current implementations. All the other objects returned off
this interface are const*, though.

[Mark Mentovai, 2015-02-17 22:33:48]

Updated. Added a comment explaining the situation so that we don’t get stuck
with a bad interface if it becomes bad in the future.

[Robert Sesek, 2015-02-17 22:34:39]

LGTM, seems reasonable.

[Mark Mentovai, 2015-02-17 22:38:07]

Committed patchset #3 (id:40001) manually as
a0f5dc62a489a582b22f9ad21a8380a52392bfbc (presubmit successful).