Resurrect builds with noarch

[anwayde]

Currently, our CI does not use noarch. noarch64 does not work with a bunch of stuff that requires FD_HAS_INT128. noarch128 addresses that but cannot build important targets like fdctl, fddev, integration-test since they need FD_HAS_SSE which is a requirement in disco/mux. We should address this and make sure we can build these targets with noarch as well to maintain a nice base for compiling under Arm, PPC, and BPF/SBPF.

[ripatel-fd]

@anwayde Making fdctl portable has lots of subtasks. I'll just list them out here for future reference. They are each a decent amount of work (> 2 weeks total) unless we want to go some cheap route.

• [ ] We haven't specifically made sure that fdctl compiles without FD_HAS_THREADS and FD_HAS_ATOMIC, I think (probably the easiest item to fix)
• [ ] tango, disco (and misc other parts of the codebase) assume x86-TSO (quite tricky to fix)
  • global search for FD_COMPILER_MFENCE to get a sense of scope
  • RCpc memory model on Arm and PPC works well reliable consumers but it requires special crafting of machine code. Namely, dcache reads must have address dependencies on the mcache sequence number to prevent reads of stale message data. Requires either C11 atomics or compiler hacks (volatile, inline asm)
  • RCpc is unfortunately insufficient for unreliable consumers due to difficulties detecting corruption during speculative reads. Namely, a sequence number sanity check after message consumption would need implicit dependencies on all instructions that read message content, which is impractical. Thus we need to use stronger architecture-specific features like memory barriers. Reaching >1Mpps on these architectures might require changes to the tile main loop, such as speculatively reading multiple fragments before issuing a memory barrier. Requires further research.
• [ ] The combination of the above two: disco uses 128-bit atomic and x86-TSO for low latency fd_frag_meta_t receive. This is easy to fix.
• [ ] fd_sandbox only supports one architecture (it assumes a uniform syscall interface, but in reality Linux exposes a different syscall interface on each architecture)
• [ ] Support for more page sizes. Some Arm systems use 16K 'normal' pages.
• [ ] FD_HAS_INT128 is a hard requirement for the runtime. Really, it is only 64-bit wide multiply. Modern compilers do tricks to provide a virtual int128 that is stored in memory / in two 64-bit GPRs and can fall back to soft multiply. The Clang BPF target isn't able to do this. Practically, this means that Firedancer's runtime components cannot run inside the Solana VM. It would be easier to fix the Clang BPF target than to fix Firedancer.
• [ ] Ensure ./deps.sh builds on other architectures.

[ripatel-fd]

Chatted with Anway. Unfortunately, the noarch target got removed from CI. We should at it back at some point.

[anwayde]

I've added the noarch64 target back to CI.

[ripatel-fd]

@anwayde Great, thanks. Can we close this then?

[anwayde]

We could, the reason I didn't was because fdctl still doesn't build with noarch. Was wondering if we should keep this open to track that? Or maybe that's not necessary. Either way, I leave the decision up to you @ripatel-fd and @lheeger-jump

[ripatel-fd]

I see no reason to build fdctl with noarch. On these embedded targets the assumptions that fdctl makes probably don't hold. Those include AF_XDP available, sandbox, etc. The noarch build target so far has mainly served to ensure individual components (like the sBPF VM or ELF parser) can build in isolation, not that entire Firedancer is supported on arbitrary architectures. @mmcgee-jump Do you have any thoughts on this?

[mmcgee-jump]

Yeah, we don't need to support noarch for fdctl (or anything other than linux+x86_64 for now)