Add untrusted NaCl build for PPAPI proxy.

Add untrusted NaCl build for PPAPI proxy.
This patch refactors ppapi_shared.gypi and ppapi_proxy.gypi into proper includes, adds ppapi_shared_untrusted and ppapi_proxy_untrusted .gyp files, and integrates them into the nacl_irt build (ppapi/native_client/native_client.gyp). In order to build without link errors, it includes our plugin side initialization of PluginDispatcher, and a PpapiPluginMain definition. When the 'build_ppapi_ipc_proxy_untrusted' gyp flag is set to '1', this will build a working NaCl IRT using the Chrome IPC proxy.
BUG=116317
TEST=compiles, runs HelloWorld and GetURL SDK examples.

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

[bbudge, 2012-06-13 19:49:10]

This should finish the untrusted build of the NaCl IRT w/ Chrome IPC proxy for
the "proof of concept" phase. I still need to land the Chrome side CL that
establishes the IPC channel between sel_ldr and the renderer process.

[bbudge, 2012-06-13 19:51:13]

On 2012/06/13 19:49:10, bbudge1 wrote:
> This should finish the untrusted build of the NaCl IRT w/ Chrome IPC proxy for
> the "proof of concept" phase. I still need to land the Chrome side CL that
> establishes the IPC channel between sel_ldr and the renderer process.

brettw and dmichael for ppapi/proxy/plugin_globals_nacl.cc, bradn for GYP stuff.

[bradnelson, 2012-06-13 20:21:17]

http://codereview.chromium.org/10546140/diff/5017/build/all.gyp
File build/all.gyp (left):

http://codereview.chromium.org/10546140/diff/5017/build/all.gyp#oldcode21
build/all.gyp:21: '../ipc/ipc_untrusted.gyp:*',
So actually you can leave this in (as it just bloats the all target).
Also I must have missed when you dropped the base_untrusted glob here as well,
that probably should come back.

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
File ppapi/native_client/native_client.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:186: ['disable_nacl==0 and
disable_nacl_untrusted==0 and build_ppapi_ipc_proxy_untrusted==1', {
Rather than make this a completely different target, is there some reason the
dependencies can't be made conditional instead, inside the target?

[Mark Seaborn, 2012-06-13 20:27:37]

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
File ppapi/native_client/native_client.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:186: ['disable_nacl==0 and
disable_nacl_untrusted==0 and build_ppapi_ipc_proxy_untrusted==1', {
We had discussed before building a separate IRT for the new proxy, so that the
two can be present side-by-side in Chromium.  Is there a specific reason you're
not doing that now?

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:210: '-lsrpc',
You shouldn't be depending on srpc.  Can you remove this, or add a TODO to
remove this?  The same goes for 'platform' and 'gio'.

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy.gypi
File ppapi/ppapi_proxy.gypi (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy.gypi#newc...
ppapi/ppapi_proxy.gypi:14: # Take some standalong files from the C++ wrapper
allowing us to more
'standalone'

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy_untrusted...
File ppapi/ppapi_proxy_untrusted.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy_untrusted...
ppapi/ppapi_proxy_untrusted.gyp:28:
'<(DEPTH)/native_client/src/untrusted/pthread/pthread.gyp:pthread_lib',
I think this is wrong, because this is the user libpthread, which is not
suitable for the IRT.  If this actually gets linked into the IRT, the IRT will
go horribly wrong. :-)

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_shared_untruste...
File ppapi/ppapi_shared_untrusted.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_shared_untruste...
ppapi/ppapi_shared_untrusted.gyp:28:
'<(DEPTH)/native_client/src/untrusted/pthread/pthread.gyp:pthread_lib',
The same warning about libpthread applies here.

What does "shared" mean in this file's name?

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
File ppapi/proxy/plugin_globals_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:20: #include
"native_client/src/include/portability.h"
Are you just #including this for EXTERN_C_BEGIN?  I'd prefer you didn't #include
a NaCl header for something trivial like that.  Can you use 'extern "C"' below
instead?

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:32: #define NACL_IPC_FD 6  // TODO(use API
constant)
Please add a comment that this must match up with NACL_CHROME_INITIAL_IPC_DESC,
defined in sel_main_chrome.h.

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:109: static int initialized = 0;
This function body doesn't do anything, so this can be an empty function.

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:131: // TODO(dmichael): Handle other error
canditions, like failure to connect?
'conditions'

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:137: // TODO(dmichael) Figure out how to
determine if we're in incognito
This does not seem appropriate to the untrusted proxy, which does not enforce
incognito mode.

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_main_nac...
File ppapi/proxy/plugin_main_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_main_nac...
ppapi/proxy/plugin_main_nacl.cc:12: int __attribute__((weak)) main(int argc,
char* argv[]) {
This file looks roughly like NaCl's src/untrusted/irt_stub/plugin_main_irt.c,
except that from the Gyp files it looks like it's linked into the IRT.  Why is
this weak?  Who is overriding this?

Actually, I don't understand why you are defining main() at all.  The IRT does
not use a main(); it just has _start().

[bbudge, 2012-06-14 02:45:10]

http://codereview.chromium.org/10546140/diff/5017/build/all.gyp
File build/all.gyp (left):

http://codereview.chromium.org/10546140/diff/5017/build/all.gyp#oldcode21
build/all.gyp:21: '../ipc/ipc_untrusted.gyp:*',
On 2012/06/13 20:21:17, bradnelson wrote:
> So actually you can leave this in (as it just bloats the all target).
> Also I must have missed when you dropped the base_untrusted glob here as well,
> that probably should come back.

Done.

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy.gypi
File ppapi/ppapi_proxy.gypi (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy.gypi#newc...
ppapi/ppapi_proxy.gypi:14: # Take some standalong files from the C++ wrapper
allowing us to more
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> 'standalone'

Done.

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy_untrusted...
File ppapi/ppapi_proxy_untrusted.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy_untrusted...
ppapi/ppapi_proxy_untrusted.gyp:10: '../native_client/build/untrusted.gypi',
I changed this (and others) to common.gypi to match native_client.gyp.

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_proxy_untrusted...
ppapi/ppapi_proxy_untrusted.gyp:28:
'<(DEPTH)/native_client/src/untrusted/pthread/pthread.gyp:pthread_lib',
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> I think this is wrong, because this is the user libpthread, which is not
> suitable for the IRT.  If this actually gets linked into the IRT, the IRT will
> go horribly wrong. :-)

Done.

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_shared_untruste...
File ppapi/ppapi_shared_untrusted.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/ppapi_shared_untruste...
ppapi/ppapi_shared_untrusted.gyp:28:
'<(DEPTH)/native_client/src/untrusted/pthread/pthread.gyp:pthread_lib',
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> The same warning about libpthread applies here.
> 
> What does "shared" mean in this file's name?

Done.

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
File ppapi/proxy/plugin_globals_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:20: #include
"native_client/src/include/portability.h"
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> Are you just #including this for EXTERN_C_BEGIN?  I'd prefer you didn't
#include
> a NaCl header for something trivial like that.  Can you use 'extern "C"' below
> instead?

Done.

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:32: #define NACL_IPC_FD 6  // TODO(use API
constant)
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> Please add a comment that this must match up with
NACL_CHROME_INITIAL_IPC_DESC,
> defined in sel_main_chrome.h.

Done.

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:109: static int initialized = 0;
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> This function body doesn't do anything, so this can be an empty function.

Done.

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:131: // TODO(dmichael): Handle other error
canditions, like failure to connect?
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> 'conditions'

Done.

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_main_nac...
File ppapi/proxy/plugin_main_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_main_nac...
ppapi/proxy/plugin_main_nacl.cc:12: int __attribute__((weak)) main(int argc,
char* argv[]) {
This was copied from the SRPC proxy library, ppruntime. You're right, it's not
needed, so it's out.
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> This file looks roughly like NaCl's src/untrusted/irt_stub/plugin_main_irt.c,
> except that from the Gyp files it looks like it's linked into the IRT.  Why is
> this weak?  Who is overriding this?
> 
> Actually, I don't understand why you are defining main() at all.  The IRT does
> not use a main(); it just has _start().

[bbudge, 2012-06-14 03:01:18]

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
File ppapi/native_client/native_client.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:186: ['disable_nacl==0 and
disable_nacl_untrusted==0 and build_ppapi_ipc_proxy_untrusted==1', {
I'm assuming we will remove the SRPC based IRT at some point, so wanted to avoid
the extra complexity of factoring out the common parts.
On 2012/06/13 20:21:17, bradnelson wrote:
> Rather than make this a completely different target, is there some reason the
> dependencies can't be made conditional instead, inside the target?

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:186: ['disable_nacl==0 and
disable_nacl_untrusted==0 and build_ppapi_ipc_proxy_untrusted==1', {
Just to keep it simple for now.
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> We had discussed before building a separate IRT for the new proxy, so that the
> two can be present side-by-side in Chromium.  Is there a specific reason
you're
> not doing that now?

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:186: ['disable_nacl==0 and
disable_nacl_untrusted==0 and build_ppapi_ipc_proxy_untrusted==1', {
For now it's simpler to do it this way, and I'd like to avoid more complexity. I
agree we may want to have them side by side in the future.
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> We had discussed before building a separate IRT for the new proxy, so that the
> two can be present side-by-side in Chromium.  Is there a specific reason
you're
> not doing that now?

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:210: '-lsrpc',
If I remove it I get link errors. Something is pulling it in. I will add a TODO
though.
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> You shouldn't be depending on srpc.  Can you remove this, or add a TODO to
> remove this?  The same goes for 'platform' and 'gio'.

[dmichael (off chromium), 2012-06-14 03:12:41]

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
File ppapi/native_client/native_client.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:186: ['disable_nacl==0 and
disable_nacl_untrusted==0 and build_ppapi_ipc_proxy_untrusted==1', {
On 2012/06/13 20:27:37, Mark Seaborn wrote:
> We had discussed before building a separate IRT for the new proxy, so that the
> two can be present side-by-side in Chromium.  Is there a specific reason
you're
> not doing that now?
Yeah, we probably should do it this way. It might be a bit of a pain to get it
working right, but it will make it easy to switch proxies without rebuilding, so
we can eventually do both on the bots. It will also make it easier to compare
things like IRT size.

But this seems fine for now to get something going.

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:303: ],
I know you're just copy/pasting, but any clue why we would have anything related
to glibc in a nacl_irt target? It doesn't seem to make sense, but I don't really
know what these are used for.

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:337: ],
There's a lot of copy/paste here...  if there's still that much after you deal
with comments, it might make sense to do a fake target for the common stuff,
like:
http://code.google.com/searchframe#OAMlx_jo-ck/src/ppapi/ppapi_tests.gypi&exa...

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_proxy_untruste...
File ppapi/ppapi_proxy_untrusted.gyp (right):

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_proxy_untruste...
ppapi/ppapi_proxy_untrusted.gyp:14: ['disable_nacl_untrusted==0', {
I see you dropped the build_ppapi_ipc_proxy_untrusted check. Is your intent to
start building our stuff by default? If so, we should drop that flag entirely.

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_proxy_untruste...
ppapi/ppapi_proxy_untrusted.gyp:17: 'target_name': 'ppapi_proxy_untrusted',
doesn't this target also exist in ppapi_proxy_untrusted.gypi? Is that being
included anywhere anymore? If not, we should delete it.

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_shared.gypi
File ppapi/ppapi_shared.gypi (right):

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_shared.gypi#ne...
ppapi/ppapi_shared.gypi:241: 'sources!': [
Does ! mean "exclude these"? If so, there are a few there that we are going to
want eventually...  like ppb_graphics_.d_thunk.cc

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
File ppapi/proxy/plugin_globals_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
ppapi/proxy/plugin_globals_nacl.cc:1: // Copyright (c) 2012 The Chromium
Authors. All rights reserved.
I don't really like the name "plugin_globals_nacl.cc", since it conflates it
with "host_globals" and "plugin_globals.cc" [the latter in this same directory],
and they're pretty different things. I think this should be something more
like...  "nacl_proxy_main.cc". WDYT?

[brettw, 2012-06-14 20:01:04]

owners lgtm

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
File ppapi/proxy/plugin_globals_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
ppapi/proxy/plugin_globals_nacl.cc:100: extern "C" {
I'd put a blank line after this and before the } below just like we would for
namespaces.

[Mark Seaborn, 2012-06-14 21:49:20]

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
File ppapi/proxy/plugin_globals_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:32: #define NACL_IPC_FD 6  // TODO(use API
constant)
On 2012/06/14 02:45:10, bbudge1 wrote:
> On 2012/06/13 20:27:37, Mark Seaborn wrote:
> > Please add a comment that this must match up with
> > NACL_CHROME_INITIAL_IPC_DESC, defined in sel_main_chrome.h.
> 
> Done.

I don't see a different comment in the new version.

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
File ppapi/proxy/plugin_globals_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
ppapi/proxy/plugin_globals_nacl.cc:100: extern "C" {
Rather than using 'extern "C"' here, can you do '#include
"ppapi/native_client/src/shared/ppapi_proxy/ppruntime.h"'?

Although that is from the old proxy, it is the header that the NaCl-side IRT
code #includes, which you're still using.  Using a common #include will ensure
that the functions' types don't get out of sync.

[bbudge, 2012-06-15 01:07:32]

Uploading a revised patch to address comments and fix my linking problem.

The link problem (multiple defs) turned out to be caused by a file in base,
rand_util_nacl.cc, which turned out to be using the IRT for this, which doesn't
work in any case. It turns out that this was only needed for
IPC::Channel::Channel::GenerateUniqueRandomChannelID, which should never be
called in the sandbox. I modified this to return an empty string in OS_NACL and
removed the rand_util stuff from the untrusted builds.

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
File ppapi/native_client/native_client.gyp (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/native_client/native_...
ppapi/native_client/native_client.gyp:186: ['disable_nacl==0 and
disable_nacl_untrusted==0 and build_ppapi_ipc_proxy_untrusted==1', {
I made an attempt to use a target_defaults section, but it fails on Mac. I added
a TODO to fix this.
On 2012/06/13 20:21:17, bradnelson wrote:
> Rather than make this a completely different target, is there some reason the
> dependencies can't be made conditional instead, inside the target?

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
File ppapi/proxy/plugin_globals_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/5017/ppapi/proxy/plugin_globals_...
ppapi/proxy/plugin_globals_nacl.cc:32: #define NACL_IPC_FD 6  // TODO(use API
constant)
Oops. Good catch. Done.
On 2012/06/14 21:49:20, Mark Seaborn wrote:
> On 2012/06/14 02:45:10, bbudge1 wrote:
> > On 2012/06/13 20:27:37, Mark Seaborn wrote:
> > > Please add a comment that this must match up with
> > > NACL_CHROME_INITIAL_IPC_DESC, defined in sel_main_chrome.h.
> > 
> > Done.
> 
> I don't see a different comment in the new version.

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_proxy_untruste...
File ppapi/ppapi_proxy_untrusted.gyp (right):

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_proxy_untruste...
ppapi/ppapi_proxy_untrusted.gyp:14: ['disable_nacl_untrusted==0', {
On 2012/06/14 03:12:41, dmichael wrote:
> I see you dropped the build_ppapi_ipc_proxy_untrusted check. Is your intent to
> start building our stuff by default? If so, we should drop that flag entirely.

Done.

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_proxy_untruste...
ppapi/ppapi_proxy_untrusted.gyp:17: 'target_name': 'ppapi_proxy_untrusted',
On 2012/06/14 03:12:41, dmichael wrote:
> doesn't this target also exist in ppapi_proxy_untrusted.gypi? Is that being
> included anywhere anymore? If not, we should delete it.

Done.

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_shared.gypi
File ppapi/ppapi_shared.gypi (right):

http://codereview.chromium.org/10546140/diff/11016/ppapi/ppapi_shared.gypi#ne...
ppapi/ppapi_shared.gypi:241: 'sources!': [
Added a comment to that effect.
On 2012/06/14 03:12:41, dmichael wrote:
> Does ! mean "exclude these"? If so, there are a few there that we are going to
> want eventually...  like ppb_graphics_.d_thunk.cc

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
File ppapi/proxy/plugin_globals_nacl.cc (right):

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
ppapi/proxy/plugin_globals_nacl.cc:1: // Copyright (c) 2012 The Chromium
Authors. All rights reserved.
This was inspired by the naming in the SRPC proxy. The '_nacl' is dictated by
GYP, where our filename rules give us inclusion/exclusion in line with the rest
of the build. How about "plugin_main_nacl.cc"?
On 2012/06/14 03:12:41, dmichael wrote:
> I don't really like the name "plugin_globals_nacl.cc", since it conflates it
> with "host_globals" and "plugin_globals.cc" [the latter in this same
directory],
> and they're pretty different things. I think this should be something more
> like...  "nacl_proxy_main.cc". WDYT?

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
ppapi/proxy/plugin_globals_nacl.cc:100: extern "C" {
The style checker complains, but I like your way better. Done.
On 2012/06/14 20:01:04, brettw wrote:
> I'd put a blank line after this and before the } below just like we would for
> namespaces.

http://codereview.chromium.org/10546140/diff/11016/ppapi/proxy/plugin_globals...
ppapi/proxy/plugin_globals_nacl.cc:100: extern "C" {
On 2012/06/14 21:49:20, Mark Seaborn wrote:
> Rather than using 'extern "C"' here, can you do '#include
> "ppapi/native_client/src/shared/ppapi_proxy/ppruntime.h"'?
> 
> Although that is from the old proxy, it is the header that the NaCl-side IRT
> code #includes, which you're still using.  Using a common #include will ensure
> that the functions' types don't get out of sync.

Done.

[bbudge, 2012-06-15 01:14:14]

Needed a comma in src/ppapi/proxy/DEPS.

[commit-bot: I haz the power, 2012-06-15 17:03:58]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bbudge@chromium.org/10546140/15001

[commit-bot: I haz the power, 2012-06-15 20:09:07]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/bbudge@chromium.org/10546140/26002

[commit-bot: I haz the power, 2012-06-15 21:34:52]

Change committed as 142482

[scottmg, 2012-06-15 22:19:59]

On 2012/06/15 21:34:52, I haz the power (commit-bot) wrote:
> Change committed as 142482

I think this breaks disable_nacl=1 (because there's no targets in
base_untrusted.gyp anymore maybe?). Do we have a standard way to avoid that
problem?

[scottmg, 2012-06-15 22:22:59]

On 2012/06/15 22:19:59, scottmg wrote:
> On 2012/06/15 21:34:52, I haz the power (commit-bot) wrote:
> > Change committed as 142482
> 
> I think this breaks disable_nacl=1 (because there's no targets in
> base_untrusted.gyp anymore maybe?). Do we have a standard way to avoid that
> problem?

It looks like adding an empty target is enough? 
https://chromiumcodereview.appspot.com/10565014