Cleanup all mentions of bakedin runner

PiperOrigin-RevId: 681482944

README.md

@@ -61,11 +61,9 @@ different CPU microarchitectures it will have multiple expected end states.
 ##### Snap
 
 A Snap is an in-memory representation of a **Snapshot** that can be easily
-loaded and executed by the **Runner**. Snaps can be compiled in an executable
-program (also called *baked-in runner*) or loaded from disk by a *reading
-runner*. In the latter case the Snap on-disk format is essentially the same as
-the in-memory one except that native pointers are replaced with offsets. See
-this
+loaded and executed by the **Runner**. Snaps are typically loaded from disk by a
+*reading runner*. The Snap on-disk format is essentially the same as the
+in-memory one except that native pointers are replaced with offsets. See this
 [header](https://github.com/google/silifuzz/blob/main/snap/gen/relocatable_snap_generator.h)
 for details. This format is often referred to as *relocatable*. Each Snap
 contains exactly one expected end state i.e. Snaps are
@@ -85,19 +83,8 @@ accumulate and report any failures produced by the individual runner processes.
 
 ## Supported platforms and microarchitectures
 
-We have extensively tested SiliFuzz on the following `x86_64` microarchitectures
-running recent Linux kernels:
-
-*   `intel-skylake / intel-cascadelake`
-*   `intel-haswell / intel-broadwell`
-*   `intel-ivybridge`
-*   `amd-rome`
-*   `amd-milan`
-
-Other `x86_64` microarchitectures should work, too, as long as there is the
-compiler and OS support for them.
-
-We are actively working on `AArch64` support.
+See [this file](https://github.com/google/silifuzz/blob/main/util/platform.h) for the
+list of supported microarchitectures.
 
 ## Trophies
 

runner/driver/runner_driver.h

@@ -167,13 +167,6 @@ class RunnerDriver {
     RunnerPostfailureChecksumStatus postfailure_checksum_status_;
   };
 
-  // Creates a RunnerDriver for a binary with baked-in corpus.
-  // The `cleanup` callback will be invoked upon destruction.
-  static RunnerDriver BakedRunner(absl::string_view binary_path,
-                                  std::function<void()> cleanup = {}) {
-    return RunnerDriver(binary_path, "", "", cleanup);
-  }
-
   // Creates a RunnerDriver for a binary that reads corpus from `corpus_path`.
   // The runner will display the corpus name as `corpus_name`. If `corpus_name`
   // is empty, it will use `corpus_path` instead. This allows us to pass a

runner/driver/runner_driver_test.cc

@@ -137,9 +137,9 @@ TEST(RunnerDriver, Cleanup) {
   ASSERT_TRUE(std::filesystem::exists(*tmp_binary));
   bool file_removed = false;
   {
-    RunnerDriver driver = RunnerDriver::BakedRunner(*tmp_binary, [&] {
-      file_removed = std::filesystem::remove(*tmp_binary);
-    });
+    RunnerDriver driver = RunnerDriver::ReadingRunner(
+        *tmp_binary, "<bogus>", "<bogus>",
+        [&] { file_removed = std::filesystem::remove(*tmp_binary); });
   }
   ASSERT_TRUE(file_removed);
   ASSERT_FALSE(std::filesystem::exists(*tmp_binary));

runner/runner_main.cc

@@ -12,16 +12,12 @@
 // See the License for the specific language governing permissions and
 // limitations under the License.
 
-// Main entry point for Snap runner binary.
+// Main entry point for Snap runner binary. Run as follows:
 //
-// SiliFuzz provides two ways to build this into a binary:
+//  reading_runner_main_nolibc corpus_file_name
 //
-// 1) BAKED IN MODE (//third_party/silifuzz/runner:runner_main_nolibc).
-//  Link with :default_snap_corpus and define kDefaultSnapCorpus to point to
-//  the actual Snap corpus. The corpus is usually produced by :snap_generator
-// 2) READING MODE (//third_party/silifuzz/runner:reading_runner_main_nolibc).
-//  Link with :loading_snap_corpus. Then pass the file name containing a
-//  relocatable corpus as a command line argument.
+// See  --help for more details.
+
 #include <unistd.h>
 
 #include <cstdlib>