On Thu, Oct 19, 2017 at 6:39 PM, Christopher Li <sparse@xxxxxxxxxxx> wrote: > On Wed, Oct 18, 2017 at 3:18 PM, Luc Van Oostenryck <luc.vanoostenryck@xxxxxxxxx> wrote: >> No real objections but I have some doubts about all the debug part. >> I think that people hacking on sparse and who need to debug know >> what they need and want to debug. > > Right, this change is to allow a separate debug binary let say "dbg-sparse", > to be execute from "sparse" when needed. My point is: if "when needed" means "when sparse developpers need to debug something" then I really think all this is not needed as the dev can very well build the executable he needs, with the options he needs, use his own workflow, ... > Take the ptrlist ref count checking for example. I image have > sparse --check-ptrlist, which will invoke dbg-sparse to do the > checking. I expect the distro will include dbg-sparse as part > of the sparse package as well. Really? Are the distros interested in this sort of things? Is there a real need for it? Who do you really think will use this? > The end result is that. The user of sparse, not sparse developers, > can invoke sparse with those extra verification (at cost of slow > down sparse) on the custom input source without modify and > recompile sparse. Yes *can* ... but will they? Why isn't there a dbg-gcc, dbg-bash, ... ? >> For example, the OPT=0 is, IMO, useless as you generally need >> others flags too. Also, when you debug, you generally need to rerun >> things several times, so using extra options on the command line is >> not ideal (a mechanism like local.mk is better suited but local.mk >> itself is not). > > In that case, you can just OPT=0 into local.mk and problem solved? > Even if you do that, you still need to provide OPT variable for overwrite > purpose. Append and reset the whole variable is easy. > Partial modify the content of variable from one to another is harder and > annoying. > > Can you clarify "but local.mk itself is not". If you have a sort of config file, or anything allowing to adapt things to your needs, you want at least to have a dot file for it. But for a project using git, you also want that the file doesn't interfer with git status but also with git clean (including git clean -x). >> Also, what's the real need for dbgbuild/ & debug/ ? >> IMO, it's a big complexification of all the rules with plenty of >> duplicated things for very few, if any, benefits. > > Provide extra verification on user input files. Another candidate > of those verification can be, the sorting of ptrlist. > There is function verify_seq_sorted () verify the list is indeed sorted. > But that function currently is not turn on in sparse. Presumably > it is used in the development phase of the ptr list sorting. > That verification function can be turn on in the debug build for example. Yes *can* ... Same questions: who will use this and when? Are extra binaries and duplicated build rules a good answer for this? More broadly: what problem do you try to solve with these patches? What values do these patches bring to sparse? Does sparse need these patches? -- Luc -- 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
