>> 1) Due to BPF being so restrictive, many hundreds of GCC tests won't >> even build, because they use functions having more than 5 arguments, >> or functions with too big stack frames, or indirect calls, etc. We >> want to be able to test our backend properly, so we added the -mxbpf >> option in order to relax some of these restrictions. >> >> 2) We are working on a BPF simulator that works with GDB. For that to >> work, we needed to add a "breakpoint" instruction that GDB can patch >> in the program. Having a simulator also allows us to run more GCC >> tests. >> >> 3) With some extensions, it becomes possible to support DWARF call frame >> information, and therefore to debug BPF programs in GDB with >> unwinding support. You can build with -mxbpf, debug, then build >> again without -mxbpf. > > All sounds like features to propose for BPF itself, rather than throw > into some weird extension. > > Why not come to the bpf community and discuss the need for these > features? Well, as I said these features are mainly intended for the benefit of the tooling side. But of course if some of them are deemed useful enough (and feasible) to be added to BPF proper, then great! As for discussion, here I am, as I was in LPC :)
