On Thu, Oct 19, 2017 at 5:42 AM, Uwe Kleine-König <uwe@xxxxxxxxxxxxxxxxx> wrote: > > I wonder about the name. From a debug build (in contrast to a release > build) I would expect that it allows to debug sparse itself (Think: add > -g to gcc, or (not) -DNODEBUG for assert(3)), but I understand you use > that term differently here. The name if mechanical. You can suggest better names. I am more focus on allowing two version of sparse can be compile at the same time. > > Why not do the the extra tests when called as (say) > > sparse --aggressive > Yes, actually that is what I have in mind. When "--aggressive" is turn on, sparse will execute "dbg-sparse" to enable those aggressive code path. The optional name is subject to change. > . Then there is no need for an extra binary at all keeping the build > system simple and that also makes it it easier to understand for users > (but I might judge others by my own standards here?) For gcc this flag > is -Wall, there isn't an extra binary either. There is still need for extra binary because some verification can be slow sparse and hard to turn off without impact the sparse performance. For example the ptr list ref count patch. It is execute at every ptrlist bucket iteration. If there is no performance impact on when those verification is turn off. Then yes, there is no need for a separate binary. I haven't done concrete measurement of the slow down. I just assume that there will be some. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-sparse" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
