New Linux file_id code doesn't persist across strip

[GoogleCodeExporter]

The Linux client rewrite changed the Linux file_id code to use a simple XOR
of the first page of the binary. However, in my testing, this value changes
if you strip the binary.

I'm not sure how this would work at all, since you can't calculate the file
ID until you strip it, but you can't dump the symbols if you've stripped
it. It seems like dump_syms, at least, is currently completely broken. Is
Google really using this code in production?

Original issue reported on code.google.com by ted.mielczarek on 16 Dec 2009 at 2:00

[GoogleCodeExporter]

Looking at the old file_id code, it used to find the .text section and then 
generate
a MD5 hash:
http://code.google.com/p/google-breakpad/source/browse/trunk/src/common/linux/fi
le_id.cc?spec=svn450&r=312

Presumably doing the MD5 hash in the crashed process is a no-no, but the code to
locate the .text section seems pretty harmless. Could we switch to XORing the
contents of the .text section instead?

Original comment by ted.mielczarek on 16 Dec 2009 at 2:10

[GoogleCodeExporter]

A patch is up for review at http://breakpad.appspot.com/49008

Original comment by ted.mielczarek on 18 Dec 2009 at 6:45

[GoogleCodeExporter]

Fixed in r461.

Original comment by ted.mielczarek on 23 Dec 2009 at 5:09

• Changed state: Fixed