We need a slice of Codon PIE

[Charles-Kaminski]

Summary

I'd like to request explicit support for building position-independent executables (PIE) with Codon.

Codon currently appears to deliberately disable PIE linking for executables, even when the user supplies -pie through -linker-flags.

This behavior is understandable given the existing implementation, but it prevents users from selecting PIE for environments that require or benefit from position-independent executables.

I encountered this while developing a Codon HTTP server prototype running on Unikraft under QEMU/KVM to see if Codon could be supported in this environment.

Using a custom compiler wrapper, I was able to successfully build and execute the application as PIE so long as I also supported --relocation-model=pic in the tool chain.

Current Implementation

In Codon's source code, codon/cir/llvm/llvisitor.cpp, the executable linking process explicitly appends -no-pie after user-supplied linker flags.

Relevant source:

https://github.com/exaloop/codon/blob/3aca1a7d/codon/cir/llvm/llvisitor.cpp#L3157-L3186

llvm::SmallVector<llvm::StringRef> userFlags(16);
llvm::StringRef(lflags).split(userFlags, " ", /*MaxSplit=*/-1, /*KeepEmpty=*/false);

for (const auto &uflag : userFlags) {
  if (!uflag.empty())
    command.push_back(uflag.str());
}

// Avoid "relocation R_X86_64_32 against `.bss' can not be used when making a PIE
// object" complaints by gcc when it is built with --enable-default-pie
if (!library)
  command.push_back("-no-pie");

executeCommand(command);

The comment indicates that -no-pie was introduced to avoid relocation errors when linking non-position-independent object code on systems where GCC defaults to PIE.

Additionally, the object-generation path contains:

writeToObjectFile(objFile, /*pic=*/library);

This suggests that ordinary executables are generated without PIC by default, while libraries use position-independent code.

Consequently, supporting PIE properly should involve both object-code generation and linker configuration.

Motivation and Justification

PIE support would improve Codon's suitability for modern Linux deployments and systems-oriented applications.

Benefits include:

• ASLR: PIE enables executable code to be loaded at randomized addresses.
• Security hardening: PIE is commonly used in hardened Linux environments.
• Unikernel compatibility: Some unikernel execution environments require position-independent executables.
• Portability: Users can target environments with different executable-loading requirements.
• Toolchain flexibility: Users can explicitly select PIE or non-PIE without maintaining custom compiler wrappers.

In my case, Unikraft's Linux binary compatibility environment required a PIE executable.

After working around Codon's linker behavior, I successfully compiled and ran a Codon HTTP server on Unikraft.

Steps to Reproduce

Tested with Codon 0.20.3 on Ubuntu Linux (x86_64).

Create a minimal Codon application:

cat > hello.py <<'EOF'
print("Hello from Codon")
EOF

Attempt to compile it as PIE:

codon build -release \
    --relocation-model=pic \
    -linker-flags="-pie" \
    -o hello hello.py

Inspect the executable:

file hello
readelf -hW hello | grep 'Type:'
readelf -dW hello | grep 'FLAGS_1'

Actual Behavior

Codon appends -no-pie after the user-supplied -pie option.

The resulting executable is non-PIE:

Type: EXEC (Executable file)

Expected Behavior

When explicitly requesting PIE, Codon should generate position-independent object code and link it as a PIE executable.

The resulting executable should report:

Type: DYN (Position-Independent Executable file)

Ideally, the dynamic section should also contain:

FLAGS_1              Flags: PIE

Proposed Enhancement

Add explicit support for generating PIE executables.

Ideally, this would:

1. Allow users to request PIE through a dedicated option such as --pie, or through existing linker options.
2. Generate position-independent object code when PIE is requested.
3. Pass -pie to the linker without subsequently appending -no-pie.
4. Preserve the existing non-PIE behavior by default for backward compatibility.
5. Ensure that Codon's runtime and generated code support PIE linking correctly.

For example:

codon build -release --pie -o hello hello.py

Alternatively, the existing command could be supported:

codon build -release \
    --relocation-model=pic \
    -linker-flags="-pie" \
    -o hello hello.py

The important requirement is that the compiler consistently configure both code generation and linking for PIE.

Thank you!

[arshajii]

We'll look into adding this in the next release, @Charles-Kaminski -- thanks for bringing it up!

[Charles-Kaminski]

Great!

[Charles-Kaminski]

@arshajii You might also want to take a quick look at https://github.com/orgs/unikraft/discussions/1945. The discussion focuses on what Unikraft could do on its end to support Codon. I'd be interested in hearing your thoughts on my suggestions to the Unikraft team. Specifically, I propose a change to their compatibility layer that would allow Codon's garbage collector to work on Unikraft running under KVM. I'm also hoping that any comments you add to the thread might help bring more visibility to the discussion within the Unikraft team.

[arshajii]

Sure, happy to chime in on that thread and offer up help and support. The technical suggestion sounds reasonable to me, although I have limited knowledge of Unikraft & its internals.

By the way, we did add proper support for -pie in a soon-to-be-merged PR; you can give it a try with the Codon builds here: https://github.com/exaloop/codon/actions/runs/40128310596 (it should be merged & released in the next few days).

[Charles-Kaminski]

Fantastic! I appreciate both the comment in support of the change to Unikraft and the fast turnaround on PIE support.