Update third_party/mach_override to include the fix for building Chromium on 64 bits

Update third_party/mach_override from https://github.com/rentzsch/mach_star/mach_override to include the fix for building Chromium on 64 bits.

BUG=138535
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=150529

[Mark Mentovai, 2012-08-06 14:57:34]

To request a code review, just hit “publish + mail comments” from the code
review site. Otherwise, nobody will see it or know it’s ready for review.

[Mark Mentovai, 2012-08-06 15:56:46]

https://chromiumcodereview.appspot.com/10834127/diff/3001/third_party/mach_ov...
File third_party/mach_override/README.chromium (right):

https://chromiumcodereview.appspot.com/10834127/diff/3001/third_party/mach_ov...
third_party/mach_override/README.chromium:30: The latest version doesn't have
the parameter where the local modification was.
Then is there a local modification at all?

If not, this should read

“Local Modifications: None”

The modifications section is only useful if modifications have, in fact been
made. If not, it shouldn’t be used as a dumping ground for historical notes.
That’s what revision history is for.

[Mihai Maerean, 2012-08-06 16:04:27]

On 2012/08/06 15:56:46, Mark Mentovai wrote:
> Then is there a local modification at all?
> If not, this should read
> “Local Modifications: None”

I have uploaded the new version with the requested change (Local Modifications:
None).

[Mark Mentovai, 2012-08-06 16:16:29]

LGTM

[commit-bot: I haz the power, 2012-08-08 08:31:19]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/mmaerean@adobe.com/10834127/4

[commit-bot: I haz the power, 2012-08-08 09:52:38]

Change committed as 150529

[Nico, 2012-08-09 21:14:30]

It looks like this breaks mach_override on 32 bit: http://crbug.com/141707

[Mihai Maerean, 2012-08-22 12:06:25]

How about we fix the build of third_party/mach_override for 64 bits by means of
a local modification?

It's just one line:
Index: src/third_party/mach_override/mach_override.c
===================================================================
--- src/third_party/mach_override/mach_override.c	(revision 150317)
+++ src/third_party/mach_override/mach_override.c	(working copy)
@@ -371,7 +371,7 @@
 		if( !err ) {
 			assert( sizeof( BranchIsland ) <= pageSize );
 #if defined(__x86_64__)
-			vm_address_t first = (uint64_t)originalFunctionAddress &
~(uint64_t)(((uint64_t)1 << 31) - 1) | ((uint64_t)1 << 31); // start in the
middle of the page?
+			vm_address_t first = ((uint64_t)originalFunctionAddress &
~(uint64_t)(((uint64_t)1 << 31)) - 1) | ((uint64_t)1 << 31); // start in the
middle of the page?
 			vm_address_t last = 0x0;
 #else
 			vm_address_t first = 0xffc00000;

Should I upload the patch to this review or should I create a new review?

[Robert Sesek, 2012-08-22 12:21:15]

On 2012/08/22 12:06:25, Mihai Maerean wrote:
> Should I upload the patch to this review or should I create a new review?

Create a new review. You've already committed the patch for this review.

[Mark Mentovai, 2012-08-22 13:04:18]

There’s a very strong preference for fixing the upstream. Even if we took a
local patch, it should immediately be followed up by fixing the upstream. Since
the upstream is broken and we’ve already diverged, we should fix the upstream.

[Nico, 2012-08-22 13:08:35]

On 2012/08/22 13:04:18, Mark Mentovai wrote:
> There’s a very strong preference for fixing the upstream. Even if we took a
> local patch, it should immediately be followed up by fixing the upstream.
Since
> the upstream is broken and we’ve already diverged, we should fix the upstream.

You could try rolling one revision at a time, waiting for a canary release each
time. Then the crash servers probably tell you when things went bad.