New AT_ flags for restricting pathname lookup [LWN.net]

New AT_ flags for restricting pathname lookup

Posted Oct 5, 2018 7:34 UTC (Fri) by Cyberax (✭ supporter ✭, #52523)
In reply to: New AT_ flags for restricting pathname lookup by flewellyn
Parent article: New AT_ flags for restricting pathname lookup

I hope so. I've just spent a day debugging a eBPF filter written by somebody else and it's NOT a nice experience at all.

Debugging infrastructure is sorely lacking for it.

to post comments

New AT_ flags for restricting pathname lookup

Posted Oct 5, 2018 12:10 UTC (Fri) by nix (subscriber, #2304) [Link] (2 responses)

eBPF is a nice thing to have if machine-generated (it's a rather nice and orthogonal assembler, and the ability to add helpers is just a killer feature that I wish real assemblers had!), but it's about as pleasant to debug programs written in it as any other assembler: i.e. fairly easy if you're familiar with the code generator, a nightmare otherwise, doubly so if this is the less regular land of handwritten code, disassembled and devoid of comments.

New AT_ flags for restricting pathname lookup

Posted Oct 5, 2018 17:14 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

It's way worse than assembly. With assembly you can typically use debuggers to trace the execution and inspect the environment. Nothing comparable exists for eBPF.

New AT_ flags for restricting pathname lookup

Posted Oct 5, 2018 22:24 UTC (Fri) by nix (subscriber, #2304) [Link]

Generally I do the same thing when debugging eBPF that I do when debugging other programs: printf()! In the case of eBPF you throw in a helper that does a printk() and chuck in calls to the helper liberally. (This is not so useful if you can't modify the eBPF, mind you.)