From 6a33f669132ccbcdbe18bef63697b7368da96b7f Mon Sep 17 00:00:00 2001
From: James Tucker <raggi@google.com>
Date: Mon, 5 Mar 2018 21:07:07 -0800
Subject: [PATCH] [all] Fuchsia architecture is now x64 for x86_64
Change-Id: I32aaa13717667c8066e4370b419909258722cfea
---
build_overview.md | 8 ++++----
build_variants.md | 10 +++++-----
ctu_analysis.md | 2 +-
debugging.md | 2 +-
development/languages/dart/ides.md | 2 +-
development/languages/rust/README.md | 2 +-
development/languages/rust/third_party.md | 2 +-
fuchsia_paver.md | 4 ++--
getting_started.md | 10 +++++-----
toolchain.md | 6 +++---
10 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/build_overview.md b/build_overview.md
index b1514231cb6..ea0069ec9b0 100644
--- a/build_overview.md
+++ b/build_overview.md
@@ -117,13 +117,13 @@ $ dot -Tpng tree.dot -o tree.png
### Inspecting the content of a GN target
```bash
-$ buildtools/gn desc out/debug-x86 //path/to/my:target
+$ buildtools/gn desc out/debug-x64 //path/to/my:target
```
### Finding references to a GN target
```bash
-$ buildtools/gn refs out/debug-x86 //path/to/my:target
+$ buildtools/gn refs out/debug-x64 //path/to/my:target
```
### Referencing targets for the build host
@@ -146,7 +146,7 @@ file:
If a target is defined in a GN build file as `//foo/bar/blah:dash`, that target
(and its dependencies) can be built with:
```bash
-$ buildtools/ninja -C out/debug-x86 -j64 foo/bar/blah:dash
+$ buildtools/ninja -C out/debug-x64 -j64 foo/bar/blah:dash
```
Note that this only works for targets in the default toolchain.
@@ -161,7 +161,7 @@ $ buildtools/gn help ninja_rules
You can also browse the set of Ninja targets currently defined in your output
directory with:
```bash
-$ buildtools/ninja -C out/debug-x86 -t browse
+$ buildtools/ninja -C out/debug-x64 -t browse
```
Note that the presence of a Ninja target does not mean it will be built - for
that it needs to depend on the “default†target.
diff --git a/build_variants.md b/build_variants.md
index 8df384bc522..5c7a48e5b1d 100644
--- a/build_variants.md
+++ b/build_variants.md
@@ -27,7 +27,7 @@ Here's an example running `gen.py` directly:
This does the same thing using the `fx set` tool:
```sh
-fx set x86 --variant host_asan --variant asan=cat,ledger
+fx set x64 --variant host_asan --variant asan=cat,ledger
```
1. The first switch applies the `host_asan` matching rule, which enables
@@ -53,9 +53,9 @@ set the `select_variant` GN build argument directly.
approximate what you want and then edit the `select_variant` value `gen.py`
produces:
* You can just edit the `args.gn` file in the GN output directory
- (e.g. `out/debug-x86/args.gn`) and the next `ninja` run (aka `fx build`)
+ (e.g. `out/debug-x64/args.gn`) and the next `ninja` run (aka `fx build`)
will re-run `gn gen` with those changes.
- * You can use the command `./buildtools gn args out/debug-x86`, which
+ * You can use the command `./buildtools gn args out/debug-x64`, which
will run your `$EDITOR` on the `args.gn` file and then do `gn gen`
immediately so you can see any errors in your GN syntax.
@@ -71,7 +71,7 @@ also runs GN this way:
You can also use the `fx set` tool to run `gen.py` for you:
```sh
-fx set x86 --help-args select_variant
+fx set x64 --help-args select_variant
```
If you combine this with one or more `--variant` switches, GN will show you
@@ -84,7 +84,7 @@ the actual value of `select_variant` that `gen.py` chose. For example:
or:
```sh
-fx set x86 --help-args select_variant --variant asan=cat,ledger
+fx set x64 --help-args select_variant --variant asan=cat,ledger
```
prints out:
diff --git a/ctu_analysis.md b/ctu_analysis.md
index a37cad6dba8..4c718f85e05 100644
--- a/ctu_analysis.md
+++ b/ctu_analysis.md
@@ -75,7 +75,7 @@ make clean && ./run.sh
In order to build only the kernel, specify a `TARGET` as an environment variable:
```
-make clean && TARGET=./build-zircon-pc-x86/zircon.elf ./run.sh
+make clean && TARGET=./build-zircon-pc-x64/zircon.elf ./run.sh
```
The script also requires [clangify.py](https://gist.github.com/karkhaz/2ab5e8c7a8783318d44ceca715f20438) to be in the zircon directory with executable bit set. After the analysis has finished, there will be a `.result-xtu` directory, containing:
diff --git a/debugging.md b/debugging.md
index 84f8a57c8d3..c4aceb3ffbd 100644
--- a/debugging.md
+++ b/debugging.md
@@ -72,7 +72,7 @@ addresses in the backtrace to symbolic form. This program is `symbolize`:
Copy the above to a file, say `backtrace.out`, and then run:
```
-bash$ ZIRCON_BUILD_DIR=$FUCHSIA_DIR/out/build-zircon/build-x86
+bash$ ZIRCON_BUILD_DIR=$FUCHSIA_DIR/out/build-zircon/build-x64
bash$ cat backtrace.out | $FUCHSIA_DIR/zircon/scripts/symbolize \
--build-dir=$ZIRCON_BUILD_DIR \
$ZIRCON_BUILD_DIR/system/utest/debugger/debugger.elf
diff --git a/development/languages/dart/ides.md b/development/languages/dart/ides.md
index f224f01d284..c86401f32e6 100644
--- a/development/languages/dart/ides.md
+++ b/development/languages/dart/ides.md
@@ -52,5 +52,5 @@ following:
build. This means that if you have a broken release build, any release build
overrides a debug build. With a broken release build, no amount of correct
rebuilding on debug will solve the issue until you delete
- `//out/release-x86`.
+ `//out/release-x64`.
- Delete the .packages file in your project and rebuild.
diff --git a/development/languages/rust/README.md b/development/languages/rust/README.md
index 2e1decae940..6de8c60d467 100644
--- a/development/languages/rust/README.md
+++ b/development/languages/rust/README.md
@@ -116,7 +116,7 @@ If you want to test out Fuchsia with your own custom-built versions of rustc or
you can set the `rustc_prefix` argument to `fx set`, like this:
```
-fx set x86 --release --args "rustc_prefix=\"/path/to/bin/dir\""
+fx set x64 --release --args "rustc_prefix=\"/path/to/bin/dir\""
```
## Going further
diff --git a/development/languages/rust/third_party.md b/development/languages/rust/third_party.md
index 499ade0a9e3..92a883d78d7 100644
--- a/development/languages/rust/third_party.md
+++ b/development/languages/rust/third_party.md
@@ -28,7 +28,7 @@ a new crate, you'll need to either run `update_rust_crates.sh` or temporarily
pass use_frozen_with_cargo=false to gn. If you are using the fx scripts,
you can do so as follows:
- ./scripts/fx set x86 --release --packages garnet/packages/default --args "use_frozen_with_cargo=false"
+ ./scripts/fx set x64 --release --packages garnet/packages/default --args "use_frozen_with_cargo=false"
Running `update_rust_crates.sh` to solve this problem will have the side effect
of updating all the existing crates in `third_party/rust-crates`, which may not be desired.
diff --git a/fuchsia_paver.md b/fuchsia_paver.md
index feed33e97c2..514db37f180 100644
--- a/fuchsia_paver.md
+++ b/fuchsia_paver.md
@@ -23,7 +23,7 @@ extend to allow you to build what you need.
## TL;DR
Read this all before? Here are the common case commands
-1. `fx set x86`
+1. `fx set x64`
2. `fx full-build`
3. Make the install media
* [[ insert USB drive into host ]]
@@ -37,7 +37,7 @@ Read this all before? Here are the common case commands
Detailed instructions for obtaining and building Fuchsia are available from the
[Getting Started](getting_started.md) guide, but we'll assume here that the
target system is x86-based and that you want to build a complete system. To
-configure our build for this we can run `fx set x86` and then build with
+configure our build for this we can run `fx set x64` and then build with
`fx full-build`.
## Creating install media
diff --git a/getting_started.md b/getting_started.md
index 9f378d20d68..816b395e9ac 100644
--- a/getting_started.md
+++ b/getting_started.md
@@ -67,13 +67,13 @@ the `fx` command should already be in your path. If not, the command is also
available as `scripts/fx`.
```
-fx set x86
+fx set x64
fx full-build
```
The first command selects the build configuration you wish to build and
generates the build system itself in an output directory
-(e.g., `out/debug-x86`).
+(e.g., `out/debug-x64`).
The second command actually executes the build, transforming the source code in
build products. If you modify the source tree, you can do an incremental build
@@ -83,15 +83,15 @@ Alternatively, you can use the [underlying build system directly](build_system.m
#### [optional] Customize Build Environment
-By default you will get a x86 debug build. You can skip this section unless
+By default you will get a x64 debug build. You can skip this section unless
you want something else.
Run `fset-usage` to see a list of build options. Some examples:
```
-fx set x86 # x86 debug build
+fx set x64 # x64 debug build
fx set arm64 # arm64 debug build
-fx set x86 --release # x86 release build
+fx set x64 --release # x64 release build
```
#### [optional] Accelerate builds with `ccache` and `goma`
diff --git a/toolchain.md b/toolchain.md
index 1b58305d335..65fa5a15a0a 100644
--- a/toolchain.md
+++ b/toolchain.md
@@ -29,15 +29,15 @@ LLVM_SRCDIR=${HOME}/llvm
Before building the runtime libraries that are built along with the
compiler, you need a Zircon `sysroot` built. This comes from the
Zircon build and sits in the `sysroot` subdirectory of the main Zircon
-build directory. For example, `.../build-x86/sysroot`.
+build directory. For example, `.../build-x64/sysroot`.
In the following commands, the string `${FUCHSIA_${arch}_SYSROOT}`
stands in for this absolute directory name. You can cut & paste these
commands into a shell after setting the `FUCHSIA_${arch}_SYSROOT`
variable, e.g.:
```bash
-make x86
-FUCHSIA_x86_64_SYSROOT=`pwd`/build-x86/sysroot
+make x64
+FUCHSIA_x86_64_SYSROOT=`pwd`/build-x64/sysroot
make arm64
FUCHSIA_aarch64_SYSROOT=`pwd`/build-arm64/sysroot
--
GitLab