Static and const variables definitions ignore visiblity and link section

[sutajo]

I am working on an Emscripten library for Rust, and Emscripten itself heavily relies on link time trickery, which breaks when symbols are not exported with the right visibility, into the right section.

The following code produces unexpected results:

#[used]
#[unsafe(no_mangle)]
#[unsafe(link_section = "mysection")]
pub static MYSCRIPT: [u8; 16] = *b" return $0 + $1;";

let result = unsafe {
      emscripten_asm_const_int(MYSCRIPT.as_ptr() as _, c"ii".as_ptr(), 10, 43)
};

I expected to see MYSCRIPT in the LLVM IR to use global, placed into mysection.

Instead, I saw the following in the IR:

@MYSCRIPT = internal constant [16 x i8] c" return $0 + $1;", align 1, !dbg !0
...
@llvm.used = appending global [1 x ptr] [ptr @MYSCRIPT], section "llvm.metadata"

It is clearly visible that the #[used] attribute is respected.
However, the section is not forwarded to the declaration and internal constant is also incorrect, because I want to export the symbol globally.

Meta

rustc --version --verbose:

rustc 1.91.0-nightly (02c7b1a7a 2025-09-13)
binary: rustc
commit-hash: 02c7b1a7ac1d739663878030510508372e46f254
commit-date: 2025-09-13
host: x86_64-pc-windows-msvc
release: 1.91.0-nightly
LLVM version: 21.1.1

[bjorn3]

On wasm targets #[link_section] will generate a custom wasm section through

!wasm.custom_sections  = { !1 }
!1 = !{!"mysection", !" return $0 + $1;"}

However because custom wasm sections don't have a location in memory while rust statics do, rustc generates a copy of the static to put in the linear memory. This is the @MYSCRIPT = internal constant [16 x i8] c" return $0 + $1;", align 1, !dbg !0 you see without section identifier. This is implemented at

rust/compiler/rustc_codegen_llvm/src/consts.rs

Lines 473 to 505 in ddaf123

	// Wasm statics with custom link sections get special treatment as they
	// go into custom sections of the wasm executable. The exception to this
	// is the `.init_array` section which are treated specially by the wasm linker.
	if self.tcx.sess.target.is_like_wasm
	&& attrs
	.link_section
	.map(|link_section| !link_section.as_str().starts_with(".init_array"))
	.unwrap_or(true)
	{
	if let Some(section) = attrs.link_section {
	let section = self.create_metadata(section.as_str().as_bytes());
	assert!(alloc.provenance().ptrs().is_empty());
	// The `inspect` method is okay here because we checked for provenance, and
	// because we are doing this access to inspect the final interpreter state (not
	// as part of the interpreter execution).
	let bytes = alloc.inspect_with_uninit_and_ptr_outside_interpreter(0..alloc.len());
	let alloc = self.create_metadata(bytes);
	let data = [section, alloc];
	let meta =
	unsafe { llvm::LLVMMDNodeInContext2(self.llcx, data.as_ptr(), data.len()) };
	let val = self.get_metadata_value(meta);
	unsafe {
	llvm::LLVMAddNamedMetadataOperand(
	self.llmod,
	c"wasm.custom_sections".as_ptr(),
	val,
	)
	};
	}
	} else {
	base::set_link_section(g, attrs);
	}

[sutajo]

Clang does not seem to emit custom sections for wasm: https://godbolt.org/z/fahs89v8z
Here is a diff of the two approaches: https://godbolt.org/z/48h1hYGGs

It would be better to have fine grained control over this, something like
#[unsafe(link_section(name = "mysection", custom_wasm_section = true))]
This would tell rustc to create a duplicate .custom_section.mysection and put a duplicate there.

Regardless if a custom section is created or not, the constant/static must go into .mysection, otherwise the attribute becomes pretty misleading.

[bjorn3]

Custom sections are as close to real sections as you get with plain wasm. It seems that clang will used named data segments if you specify a custom section. These only defined within the linking custom section and thus become indistinguishable from globals without section specified after linking.

It seems that before #52353 there was a separate #[wasm_custom_section] attribute. This PR is from the early days of wasm before the wasm support in LLVM was even stable and only a couple months after named data segments were added to the specification for the linking section in WebAssembly/tool-conventions#43 (and it was added to LLVM a couple months prior: llvm/llvm-project@d95ed95). I guess someone missed that support for this was introduced in the first place.