How to efficiently execute the .so file generated by the Solang compiler?

[Subway2023]

I placed the .so program generated by the solang compiler into rbpf for execution, but encountered an error.

test.sol

contract C {
    function f() public pure returns (uint r1)
    {
        uint8 a=0;
        r1=a+1234;
    }
}

input.txt (26121ff0 is the selector of function f)

26121ff0

./solang-linux-x86-64 compile ./test.sol --target solana --output ./build
git clone https://github.com/solana-labs/rbpf
cd cli

cargo run -- -u interpreter --mem 9999999999 --input input.txt --elf ./C.so --trace >> ./temp.txt

mem: [50, 54, 49, 50, 49, 102, 102, 48]
Result: Err(AccessViolation(Load, 17179869192, 1, "input"))
Instruction Count: 14
Trace:

    0 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200001000]  5733: lddw r0, 0x200000000
    1 [0000000200000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200001000]  5735: jeq r1, 0, lbb_5891
    2 [0000000200000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200001000]  5736: ldxdw r7, [r1+0x0]
    3 [0000000200000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5737: stxdw [r10-0x30], r7
    4 [0000000200000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5738: jeq r7, 0, lbb_5865
    5 [0000000200000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5739: mov64 r0, r1
    6 [0000000400000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5740: add64 r0, 8
    7 [0000000400000008, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5741: mov64 r2, 0
    8 [0000000400000008, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5742: mov64 r3, r10
    9 [0000000400000008, 0000000400000000, 0000000000000000, 0000000200001000, 0000000000000000, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5743: add64 r3, -558
   10 [0000000400000008, 0000000400000000, 0000000000000000, 0000000200000DD2, 0000000000000000, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5744: mov64 r4, 10
   11 [0000000400000008, 0000000400000000, 0000000000000000, 0000000200000DD2, 000000000000000A, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5745: ja lbb_5812
   12 [0000000400000008, 0000000400000000, 0000000000000000, 0000000200000DD2, 000000000000000A, 0000000000000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5812: mov64 r5, r1
   13 [0000000400000008, 0000000400000000, 0000000000000000, 0000000200000DD2, 000000000000000A, 0000000400000000, 0000000000000000, 3066663132313632, 0000000000000000, 0000000000000000, 0000000200001000]  5813: ldxb r6, [r5+0x8]

My question: How to correctly call the f() function and retrieve the return value?

[0rlych1kk4]

How to Efficiently Execute the .so File Generated by Solang Compiler for Solana

Hi @Subway2023, I see you're trying to execute the .so file compiled from Solang directly using rbpf, but you're running into an AccessViolation error. Based on your setup, I believe the issue could be related to incorrect input encoding or how Solana BPF programs expect structured data.

Possible Causes & Fixes

1. Incorrect ABI Encoding for Input Data
Your input file contains only the function selector (26121ff0), but Solana programs require structured input encoding (Borsh or SPL-compatible). The error suggests an invalid memory access when trying to load input data.

Fix: Use Proper Borsh Encoding for Inputs

Instead of directly using 26121ff0, encode it in Borsh format before passing it as input. You can generate the properly encoded input using Rust:

use solana_program::borsh::try_to_vec;
use borsh::BorshSerialize;

#[derive(BorshSerialize)]
struct Input {
selector: [u8; 4],
}

fn main() {
let data = Input {
selector: [0x26, 0x12, 0x1f, 0xf0],
};

let encoded = try_to_vec(&data).unwrap();
std::fs::write("input.txt", encoded).expect("Failed to write input");

}
Now, use the generated input.txt instead of raw function selectors.

2. ELF File Might Not Be a Valid Solana BPF Program
Solana smart contracts need a specific entrypoint (entrypoint!()). If your .so file isn't structured as a valid Solana program, rbpf might not execute it correctly.

Fix: Verify the ELF Format

Run:

readelf -h ./C.so
Ensure:

e_machine is EM_BPF (should be targeting eBPF for Solana).
Type is EXEC (executable file).
Entry point address is valid.
If it's not structured correctly, try recompiling it using:

solang compile test.sol --target solana --emit llvm-bc,llvm-ir,object,asm --output build/
3. Execute Using Solana's Local Test Validator Instead of rbpf
Instead of manually running via rbpf, a more reliable way to test execution is by deploying the .so file as a Solana program.

Steps to Deploy & Execute the .so file

1. Start a Local Solana Test Validator

solana-test-validator
2. Deploy the .so file

solana program deploy C.so
3. Call the function using Solana CLI or a Rust client Use solana program invoke to interact with the deployed contract.

[Subway2023]

When I run solana-ledger-tool program run --help, it prompts me that the format of input.txt is as follows. How should I fill in the data inside, such as data and instruction_data?

solana-ledger-tool program run --help

   -i, --input <FILE / BYTES>
            Input for the program to run on, where FILE is a name of a JSON file
            with input data, or BYTES is the number of 0-valued bytes to allocate for program parameters"
            
            The input data for a program execution have to be in JSON format
            and the following fields are required
            {
                "program_id": "DozgQiYtGbdyniV2T74xMdmjZJvYDzoRFFqw7UR5MwPK",
                "accounts": [
                    {
                        "key": "524HMdYYBy6TAn4dK5vCcjiTmT2sxV6Xoue5EXrz22Ca",
                        "owner": "BPFLoaderUpgradeab1e11111111111111111111111",
                        "is_signer": false,
                        "is_writable": true,
                        "lamports": 1000,
                        "data": [0, 0, 0, 3]
                    }
                ],
                "instruction_data": [31, 32, 23, 24]
            }

[0rlych1kk4]

This strongly shows that 8589934592 (0x200000000) is a memory pointer, not the actual returned value. This means the actual return value is stored in memory at address 0x200000000. To retrieve the correct return value, you need to read from this memory location.

1: Inspect what’s stored at 0x200000000, you need to dump the memory after execution.
Run the program with additional debugging:
RUST_LOG=debug solana-ledger-tool program run C.so --input input.txt --ledger test-ledger --trace test.trace

Then, open test.trace and look for:

• Any stxdw or stdw (store double word) instructions.
• The contents of r0 before exit.

2: If you suspect that 0x200000000 contains the actual value, you can manually extract it from memory.

    a. )  Search the memory section  and run:
            objdump -s -j .data C.so
   or
            readelf -x .data C.so

    in order for you to dump the memory sections of the compiled ELF.

   b.)  Look at Address 0x200000000 since solana allocates a memory region for return values, you should check the contents       at that location

3: If Solana’s memory model is causing issues, try explicitly storing the return value at a fixed location in Solidity:

contract C {
function f() public pure returns (uint r1)
{
assembly {
let ptr := mload(0x40) // Get free memory pointer
mstore(ptr, 12345678) // Store the return value
return(ptr, 32) // Return pointer to stored value
}
}
}

This ensures the Solana BPF returns the actual value instead of just a pointer. Forces explicit storage at a known memory location.

Lastly:

• Dump test.trace to inspect memory contents
• Check .data section of the ELF file for stored values
• Modify Solidity contract to store the return value explicitly

[Subway2023]

Method1

stxdw is in trace. However there is no value of 12345678(or 0xbc614e) in it.

  106 [0000000000000000, 0000000300000008, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5877: stxdw [r1+0x0], r2
  107 [0000000000000000, 0000000300000008, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5878: lddw r1, 0x300000000
  108 [0000000000000000, 0000000300000000, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5880: stxdw [r1+0x0], r2

Method2

solang does not allow mload

error: builtin 'mload' is not available for target Solana. Please, open a GitHub issue at https://github.com/hyperledger/solang/issues if there is need to support this function
  ┌─ /mnt/sdd1/sbw/crossCompilerFuzz/virtualMachine/solanaExecute/data/test.sol:4:24
  │
4 │             let ptr := mload(0x40) // Get free memory pointer
  │                        ^^^^^^^^^^^

[0rlych1kk4]

1. Since the expected value (12345678) is missing in the trace, you need to do:

a. Check r2 before stxdw
* stxdw [r1+0x0], r2 means r2 is being stored at r1+0x0
* If r2 does not contain 12345678, then the function is not setting it correctly.
b. Manually print register values before exit
* Modify solana-ledger-tool to dump registers right before exit.
* Look at the last mov64 r0, ... instruction before exit—this should contain the return value.

2. Ensure solidity is correctly returning the value. Since mload is not supported, modify the contract to ensure explicit storage of the return value:

contract C {
function f() public pure returns (uint) {
return 12345678; // Ensure explicit return
}
}

Then compile and rerun to see if the value appears in stxdw or lddw.

3. Read Memory at 0x300000000
   From the trace:

107 [0000000000000000, 0000000300000008, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000] 5878: lddw r1, 0x300000000
108 [0000000000000000, 0000000300000000, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000] 5880: stxdw [r1+0x0], r2

• lddw r1, 0x300000000 → r1 now points to 0x300000000.
• stxdw [r1+0x0], r2 → r2 is stored at 0x300000000.

Dump memory at 0x300000000

Run:
hexdump -C test.trace | grep "300000000"

or use solana-ledger-tool with --trace and scan for 0x300000000.

Next you need to

• Verify if r2 contains 12345678 before stxdw.
• Modify Solidity contract to ensure an explicit return.
• Dump memory at 0x300000000 to find the stored value.

Let me know If you find anything in the memory dump.

[Subway2023]

1. r2 has no value of 12345678

  106 [0000000000000000, 0000000300000008, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5877: stxdw [r1+0x0], r2
  107 [0000000000000000, 0000000300000008, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5878: lddw r1, 0x300000000
  108 [0000000000000000, 0000000300000000, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5880: stxdw [r1+0x0], r2
  109 [0000000000000000, 0000000300000000, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5881: lddw r1, 0x300000014
  110 [0000000000000000, 0000000300000014, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5883: stxw [r1+0x0], r2
  111 [0000000000000000, 0000000300000014, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5884: lddw r1, 0x300000010
  112 [0000000000000000, 0000000300000010, 0000000000000000, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5886: mov64 r2, 32744
  113 [0000000000000000, 0000000300000010, 0000000000007FE8, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5887: stxw [r1+0x0], r2
  114 [0000000000000000, 0000000300000010, 0000000000007FE8, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5888: mov64 r1, r10
  115 [0000000000000000, 0000000200001000, 0000000000007FE8, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5889: add64 r1, -608
  116 [0000000000000000, 0000000200000DA0, 0000000000007FE8, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5890: call solang_dispatch
  117 [0000000000000000, 0000000200000DA0, 0000000000007FE8, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200002000]  5907: mov64 r6, r1
  118 [0000000000000000, 0000000200000DA0, 0000000000007FE8, 000000000000000C, 0000000000000006, 0000000400002860, 0000000200000DA0, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200002000]  5908: ldxdw r1, [r6+0x240]
  119 [0000000000000000, 0000000000000004, 0000000000007FE8, 000000000000000C, 0000000000000006, 0000000400002860, 0000000200000DA0, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200002000]  5909: mov64 r2, 8
  120 [0000000000000000, 0000000000000004, 0000000000000008, 000000000000000C, 0000000000000006, 0000000400002860, 0000000200000DA0, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200002000]  5910: jgt r2, r1, lbb_5919
  121 [0000000000000000, 0000000000000004, 0000000000000008, 000000000000000C, 0000000000000006, 0000000400002860, 0000000200000DA0, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200002000]  5919: lddw r0, 0x200000000
  122 [0000000200000000, 0000000000000004, 0000000000000008, 000000000000000C, 0000000000000006, 0000000400002860, 0000000200000DA0, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200002000]  5921: exit
  123 [0000000200000000, 0000000000000004, 0000000000000008, 000000000000000C, 0000000000000006, 0000000400002860, 0000000400000010, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200001000]  5891: exit

hexdump -C test.trace.0 | grep "300000000"

00006040  20 72 31 2c 20 30 78 33  30 30 30 30 30 30 30 30  | r1, 0x300000000|
00006070  30 33 30 30 30 30 30 30  30 30 2c 20 30 30 30 30  |0300000000, 0000|

[0rlych1kk4]

The function's return value is likely being optimized away or stored in another memory location.

The trace output :
* stxdw [r1+0x0], r2 stores r2 at r1, but r2 does not contain 12345678.
* Memory address 0x300000000 is accessed, but its contents do not match the expected return value.
* solang_dispatch is called at instruction 5890, meaning the function dispatch logic may be handling return values differently.

1. Since Solang's compiler may be optimizing away the return value, modify the Solidity function to explicitly store the return value in memory before returning.

Modified Solidity Contract:
contract C {
function f() public pure returns (uint r1) {
uint result = 12345678; // Store in a variable first
assembly {
let ptr := add(msize(), 0x20) // Allocate memory
mstore(ptr, result) // Store value in memory
return(ptr, 32) // Return the pointer to the value
}
}
}

With this Fix :
* Prevents compiler optimizations that remove return values
* Ensures value is stored in memory, making it retrievable
* Solana BPF expects return values in memory, and this ensures correct storage.

2. If Solidity does not allow mstore, the return value may still be placed in register r0 or in a memory offset.

a.) Find the exit instruction and check r0

• In your trace output:

121 [0000000000000000, 0000000000000004, 0000000000000008, 000000000000000C, 0000000000000006, 0000000400002860, 0000000200000DA0, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200002000] 5919: lddw r0, 0x200000000
122 [0000000200000000, 0000000000000004, 0000000000000008, 000000000000000C, 0000000000000006, 0000000400002860, 0000000200000DA0, 0000000200000FF0, 0000000000000001, 0000000200000DD8, 0000000200002000] 5921: exit

• r0 is loaded from 0x200000000 before exiting.
• The actual value might be stored at 0x200000000.

b.) Dump memory at 0x200000000 to check stored value
Run:
hexdump -C test.trace | grep "200000000"

3. To trace where the return value is being stored, use Solana's built-in BPF debugger:

   solana-test-validator --log
   solana program dump -v C.so > program_dump.txt
   solana-debugger C.so --input input.txt --trace test.trace

This will show exactly where r0 and memory are modified before exiting.

Lastly,

• Modify Solidity contract to store return value explicitly.
• Dump memory at 0x200000000 to check stored return value.
• Run Solana BPF Debugger to trace r0 before exit.

let me know where it is stored, if you find 12345678 in memory