Android: create a generic android_ucontext.h

Android: create a generic android_ucontext.h

We now have a generic android_ucontext.h that should work on both
ARM and X86.

Note: if this needs to be reverted on X86, please only revert
the GYP file and send me the error message.

(Thanks to Yin Fengwei for his related work in
https://chromiumcodereview.appspot.com/11639038/)

BUG=166704
NOTRY=true

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=177321

[jln (very slow on Chromium), 2013-01-17 01:22:46]

Markus, could you please take a look ?

[Markus (顧孟勤), 2013-01-17 01:31:34]

lgtm

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
File sandbox/linux/services/android_arm_ucontext.h (right):

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:16: unsigned long sig[2];  // 2 is
actually _NSIG_WORDS.
Is this correct for 64bit architectures. I thought, the Linux kernel always has
exactly 64bit signals. But an "unsigned long" would likely be 64bit on a 64bit
system. So, it would give us 128 signals.

Or do we just not care and assume that for the foreseeable future, all of the
Android ARM devices are going to be 32bit?

[palmer, 2013-01-17 01:33:46]

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
File sandbox/linux/services/android_arm_ucontext.h (right):

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:12: typedef unsigned long greg_t;
So, it was supposed to have been unsigned before?

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:16: unsigned long sig[2];  // 2 is
actually _NSIG_WORDS.
Style nit: I'd align these comments. Or, preferably, put them above (rather than
to the right of) the code they comment on.

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:16: unsigned long sig[2];  // 2 is
actually _NSIG_WORDS.
> Or do we just not care and assume that for the foreseeable future, all of the
> Android ARM devices are going to be 32bit?

I'd be surprised if that assumption holds for long.

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:18: // gets defined nower Android
headers.
collisions (one s)

nower --> in newer

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:21: typedef struct ucontext {
Style nit: Since we are poking this code and not blindly copying it from
upstream, it'd be nice to format it according to Chromium style guide. The
upstream style is kind of nasty...

[jln (very slow on Chromium), 2013-01-17 01:53:27]

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
File sandbox/linux/services/android_arm_ucontext.h (right):

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:12: typedef unsigned long greg_t;
On 2013/01/17 01:33:46, Chris P. wrote:
> So, it was supposed to have been unsigned before?

It was wrong before. Someone nice added it to green the tree at some point, not
me :)

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:16: unsigned long sig[2];  // 2 is
actually _NSIG_WORDS.
On 2013/01/17 01:31:34, Markus (顧孟勤) wrote:
> Is this correct for 64bit architectures. I thought, the Linux kernel always
has
> exactly 64bit signals. But an "unsigned long" would likely be 64bit on a 64bit
> system. So, it would give us 128 signals.
> 
> Or do we just not care and assume that for the foreseeable future, all of the
> Android ARM devices are going to be 32bit?

Yeah I tried to copy exactly what they were doing on arm 32 bits.
arm64 bits will be a new architecture.

On arm64 bits, they'll use the generic UAPI one from
include/uapi/asm-generic/signal.h

I changed it to the UAPI version, since it's more generic.

Moreover, as you can see below, it doesn't matter for the structure definition
anyways (we always build a 32 bytes sigset_t) and I specifically changed the
name of sigset_t to something obscure.

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:18: // gets defined nower Android
headers.
On 2013/01/17 01:33:46, Chris P. wrote:
> collisions (one s)
> 
> nower --> in newer

Done.

https://chromiumcodereview.appspot.com/11971028/diff/6002/sandbox/linux/servi...
sandbox/linux/services/android_arm_ucontext.h:21: typedef struct ucontext {
On 2013/01/17 01:33:46, Chris P. wrote:
> Style nit: Since we are poking this code and not blindly copying it from
> upstream, it'd be nice to format it according to Chromium style guide. The
> upstream style is kind of nasty...

I'll keep it as is if you don't mind I would really rather touch it as little as
I can.
Also it makes it easier for people to compare to the original etc..

[commit-bot: I haz the power, 2013-01-17 02:28:57]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jln@chromium.org/11971028/6004

[commit-bot: I haz the power, 2013-01-17 02:38:51]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/jln@chromium.org/11971028/6004

[commit-bot: I haz the power, 2013-01-17 02:43:24]

Change committed as 177321