[PATCH] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[PATCH] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[Giuliano Procida]

Previously, `EXPORT_SYMBOL_RUST_GPL(sym)` declared `extern int sym;` so
that it could invoke `EXPORT_SYMBOL_GPL(sym)`, which required `sym` to
be a declared C identifier for `typeof(sym)`, `__ADDRESSABLE(sym)`, and
(when `CONFIG_GENDWARFKSYMS` is enabled) `__GENDWARFKSYMS_EXPORT(sym)`.

This resulted in the compiler emiting DWARF debug information in
`rust/exports.o` describing every exported Rust symbol—functions and
data alike, as a C `int` variable.

Although `rust/Makefile` sets `skip_gendwarfksyms = 1` on `exports.o`,
the bogus `int` DWARF entries were still present in `vmlinux`, where
they conflicted with the true DWARF types emitted by `rustc` and
confused DWARF consumers such as debuggers and ABI analysis tools.

This change defines `EXPORT_SYMBOL_RUST_GPL(sym)` using
`___EXPORT_SYMBOL` directly:

	asm(__stringify(___EXPORT_SYMBOL(sym, "GPL", "")))

matching the `__ASSEMBLY__` path in `include/linux/export.h`.

Omitting the C-level wrappers from `__EXPORT_SYMBOL` is safe because:
- `__GENDWARFKSYMS_EXPORT(sym)` is unneeded because `gendwarfksyms` runs
  directly on the defining Rust and helper object files and is already
  disabled for `rust/exports.o`.
- `extern int sym;`, `extern typeof(sym) sym;`, and `__ADDRESSABLE(sym)`
  have no effect in `rust/exports.c`: the symbols are already emitted in
  separate translation units (scraped via `nm --defined-only`), the fake
  `extern int` declaration never produced kCFI function type IDs, and
  `___EXPORT_SYMBOL` already emits a `.quad`/`.long` reference to `sym`
  in `.export_symbol` that satisfies both ELF linking and LTO module-asm
  symbol resolution.
- `DEFAULT_SYMBOL_NAMESPACE`, `__DISABLE_EXPORTS`, `__PKVM_HYP__`, and
  `__GENKSYMS__` are not used by `rust/exports.c`.

Signed-off-by: Giuliano Procida <gprocida@google.com>
---
 rust/exports.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/rust/exports.c b/rust/exports.c
index 1b52460b0f4e..7d094d0dea1c 100644
--- a/rust/exports.c
+++ b/rust/exports.c
@@ -1,19 +1,20 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * A hack to export Rust symbols for loadable modules without having to redo
- * the entire `include/linux/export.h` logic in Rust.
+ * Export Rust symbols for loadable modules using similar logic to that in
+ * `include/linux/export.h`.
  *
  * This requires Rust's new/future `v0` mangling scheme because the default one
  * ("legacy") uses invalid characters for C identifiers (thus we cannot use the
  * `EXPORT_SYMBOL_*` macros).
  *
  * All symbols are exported as GPL-only to guarantee no GPL-only feature is
- * accidentally exposed.
+ * accidentally exposed. There is no support for symbol namespaces.
  */
 
 #include <linux/export.h>
 
-#define EXPORT_SYMBOL_RUST_GPL(sym) extern int sym; EXPORT_SYMBOL_GPL(sym)
+#define EXPORT_SYMBOL_RUST_GPL(sym)				\
+	asm(__stringify(___EXPORT_SYMBOL(sym, "GPL", "")))
 
 #include "exports_core_generated.h"
 #include "exports_bindings_generated.h"
-- 
2.56.0.212.g129ede20d9-goog

Re: [PATCH] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[Sami Tolvanen]

On Mon, Oct 19, 2026 at 8:13 AM Giuliano Procida <gprocida@google.com> wrote:
>
> Previously, `EXPORT_SYMBOL_RUST_GPL(sym)` declared `extern int sym;` so
> that it could invoke `EXPORT_SYMBOL_GPL(sym)`, which required `sym` to
> be a declared C identifier for `typeof(sym)`, `__ADDRESSABLE(sym)`, and
> (when `CONFIG_GENDWARFKSYMS` is enabled) `__GENDWARFKSYMS_EXPORT(sym)`.
>
> This resulted in the compiler emiting DWARF debug information in
> `rust/exports.o` describing every exported Rust symbol—functions and
> data alike, as a C `int` variable.
>
> Although `rust/Makefile` sets `skip_gendwarfksyms = 1` on `exports.o`,
> the bogus `int` DWARF entries were still present in `vmlinux`, where
> they conflicted with the true DWARF types emitted by `rustc` and
> confused DWARF consumers such as debuggers and ABI analysis tools.
>
> This change defines `EXPORT_SYMBOL_RUST_GPL(sym)` using
> `___EXPORT_SYMBOL` directly:
>
>         asm(__stringify(___EXPORT_SYMBOL(sym, "GPL", "")))
>
> matching the `__ASSEMBLY__` path in `include/linux/export.h`.
>
> Omitting the C-level wrappers from `__EXPORT_SYMBOL` is safe because:
> - `__GENDWARFKSYMS_EXPORT(sym)` is unneeded because `gendwarfksyms` runs
>   directly on the defining Rust and helper object files and is already
>   disabled for `rust/exports.o`.
> - `extern int sym;`, `extern typeof(sym) sym;`, and `__ADDRESSABLE(sym)`
>   have no effect in `rust/exports.c`: the symbols are already emitted in
>   separate translation units (scraped via `nm --defined-only`), the fake
>   `extern int` declaration never produced kCFI function type IDs, and
>   `___EXPORT_SYMBOL` already emits a `.quad`/`.long` reference to `sym`
>   in `.export_symbol` that satisfies both ELF linking and LTO module-asm
>   symbol resolution.
> - `DEFAULT_SYMBOL_NAMESPACE`, `__DISABLE_EXPORTS`, `__PKVM_HYP__`, and
>   `__GENKSYMS__` are not used by `rust/exports.c`.
>
> Signed-off-by: Giuliano Procida <gprocida@google.com>

Reviewed-by: Sami Tolvanen <samitolvanen@google.com>

Sami

Re: [PATCH] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[Miguel Ojeda]

On Mon, Oct 19, 2026 at 5:13 PM Giuliano Procida <gprocida@google.com> wrote:
>
> This change defines `EXPORT_SYMBOL_RUST_GPL(sym)` using
> `___EXPORT_SYMBOL` directly:
>
>         asm(__stringify(___EXPORT_SYMBOL(sym, "GPL", "")))
>
> matching the `__ASSEMBLY__` path in `include/linux/export.h`.

Hmm... It says it matches the `__ASSEMBLY__` path, but it matches the
`#else` path, no?

Cc'ing the `RUST` entry and modules too.

In addition, I wonder if we should avoid hardcoding the particular
form of that `asm(...` and instead expose it from the C header. That
way we avoid repetition and getting it out-of-sync -- that was part of
the original reasoning.

By the way, I am right that you noticed this via GCC builds?

(Nit: please write the commit message in the imperative form:
https://docs.kernel.org/process/submitting-patches.html#describe-your-changes)

Thanks!

Cheers,
Miguel

Re: [PATCH] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[Petr Pavlu]

On 10/20/26 9:22 PM, Miguel Ojeda wrote:
> On Mon, Oct 19, 2026 at 5:13 PM Giuliano Procida <gprocida@google.com> wrote:
>>
>> This change defines `EXPORT_SYMBOL_RUST_GPL(sym)` using
>> `___EXPORT_SYMBOL` directly:
>>
>>         asm(__stringify(___EXPORT_SYMBOL(sym, "GPL", "")))
>>
>> matching the `__ASSEMBLY__` path in `include/linux/export.h`.
> 
> Hmm... It says it matches the `__ASSEMBLY__` path, but it matches the
> `#else` path, no?
> 
> Cc'ing the `RUST` entry and modules too.
> 
> In addition, I wonder if we should avoid hardcoding the particular
> form of that `asm(...` and instead expose it from the C header. That
> way we avoid repetition and getting it out-of-sync -- that was part of
> the original reasoning.

It should be also ok to move EXPORT_SYMBOL_RUST_GPL() directly into
include/linux/export.h.

-- Petr

Re: [PATCH] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[Miguel Ojeda]

On Wed, Oct 21, 2026 at 11:27 AM Petr Pavlu <petr.pavlu@suse.com> wrote:
>
> It should be also ok to move EXPORT_SYMBOL_RUST_GPL() directly into
> include/linux/export.h.

Yeah, that sounds great to me. Probably with a small comment added,
and removing the one in Nova too (which this patch should do anyway --
it is going away, but still).

Cheers,
Miguel

Re: [PATCH] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[Giuliano Procida]

Hi.

On Tue, 20 Oct 2026 at 20:22, Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Mon, Oct 19, 2026 at 5:13 PM Giuliano Procida <gprocida@google.com> wrote:
> >
> > This change defines `EXPORT_SYMBOL_RUST_GPL(sym)` using
> > `___EXPORT_SYMBOL` directly:
> >
> >         asm(__stringify(___EXPORT_SYMBOL(sym, "GPL", "")))
> >
> > matching the `__ASSEMBLY__` path in `include/linux/export.h`.
>
> Hmm... It says it matches the `__ASSEMBLY__` path, but it matches the
> `#else` path, no?

The description was AI generated, but it is accurate. Both paths use the
triple-underscore three-argument macro alone.

...
#elif defined(__ASSEMBLY__)

#define __EXPORT_SYMBOL(sym, license, ns) \
        ___EXPORT_SYMBOL(sym, license, ns)

#else
...

> Cc'ing the `RUST` entry and modules too.
>
> In addition, I wonder if we should avoid hardcoding the particular
> form of that `asm(...` and instead expose it from the C header. That
> way we avoid repetition and getting it out-of-sync -- that was part of
> the original reasoning.

I wondered the same thing, but that would introduce yet another intermediate
macro.

> By the way, I am right that you noticed this via GCC builds?

No, Android kernels have been built with Clang for years.

We post-process DWARF information with STG for ABI purposes and noticed
this interesting side effect there.

> (Nit: please write the commit message in the imperative form:
> https://docs.kernel.org/process/submitting-patches.html#describe-your-changes)

I will do so in the next version.

> Thanks!
>
> Cheers,
> Miguel

Re: [PATCH] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[Miguel Ojeda]

On Wed, Oct 21, 2026 at 4:21 PM Giuliano Procida <gprocida@google.com> wrote:
>
> The description was AI generated, but it is accurate. Both paths use the
> triple-underscore three-argument macro alone.

Yeah, I understand that not having the `extern` and so on is what the
AI wants to emphasize here, instead of the `asm(...` wrapping of the
`#else` side, but it sounds confusing to me, i.e. it introduces the
change as if matching the assembly path was important for some reason
in particular.

> I wondered the same thing, but that would introduce yet another intermediate
> macro.

We are introducing a macro either way -- in fact we have to introduce
it twice if we don't do it centrally.

I guess you mean avoiding the duplication in the C header, but that
duplication already exists in this version. So if no new intermediate
macro is preferred, then at least the duplication would be more local
and thus more obvious when they both need to be updated.

> No, Android kernels have been built with Clang for years.
>
> We post-process DWARF information with STG for ABI purposes and noticed
> this interesting side effect there.

Ah, nevermind, I checked the DWARF emitted by Clang, but without
gendwarfksyms, my bad (I am aware of Android using Clang, of course;
it is why it sounded strange and wanted to double-check if it was
related to GCC somehow).

Thanks!

Cheers,
Miguel

[PATCH v2 0/2] clean up EXPORT_SYMBOL_RUST_GPL

[Giuliano Procida]

The two separate patches now move EXPORT_SYMBOL_RUST_GPL definitions
into linux/export.h and prevent the emission of bogus type information
for Rust symbols.

Giuliano Procida (2):
  rust: move EXPORT_SYMBOL_RUST_GPL to include/linux/export.h
  rust: exports: emit ___EXPORT_SYMBOL without C declarations

 drivers/gpu/Makefile                      |  4 ++--
 drivers/gpu/nova-core/nova_core_exports.c |  2 --
 include/linux/export.h                    | 14 ++++++++++++++
 rust/exports.c                            | 12 +-----------
 4 files changed, 17 insertions(+), 15 deletions(-)

-- 
2.56.0.218.g1ec904b173-goog

[PATCH v2 1/2] rust: move EXPORT_SYMBOL_RUST_GPL to include/linux/export.h

[Giuliano Procida]

Move identical definitions of `EXPORT_SYMBOL_RUST_GPL` to
`include/linux/export.h` from:

- `rust/exports.c`
- `drivers/gpu/nova-core/nova_core_exports.c`

Both files already include `<linux/export.h>`.

Signed-off-by: Giuliano Procida <gprocida@google.com>
---
 drivers/gpu/nova-core/nova_core_exports.c |  2 --
 include/linux/export.h                    | 13 +++++++++++++
 rust/exports.c                            | 12 +-----------
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/nova-core/nova_core_exports.c b/drivers/gpu/nova-core/nova_core_exports.c
index 6e80ca9792ee..480472b039db 100644
--- a/drivers/gpu/nova-core/nova_core_exports.c
+++ b/drivers/gpu/nova-core/nova_core_exports.c
@@ -10,6 +10,4 @@
 
 #include <linux/export.h>
 
-#define EXPORT_SYMBOL_RUST_GPL(sym) extern int sym; EXPORT_SYMBOL_GPL(sym)
-
 #include "exports_nova_core_generated.h"
diff --git a/include/linux/export.h b/include/linux/export.h
index a686fd0ba406..4aeb422d86af 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -93,4 +93,17 @@
 
 #define EXPORT_SYMBOL_FOR_MODULES(sym, mods) __EXPORT_SYMBOL(sym, "GPL", "module:" mods)
 
+/*
+ * A hack to export Rust symbols for loadable modules without having to redo
+ * the entire `EXPORT_SYMBOL_GPL` logic in Rust.
+ *
+ * This requires Rust's new/future `v0` mangling scheme because the default one
+ * ("legacy") uses invalid characters for C identifiers (thus we cannot use the
+ * `EXPORT_SYMBOL_*` macros).
+ *
+ * All symbols are exported as GPL-only to guarantee no GPL-only feature is
+ * accidentally exposed.
+ */
+#define EXPORT_SYMBOL_RUST_GPL(sym) extern int sym; EXPORT_SYMBOL_GPL(sym)
+
 #endif /* _LINUX_EXPORT_H */
diff --git a/rust/exports.c b/rust/exports.c
index 1b52460b0f4e..8b2dd4aa1f92 100644
--- a/rust/exports.c
+++ b/rust/exports.c
@@ -1,20 +1,10 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * A hack to export Rust symbols for loadable modules without having to redo
- * the entire `include/linux/export.h` logic in Rust.
- *
- * This requires Rust's new/future `v0` mangling scheme because the default one
- * ("legacy") uses invalid characters for C identifiers (thus we cannot use the
- * `EXPORT_SYMBOL_*` macros).
- *
- * All symbols are exported as GPL-only to guarantee no GPL-only feature is
- * accidentally exposed.
+ * Export symbols from the `rust/` crates and C helpers for loadable modules.
  */
 
 #include <linux/export.h>
 
-#define EXPORT_SYMBOL_RUST_GPL(sym) extern int sym; EXPORT_SYMBOL_GPL(sym)
-
 #include "exports_core_generated.h"
 #include "exports_bindings_generated.h"
 #include "exports_kernel_generated.h"
-- 
2.56.0.218.g1ec904b173-goog

[PATCH v2 2/2] rust: exports: emit ___EXPORT_SYMBOL without C declarations

[Giuliano Procida]

Define `EXPORT_SYMBOL_RUST_GPL(sym)` using `___EXPORT_SYMBOL` directly:

	asm(__stringify(___EXPORT_SYMBOL(sym, "GPL", "")))

matching the `__ASSEMBLY__` path.

Previously, `EXPORT_SYMBOL_RUST_GPL(sym)` declared `extern int sym;` so
that it could invoke `EXPORT_SYMBOL_GPL(sym)`, which required `sym` to
be a declared C identifier for `typeof(sym)`, `__ADDRESSABLE(sym)`, and
(when `CONFIG_GENDWARFKSYMS` is enabled) `__GENDWARFKSYMS_EXPORT(sym)`.

This resulted in the compiler emitting DWARF debug information in
`rust/exports.o` and `drivers/gpu/nova-core/nova_core_exports.o`
describing every exported Rust symbol, functions and data alike, as a C
`int` variable.

Although `rust/Makefile` sets `skip_gendwarfksyms = 1` on `exports.o`
and `drivers/gpu/Makefile` runs `gendwarfksyms` on `nova_core.o` rather
than `nova_core_exports.o`, the bogus `int` DWARF entries were still
present in `vmlinux` and `nova-core.ko`, where they conflicted with the
true DWARF types emitted by `rustc` and confused DWARF consumers such as
debuggers and ABI analysis tools.

Omitting the C-level wrappers from `__EXPORT_SYMBOL` is safe because:
- `__GENDWARFKSYMS_EXPORT(sym)` is unneeded because `gendwarfksyms` runs
  directly on the defining Rust and helper object files rather than on
  `rust/exports.o` or `nova_core_exports.o`.
- `extern int sym;`, `extern typeof(sym) sym;`, and `__ADDRESSABLE(sym)`
  have no effect in `rust/exports.c` or `nova_core_exports.c`: the
  symbols are already emitted in separate translation units (scraped via
  `nm --defined-only`), the fake `extern int` declaration never produced
  kCFI function type IDs, and `___EXPORT_SYMBOL` already emits a
  `.quad`/`.long` reference to `sym` in `.export_symbol` that satisfies
  both ELF linking and LTO module-asm symbol resolution.
- `DEFAULT_SYMBOL_NAMESPACE`, `__DISABLE_EXPORTS`, and `__GENKSYMS__`
  are not used by `rust/exports.c` or `nova_core_exports.c`.

Signed-off-by: Giuliano Procida <gprocida@google.com>
---
 drivers/gpu/Makefile   | 4 ++--
 include/linux/export.h | 9 +++++----
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index e372fc02139f..1269ce862ad2 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -47,8 +47,8 @@ $(obj)/nova-core/nova_core_exports.o: $(obj)/nova-core/exports_nova_core_generat
 CFLAGS_nova-core/nova_core_exports.o := -I $(objtree)/$(obj)/nova-core
 
 ifdef CONFIG_MODVERSIONS
-# The C export shim declares Rust symbols as `extern int`, so reuse its export
-# list but generate symbol CRCs from the Rust object instead of the shim's DWARF.
+# The C export shim has no DWARF type info for Rust symbols, so reuse
+# its export list but generate symbol CRCs from the Rust object.
 $(obj)/nova-core/nova_core_exports.o: private cmd_gensymtypes_c = \
 	$(call getexportsymbols,\1) | \
 	$(objtree)/scripts/gendwarfksyms/gendwarfksyms \
diff --git a/include/linux/export.h b/include/linux/export.h
index 4aeb422d86af..2a0362cc54e1 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -94,16 +94,17 @@
 #define EXPORT_SYMBOL_FOR_MODULES(sym, mods) __EXPORT_SYMBOL(sym, "GPL", "module:" mods)
 
 /*
- * A hack to export Rust symbols for loadable modules without having to redo
- * the entire `EXPORT_SYMBOL_GPL` logic in Rust.
+ * Export Rust symbols for loadable modules without having to redo the entire
+ * `EXPORT_SYMBOL_GPL` logic in Rust.
  *
  * This requires Rust's new/future `v0` mangling scheme because the default one
  * ("legacy") uses invalid characters for C identifiers (thus we cannot use the
  * `EXPORT_SYMBOL_*` macros).
  *
  * All symbols are exported as GPL-only to guarantee no GPL-only feature is
- * accidentally exposed.
+ * accidentally exposed. There is no support for symbol namespaces.
  */
-#define EXPORT_SYMBOL_RUST_GPL(sym) extern int sym; EXPORT_SYMBOL_GPL(sym)
+#define EXPORT_SYMBOL_RUST_GPL(sym)				\
+	asm(__stringify(___EXPORT_SYMBOL(sym, "GPL", "")))
 
 #endif /* _LINUX_EXPORT_H */
-- 
2.56.0.218.g1ec904b173-goog