While working on bug #14348, I've been looking at the buildid code. I believe it could be improved. Here's how it currently works. There is a lower-level routine, _stp_build_id_check(), that does the actual check. Then there are several upper-level routines that call _stp_build_id_check(): _stp_module_check() _stp_kmodule_check() _stp_usermodule_check() The buildid of the target module (either kernel, module, or user) is saved at translate time and compiled into the systemtap module. Then when the systemtap module is loaded, it checks the buildid against the target module. The code misses the following situation. If at translate time there was a buildid present in the target module and when the systemtap module is loaded we can't find a buildid section in the target module, systemtap doesn't treat that as an error. To my mind, if a target module had a buildid and now it doesn't, it has been modified and the systemtap module should exit before trying to probe it. There is another situation, the reverse of the above, that I'm not so sure about. If at translate time there wasn't a buildid present, and at systemtap module load time there is one present, then the target module has changed. I'm not 100% sure we should go always look for the buildid section in the target module if at translate time we didn't find one. It might depend on how expensive looking for the buildid section is.
After some testing, I've found that the buildid code actually did handle the case where the buildid was removed from the target. Commit 7a27d03 modifies the buildid.exp testcase to test this scenario.