Skip to content

[CodeGen][ObjC] Initial WebAssembly Support for GNUstep #169043

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
hmelder wants to merge 4 commits into
base: main
Choose a base branch
from
+36 −5
Open

[CodeGen][ObjC] Initial WebAssembly Support for GNUstep #169043

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
a07542b
[clang] Whitelist wasm when targeting GNUstep 2.x
hmelder Nov 21, 2025
0ee0356
[CodeGen][ObjC] Mangle public symbols for wasm
hmelder Nov 21, 2025
45e7f44
[CodeGen][ObjC] Fix class_registerAlias_np signature
hmelder Nov 21, 2025
8ad5d24
[CodeGen][ObjC] Add WASM symbol mangling test
hmelder Nov 28, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 11 additions & 4 deletions clang/lib/CodeGen/CGObjCGNU.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -179,8 +179,16 @@ class CGObjCGNU : public CGObjCRuntime {
(R.getVersion() >= VersionTuple(major, minor));
}

std::string ManglePublicSymbol(StringRef Name) {
return (StringRef(CGM.getTriple().isOSBinFormatCOFF() ? "$_" : "._") + Name).str();
const std::string ManglePublicSymbol(StringRef Name) {
StringRef prefix = "._";

// Exported symbols in Emscripten must be a valid Javascript identifier.
auto triple = CGM.getTriple();
if (triple.isOSBinFormatCOFF() || triple.isOSBinFormatWasm()) {
Copy link
Member

@dschuff dschuff Dec 5, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The restriction on valid JS identifiers is specific to Emscripten rather than wasm as a whole, so you might want to check for isOSEmscripten here rather than the bin format. But if you want to have a common ABI across Emscripten and WASI, then this would be OK with me too.

Copy link
Collaborator

@sbc100 sbc100 Dec 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should maybe fix emscripten to deal with these symbols instead of patching here?

Copy link
Member

@dschuff dschuff Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that makes sense. we could just do a similar prefix or substitution as the one here? If the export name is invalid, we could just mangle the symbol on the Module object? Or have an alias so Module[".realSymbol"] could keep working?

Copy link
Collaborator

@sbc100 sbc100 Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we can do that. But remember that symbols are also available directly in the module scope as normal variables.

e.g. One can just write _malloc for symbols that are not exported on the Module. For exported symbols one can also write Module['_malloc']. So this change would just mean that symbol are that not valid JS symbol names would not be accessible via the first method... which is an odd difference but maybe better than "link failure" ?

Copy link
Member

@dschuff dschuff Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, better than link failure I think. And given that the map style accessors aren't going away, maybe it's sufficient to just leave it at that. where if you have invalid identifiers, you just need to use that method (as opposed to trying to mangle them and change the symbol name altogether?)

Copy link
Collaborator

@sbc100 sbc100 Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, I'll look into fixing this now on the emscripten side. We have an open bug there already: emscripten-core/emscripten#24825

Copy link
Member

@dschuff dschuff Dec 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hmelder / @HendrikHuebner Would Sam's Emscripten change be useful for the objc use case?

Copy link
Contributor Author

@hmelder hmelder Dec 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The restriction on valid JS identifiers is specific to Emscripten rather than wasm as a whole, so you might want to check for isOSEmscripten here rather than the bin format. But if you want to have a common ABI across Emscripten and WASI, then this would be OK with me too.

I think it does not really matter whether we use $ or . and I would prefer to not add more complexity into the conditional.

We should maybe fix emscripten to deal with these symbols instead of patching here?
[...]
So this change would just mean that symbol are that not valid JS symbol names would not be accessible via the first method... which is an odd difference but maybe better than "link failure" ?

We mangle the symbols so that they are not directly usable by the user in a C program, or at least this was the original intend with . on ELF. AFAIK there is an extension that allows $ to be used in a C identifier which is why Emscripten supports it in the first place.

You can change this in Emscripten but it does not really matter for our use case.

prefix = "$_";
}

return (prefix + Name).str();
}

std::string SymbolForProtocol(Twine Name) {
Expand Down Expand Up @@ -4106,8 +4114,7 @@ llvm::Function *CGObjCGNU::ModuleInitFunction() {
if (!ClassAliases.empty()) {
llvm::Type *ArgTypes[2] = {PtrTy, PtrToInt8Ty};
llvm::FunctionType *RegisterAliasTy =
llvm::FunctionType::get(Builder.getVoidTy(),
ArgTypes, false);
llvm::FunctionType::get(BoolTy, ArgTypes, false);
llvm::Function *RegisterAlias = llvm::Function::Create(
RegisterAliasTy,
llvm::GlobalValue::ExternalWeakLinkage, "class_registerAlias_np",
Expand Down
3 changes: 2 additions & 1 deletion clang/lib/Driver/ToolChains/Clang.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8001,7 +8001,8 @@ ObjCRuntime Clang::AddObjCRuntimeArgs(const ArgList &args,
if ((runtime.getKind() == ObjCRuntime::GNUstep) &&
(runtime.getVersion() >= VersionTuple(2, 0)))
if (!getToolChain().getTriple().isOSBinFormatELF() &&
!getToolChain().getTriple().isOSBinFormatCOFF()) {
!getToolChain().getTriple().isOSBinFormatCOFF() &&
!getToolChain().getTriple().isOSBinFormatWasm()) {
getToolChain().getDriver().Diag(
diag::err_drv_gnustep_objc_runtime_incompatible_binary)
<< runtime.getVersion().getMajor();
Expand Down
23 changes: 23 additions & 0 deletions clang/test/CodeGenObjC/gnustep2-wasm32-symbols.m
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
// RUN: %clang_cc1 -triple wasm32-unknown-emscripten -emit-llvm -fobjc-runtime=gnustep-2.2 -o - %s | FileCheck %s

@class NSString;

@protocol AProtocol
- (void) meth;
@end

@interface AClass <AProtocol>
@end

@implementation AClass
- (void) meth {}
@end

// Make sure that all public symbols are mangled correctly. All exported symbols
// must be valid Javascript identifiers in Emscripten.
// CHECK: $"$_OBJC_PROTOCOL_AProtocol" = comdat any
// CHECK: @"$_OBJC_METACLASS_AClass"
// CHECK: @"$_OBJC_PROTOCOL_AProtocol"
// CHECK: @"$_OBJC_CLASS_AClass"
// CHECK: @"$_OBJC_REF_CLASS_AClass"
// CHECK: @"$_OBJC_INIT_CLASS_AClass"