Rules to avoid common extended inline assembly mistakes

Re:Rules to avoid common extended inline assembly mistakes by bjackman on Saturday December 21, 2024 @06:28AM (#42479044)

I have a fun exception to this!

When writing BPF programs, sometimes it's tricky to get the compiler to generate code that passes the verifier. This can lead you down a path of writing bizarre C in order to try and produce the right order of checks and register allocations.

So, use inline asm!

It's not portable any more... But it's a BPF program! There's nothing to port it to.

It's less readable... Wait no, it's _more_ readable because BPF asm has good syntax and you can avoid the bizarre C backflips to satisfy the verifier.

It's unsafe... Wait no, it's checked for safety at load time!

[ Parent | on HN ]

Re:Rules to avoid common extended inline assembly mistakes by ryandrake on Saturday December 21, 2024 @09:36AM (#42479933)

For the curious, BPF in this case might mean Berkeley Packet Filter[1]. Not sure. Kind of an obscure acronym but Google search seems to have a consensus.

1: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter

[ Parent | on HN ]

Re:Rules to avoid common extended inline assembly mistakes by wyldfire on Saturday December 21, 2024 @10:00AM (#42480053)

It does. These days, it's probably eBPF and a popular target is the linux kernel [1].

You can write C hooks for tracing and profiling, etc. - with inline asm!

[1] https://docs.kernel.org/bpf/

[ Parent | on HN ]