Enabling 64-bit mojo shell to launch 32-bit child to handle nonsfi content.

shell/context.cc

Index: shell/context.cc
diff --git a/shell/context.cc b/shell/context.cc
index 2e9513064dc7dba71e2b9a3fd6ea179e85561c4a..085e09bee20c6ba5f4cc54aa3fcf674107c88346 100644
--- a/shell/context.cc
+++ b/shell/context.cc
@@ -257,6 +257,8 @@ bool Context::Init() {
       base::CommandLine::ForCurrentProcess()->GetProgram());
   base::FilePath shell_child_path =
       shell_path.DirName().AppendASCII("mojo_shell_child");
+  mojo_shell_child_path_32_bit_ =
+      shell_path.DirName().AppendASCII("clang_x86/mojo_shell_child");

[Sean Klein, 2015/09/14 18:10:33]

I'm not entirely sure if I should be dependent on the clang_x86 toolchain here.
I could potentially create another copy rule to move
"clang_x86/mojo_shell_child"
to
"mojo_shell_child_x86",
and call it regardless of the toolchain that built it.


(That being said, this current version does technically work)

[Mark Seaborn, 2015/09/14 18:38:58]

I think this depends how mojo_shell gets packaged.  Whether this is OK is up to
the owners of the code.

[Petr Hosek, 2015/09/14 19:13:52]

The path is an artifact of the build system (GN in this case) and I'd argue
against hardcoding it (we don't want to have a different code path for each
toolchain); instead I'd use a copy rule.

[Sean Klein, 2015/09/15 18:37:50]

Using a copy rule in the gn files -- now there are two binaries:
"mojo_shell_child" and
"mojo_shell_child_32".

The 32-bit version does not indicate which build system it originated from now.

   return InitWithPaths(shell_child_path);
 }