Fix radamsa binary for ARM64 by JuanMBriones · Pull Request #5463 · google/clusterfuzz

JuanMBriones · 2026-09-09T02:18:04Z

When executing Mac ARM64 swarming tasks we execute radamsa binary,
hence having it as a ARM64 is needed.

Ran python butler.py py_unittest -t core -p engine_common_test.py (passed).

Bug: 561690132

g-ortuno

It's not great that we have "resources/platform/[platform]" AND "fuzzers/bin/[platform]". Could we move RADAMSA to "resources/platform/" and then do something like:

def get_radamsa_path():
  """Return path to radamsa binary for current platform."""
  if environment.platform() not in ('LINUX', 'MAC'):
    return None
  return environment.get_default_tool_path('radamsa')

JuanMBriones · 2026-09-18T18:22:29Z

It's not great that we have "resources/platform/[platform]" AND "fuzzers/bin/[platform]". Could we move RADAMSA to "resources/platform/" and then do something like:
def get_radamsa_path():
  """Return path to radamsa binary for current platform."""
  if environment.platform() not in ('LINUX', 'MAC'):
    return None
  return environment.get_default_tool_path('radamsa')

Pls excuse the delay. I think I got a better solution for the platform + arch binaries.

For x86 binaries they'll be located on resources/platform/[platform] and for other archs (different than x86) they will be located on resources/platform/[platform]/arch/

Pls let me know what you think:D

…rectory Use binaries for different archs and platforms. This allows to have a more structured way to handle and support more architectures. - x86 binaries will be located in `resources/platform/[platform]` - Others archs bins (arm64, etc) will be located in `resources/platform/[platform]/arch/` Signed-off-by: Manuel Briones <manuelbriones@google.com>

When executing macOS ARM64 Swarming tasks, ClusterFuzz invokes the radamsa mutator binary. Previously, only an x86_64 macOS binary was bundled, and extracted files could lack execute permissions under Swarming bot users. Changes: * Add native macOS ARM64 binary (`bin/mac/radamsa_arm64`). * Update `get_radamsa_path()` in `engine_common.py`: - Prefer `radamsa` from `APP_DIR` (fuzzer build directory) if present. - Detect ARM64 on macOS and select `radamsa_arm64` over x86_64 `radamsa`. - Ensure `0o755` permissions on the resolved binary via `os.chmod`. * Add unit tests for `get_radamsa_path()` in `engine_common_test.py`. Bug: 561690132 Signed-off-by: Manuel Briones <manuelbriones@google.com>

g-ortuno · 2026-09-18T18:41:05Z

So you're saying we would have:

resources/
  platform/
    macos/
      llvm-symbolizer
      radamsa
      arm64/
        llvm-symbolizer
        radamsa

Instead of:

resources/
  platform/
    macos/
      llvm-symbolizer
      radamsa
    macos_arm64/
      llvm-symbolizer
      radamsa

Was there an issue with the latter option? I don't have a super strong opinion with a small preference for the second one since it's less nested dirs and matches the format of deployment targets i.e. macos and macos_arm64.

JuanMBriones · 2026-09-18T18:52:07Z

So you're saying we would have:
resources/
  platform/
    macos/
      llvm-symbolizer
      radamsa
      arm64/
        llvm-symbolizer
        radamsa
Instead of:
resources/
  platform/
    macos/
      llvm-symbolizer
      radamsa
    macos_arm64/
      llvm-symbolizer
      radamsa
Was there an issue with the latter option? I don't have a super strong opinion with a small preference for the second one since it's less nested dirs and matches the format of deployment targets i.e. macos and macos_arm64.

Yeah I opted for the first option. But, tbh I would love feedback on it. I'm open to choose what will suit the best:D

AFAIK platform is the operating system itself and I think is logical to have a subsection for the archtecture and not blend it together with the platform.

On the other hand, I support your arguments and I think having the same naming as the deployment target is a better practice as well.

There's another thing I've been looking into the last couple of days... having a Universal executable at least for Mac 1,2 it basically have a header that is used by Mac to determine whether a executable might me compatible with the current architecture (the same as when we use file util). Meaning that we can avoid this at least for Mac.

g-ortuno · 2026-09-18T18:42:42Z

  if is_android(plt):
    plt = 'ANDROID'

+  arch = get_cpu_arch()


This would be a good opportunity to use get_target_cpu_arch.

g-ortuno · 2026-09-18T19:01:52Z

  plt = platform_override or platform()

  # Android resources share the same android directory.
  if is_android(plt):
    plt = 'ANDROID'

+  arch = get_cpu_arch()
+  if (not platform_override and plt != 'ANDROID' and arch and
+      not arch.startswith('x86')):
+    return os.path.join(get_resources_directory(), 'platform', plt.lower(),
+                        arch)
+
  return os.path.join(get_resources_directory(), 'platform', plt.lower())


What do you think of:

Suggested change

return os.path.join(get_resources_directory(), 'platform', plt.lower())

plt = platform_override or platform()

platform_directory = os.path.join(get_resources_directory(), 'platform')

# All Android variants share the same android directory. It holds host-side

# tools (adb, aapt) and device-side payloads (.apk), neither of which is

# keyed by host arch, so it is never arch-split.

if is_android(plt.upper()):

return os.path.join(platform_directory, 'android')

arch = get_host_cpu_arch()

if not arch or arch in _UNSUFFIXED_ARCHS:

return os.path.join(platform_directory, plt.lower())

return os.path.join(platform_directory, plt.lower(), arch)

g-ortuno · 2026-09-18T19:04:43Z

+    self.assertEqual('/resources/platform/linux',
+                     environment.get_platform_resources_directory())
+
+  def test_android(self):


We should test that ANDROID_X86, ANDROID_EMULATOR, ANDROID_AUTO, etc. all use /resources/platform/android?

g-ortuno · 2026-09-18T19:05:12Z

    self.mock.get_platform_resources_directory.assert_called_once_with('linux')
+
+
+class GetPlatformResourcesDirectoryTest(unittest.TestCase):


We should also have a test that passes a platform override.

g-ortuno · 2026-09-18T19:12:28Z

Up to you which dir structure you prefer! RE: the universal binary, that seems cool, but I think it adds another layer of complexity e.g. we would have to manually package all of our binaries. That seems more complicate than just downloading the right binaries to the right directory.

JuanMBriones requested a review from a team as a code owner September 9, 2026 02:18

JuanMBriones marked this pull request as draft September 9, 2026 02:18

JuanMBriones changed the title ~~wip: Fix radamsa binary for ARM64~~ Fix radamsa binary for ARM64 Sep 11, 2026

JuanMBriones added this pull request to stack #5469 September 11, 2026 19:47

JuanMBriones force-pushed the mac_arm64_coverage_guided_fuzzers_support_extra_deps branch 3 times, most recently from c8b03ac to 4f3a08a Compare September 14, 2026 23:07

JuanMBriones requested a review from g-ortuno September 14, 2026 23:09

JuanMBriones force-pushed the mac_arm64_coverage_guided_fuzzers_support_extra_deps branch from 4f3a08a to 2be786f Compare September 15, 2026 05:04

g-ortuno requested changes Sep 15, 2026

View reviewed changes

JuanMBriones force-pushed the mac_arm64_coverage_guided_fuzzers_support_extra_deps branch from 2be786f to e5981e0 Compare September 18, 2026 18:20

JuanMBriones added 2 commits September 18, 2026 18:29

JuanMBriones force-pushed the mac_arm64_coverage_guided_fuzzers_support_extra_deps branch from e5981e0 to a861dca Compare September 18, 2026 18:30

g-ortuno requested changes Sep 18, 2026

View reviewed changes

Navigation Menu

Fix radamsa binary for ARM64 - #5463

Fix radamsa binary for ARM64#5463
JuanMBriones wants to merge 2 commits into
masterfrom
mac_arm64_coverage_guided_fuzzers_support_extra_deps

JuanMBriones commented Sep 9, 2026 •

edited

Loading

Uh oh!

g-ortuno left a comment

Uh oh!

JuanMBriones commented Sep 18, 2026

Uh oh!

g-ortuno commented Sep 18, 2026

Uh oh!

JuanMBriones commented Sep 18, 2026 •

edited

Loading

Uh oh!

g-ortuno Sep 18, 2026

Uh oh!

g-ortuno Sep 18, 2026

Uh oh!

g-ortuno Sep 18, 2026

Uh oh!

g-ortuno Sep 18, 2026

Uh oh!

g-ortuno commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-  return os.path.join(get_resources_directory(), 'platform', plt.lower())
+plt = platform_override or platform()
+platform_directory = os.path.join(get_resources_directory(), 'platform')
+# All Android variants share the same android directory. It holds host-side
+# tools (adb, aapt) and device-side payloads (.apk), neither of which is
+# keyed by host arch, so it is never arch-split.
+if is_android(plt.upper()):
+  return os.path.join(platform_directory, 'android')
+arch = get_host_cpu_arch()
+if not arch or arch in _UNSUFFIXED_ARCHS:
+  return os.path.join(platform_directory, plt.lower())
+return os.path.join(platform_directory, plt.lower(), arch)

		self.mock.get_platform_resources_directory.assert_called_once_with('linux')


		class GetPlatformResourcesDirectoryTest(unittest.TestCase):

Conversation

JuanMBriones commented Sep 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

g-ortuno left a comment

Choose a reason for hiding this comment

Uh oh!

JuanMBriones commented Sep 18, 2026

Uh oh!

g-ortuno commented Sep 18, 2026

Uh oh!

JuanMBriones commented Sep 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

g-ortuno Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

g-ortuno Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

g-ortuno Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

g-ortuno Sep 18, 2026

Choose a reason for hiding this comment

Uh oh!

g-ortuno commented Sep 18, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

JuanMBriones commented Sep 9, 2026 •

edited

Loading

JuanMBriones commented Sep 18, 2026 •

edited

Loading