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. -- PMM