[DTrace-devel] okay to emit unlabeled BPF_NOP()?

[Eugene Loh]

It appears that we can handle BPF_NOP() instructions only if they're 
labeled.  Is that okay?  Known limitation?  Should we put a safeguard in 
for unlabeled BPF_NOP() instructions?

BPF_NOP() instructions are encoded as "jump 0" instructions.  We 
(dt_cg.c) encode other jump instructions as "jump label", where label is 
a 1-based integer.  Then, during the "second pass" of dt_as() we 
relocate jump targets, translating from labels to offsets (relative to 
the immediately following instruction).  This means that a BPF_NOP() is 
interpreted as a jump to label 0, which does not exist, and bad code is 
produced, possibly causing the BPF verifier to fail.

This is not a big problem right now since we only generate BPF_NOP() 
instructions when they are labeled, and there is special code to handle 
that case.  But I'm wondering:

*)  Are we okay with that limitation?  (We cannot emit unlabeled 
BPF_NOP() instructions.)

*)  Would it be okay to insert a safeguard -- say, in dt_irlist_append() 
or dt_as() -- against unlabeled BPF_NOP() instructions?

Admittedly, it would seem ideal never to emit useless code. 
Nevertheless, it's easy enough to insert a safeguard against some 
unforeseen situation.