On Thu, Apr 5, 2012 at 12:24, Andreas Färber <afaer...@suse.de> wrote: > Am 04.04.2012 22:54, schrieb Peter Maydell: >> On 4 April 2012 21:34, Blue Swirl <blauwir...@gmail.com> wrote: >>> On Wed, Apr 4, 2012 at 20:11, Peter Maydell <peter.mayd...@linaro.org> >>> wrote: >>>> I'd much rather enable a #define to turn on debugging than faff about >>>> with tracing. It's simple and straightforward, you can do it with a >>>> single obvious change and recompile, and nobody has to look up >>>> documentation to figure out how it works. >>> >>> Laziness. Even the built in help should be sufficient to start using >>> tracepoints. >> >> Well, I looked at the docs and said "this gives me no benefit over >> DPRINTF, and why do I have to create a file that explicitly lists >> every single event the code I'm interested in has defined, and >> the quickstart seems to be recommending something that you have to >> postprocess, and generally I dunno what problem this is trying to >> solve but it doesn't look like it's trying to solve programmer debug >> tracing". >> >> If other people want to write trace events that's fine but for me >> at the moment it seems a definite step back from simple DPRINTF >> macros. >> >>>> If tracepoints were always-compiled-in and enabled at runtime I'd >>>> agree with you: then you could have linux-kernel-style "enable debug >>>> tracing", "enable warnings about odd guest behaviour", "be silent", >>>> etc. But they're not, so they don't gain anything over a simple >>>> DPRINTF for programmer debugging. >>> >>> False. It's easy to compile in tracepoints >>> (--enable-trace-backend=simple) and the overhead is zero or marginal. >> >> (a) that gives you a binary dump rather than something actually >> readable (and 'simple' can't even handle string output!) and >> (b) if it's that good why don't we enable it by default? >> Also I can't see anything in the docs about having sensible sets >> of levels of tracing or grouping trace events into coherent sets >> you can toggle on and off. >> >>> Processing is offline. >> >> For debugging this is not a feature -- you want to see the output >> as you step through things in the debugger. > > Seeing this thread today, not being cc'ed properly and the list lagging > yesterday once again, we should not have this discussion without > involving the tracing maintainer, cc'ed. > > I agree with Blue that using tracepoints is more flexible output-wise > and avoids bitrot. However trace-events is an annoying single point of > merge conflicts when adding trace points. Is it thinkable of allowing > more localized tracepoint definitions
Forgot to respond to this, sorry. I think this could be useful. > I agree with Peter that tracing being nop by default is not so helpful > for developers. So what about enabling the stderr backend by default, > with all tracepoints disabled by default? Maybe the best would be that several back ends could be enabled at the same time. > In addition to what's been said on this thread, the simple tracing > backend potentially collects a lot of garbage into files that are hard > to post-process in a changing development tree due to dependency on > trace-events file. What is this garbage? > I would've suggested to enable the platform's native tracing backend by > default, but on Linux there might be SystemTap and LTTng both present. > At least DTrace and SystemTap scripts can also emit printfs when events > occur, for DPRINTF-like output; shipping some examples for specific > areas in scripts/ might not be a bad idea either. Yes, I've never tried either because simpletrace works for me and I haven't seen simple examples for them. > > Andreas > > -- > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany > GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
