Adding atomic ops for MIPS architecture.

[MIPS] Adding atomic ops for MIPS architecture.

Initial commit for atomic operations on MIPS architecture.

BUG=https://code.google.com/p/chromium/issues/detail?id=130022
TEST=make chrome


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

[petarj, 2012-05-28 22:24:45]

This patch adds support for atomic operations for MIPS architecture.

[Brad Chen, 2012-05-29 18:46:41]

On 2012/05/28 22:24:45, petarj wrote:
> This patch adds support for atomic operations for MIPS architecture.

While I'm looking for a more qualified reviewer, can you figure out how to run
base/atomicops_unittest.cc and confirm that those tests work with your MIPS
implementation?

[Brad Chen, 2012-05-29 21:23:50]

Thanks for pointing out that this code is the same as
v8/src/atomicops_internal_mips_gcc.h

Q: Why do you need this file in chromium/src/base? If it's for Native Client,
should it go someplace in the NaCl tree?

On 2012/05/29 18:46:41, Brad Chen wrote:
> On 2012/05/28 22:24:45, petarj wrote:
> > This patch adds support for atomic operations for MIPS architecture.
> 
> While I'm looking for a more qualified reviewer, can you figure out how to run
> base/atomicops_unittest.cc and confirm that those tests work with your MIPS
> implementation?

[petarj, 2012-05-29 21:39:37]

On 2012/05/29 21:23:50, Brad Chen wrote:
> Q: Why do you need this file in chromium/src/base? If it's for Native Client,
> should it go someplace in the NaCl tree?

This patch is actually the first one in a series of (small) patches that enable
building Chromium for MIPS platforms. The issue page is: 
https://code.google.com/p/chromium/issues/detail?id=130022

This is not (strictly) needed for Native Client.

[darin (slow to review), 2012-05-29 22:01:39]

Is there going to be buildbot infrastructure on build.chromium.org for this
port?  How will Chromium developers maintain this port?

[petarj, 2012-06-01 23:24:36]

On 2012/05/29 22:01:39, darin wrote:
> Is there going to be buildbot infrastructure on http://build.chromium.org for
this
> port?  How will Chromium developers maintain this port?

I have created a thread for this on chromium-dev, so we can discuss if and what
additional build/test infrastructure is needed for it.
https://groups.google.com/a/chromium.org/group/chromium-dev/browse_thread/thr...

[brettw, 2012-06-16 03:26:35]

LGTM

[M-A Ruel, 2012-06-18 00:41:57]

Be sure to use the latest version of the depot_tools. It seems like the version
you used had the bug with the upstream branch name. This causes the 'base url'
to be missing from the issue, causing the CQ to ignore this change. I'll update
this CL manually to set a fake base url, so that the CQ can trigger correctly.

[M-A Ruel, 2012-06-18 00:44:07]

On 2012/06/18 00:41:57, Marc-Antoine Ruel wrote:
> Be sure to use the latest version of the depot_tools. It seems like the
version
> you used had the bug with the upstream branch name. This causes the 'base url'
> to be missing from the issue, causing the CQ to ignore this change. I'll
update
> this CL manually to set a fake base url, so that the CQ can trigger correctly.

You can now see on the left side:
Base URL:
http://git.chromium.org/chromium/src.git@master

[commit-bot: I haz the power, 2012-06-18 00:44:20]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/petarj@mips.com/10448043/1

[commit-bot: I haz the power, 2012-06-18 00:44:23]

Presubmit check for 10448043-1 failed and returned exit status 1.

Running presubmit commit checks ...

** Presubmit Warnings **
petarj@mips.com is not in AUTHORS file. If you are a new contributor, please
visit
http://www.chromium.org/developers/contributing-code and read the "Legal"
section
If you are a chromite, verify the contributor signed the CLA.

Presubmit checks took 1.1s to calculate.

[M-A Ruel, 2012-06-18 00:55:04]

On 2012/06/18 00:44:23, I haz the power (commit-bot) wrote:
> Presubmit check for 10448043-1 failed and returned exit status 1.
> 
> Running presubmit commit checks ...
> 
> ** Presubmit Warnings **
> mailto:petarj@mips.com is not in AUTHORS file. If you are a new contributor,
please
> visit
> http://www.chromium.org/developers/contributing-code and read the "Legal"
> section
> If you are a chromite, verify the contributor signed the CLA.
> 
> Presubmit checks took 1.1s to calculate.

What the presubmit check says is:
- Make sure the corporate CLA for MIPS is updated to include your name. Your
name is not listed in the corporate CLA at the moment.
- Then (and only then), add yourself to src/AUTHORS.

[M-A Ruel, 2012-06-18 01:02:42]

On 2012/06/18 00:55:04, Marc-Antoine Ruel wrote:
> What the presubmit check says is:
> - Make sure the corporate CLA for MIPS is updated to include your name. Your
> name is not listed in the corporate CLA at the moment.

I didn't look at the right place, no need to do anything.

> - Then (and only then), add yourself to src/AUTHORS.

You just need to do that.

[commit-bot: I haz the power, 2012-06-18 01:17:45]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/petarj@mips.com/10448043/13001

[commit-bot: I haz the power, 2012-06-18 02:47:07]

Change committed as 142663

[stuartmorgan, 2012-06-29 13:49:15]

https://chromiumcodereview.appspot.com/10448043/diff/1/build/build_config.h
File build/build_config.h (right):

https://chromiumcodereview.appspot.com/10448043/diff/1/build/build_config.h#n...
build/build_config.h:110: #define WCHAR_T_IS_UNSIGNED 0
This came up incidentally in an unrelated review: why is this line here? Is this
overriding some other #define to 1? If so, why isn't the fix at that point,
instead of setting it to 0 here?

[petarj, 2012-07-01 22:56:51]

https://chromiumcodereview.appspot.com/10448043/diff/1/build/build_config.h
File build/build_config.h (right):

https://chromiumcodereview.appspot.com/10448043/diff/1/build/build_config.h#n...
build/build_config.h:110: #define WCHAR_T_IS_UNSIGNED 0
On 2012/06/29 13:49:15, stuartmorgan wrote:
> This came up incidentally in an unrelated review: why is this line here? Is
this
> overriding some other #define to 1? If so, why isn't the fix at that point,
> instead of setting it to 0 here?

No, this is not overriding any other #define directive. It was just a matter of
code style, so we define it to zero instead of leaving it undefined.