On Thu, Aug 29, 2019 at 8:49 PM Daniel Thompson <daniel.thompson@xxxxxxxxxx> wrote: > > On Thu, Aug 29, 2019 at 07:58:45PM +0530, Amit Kucheria wrote: > > On Thu, Aug 29, 2019 at 7:35 PM Daniel Thompson > > <daniel.thompson@xxxxxxxxxx> wrote: > > > > > > On Tue, Aug 27, 2019 at 05:43:59PM +0530, Amit Kucheria wrote: > > > > Printing the function name when enabling debugging makes logs easier to > > > > read. > > > > > > > > Signed-off-by: Amit Kucheria <amit.kucheria@xxxxxxxxxx> > > > > Reviewed-by: Stephen Boyd <swboyd@xxxxxxxxxxxx> > > > > Reviewed-by: Daniel Lezcano <daniel.lezcano@xxxxxxxxxx> > > > > > > This should need to be manually added at each call site; it is already > > > built into the logging system (the f flag for dynamic debug)? > > > > I assume you meant "shouldn't". > > Quite so. Sorry about that. > > > I haven't yet integrated dynamic debug into my daily workflow. > > > > Last time I looked at it, it was a bit bothersome to use because I > > needed to lookup exact line numbers to trigger useful information. And > > those line numbers constantly keep changing as I work on the driver, > > so it was a bit painful to script. Not to mention the syntax to frob > > the correct files in debugfs to enable this functionality. > > > > As opposed to this, adding the following to the makefile is so easy. :-) > > > > CFLAGS_tsens-common.o := -DDEBUG > > > > Perhaps I am using it all wrong? How would I go about using dynamic > > debug instead of this patch? > > Throwing dyndbg="file <fname>.c +pf" onto the kernel command line is a > good start (+p enables debug level prints, +f causes messages to include > the function name). That's useful to know. $ git grep __func__ | wc -l 30914 Want to send some patches? :-) > When the C files map to module names (whether the modules are actually > built-in or not) then <module>.dyndbg=+pf is a bit cleaner and allows > you to debug the whole of a driver without how it is decomposed into > files. And if changing the kernel cmdline options isn't possible or is inconvenient? > There are (many) other controls to play with[1] but the above should be > sufficient to simulate -DDEBUG . The "hard" bit is explicitly poking the line number in a file to activate a paricular pr_dbg statement. Even if I scripted it, those lines numbers keep changing in an actively developed driver. Somehow, I've always felt dyndbg was more useful to debug a production system where recompiling the kernel wasn't an option e.g. reporting an issue back to a distro-kernel vendor. > Daniel. > > [1] > https://www.kernel.org/doc/html/latest/admin-guide/dynamic-debug-howto.html
