Ingo Molnar wrote:Otherwise you're forcing everyone to take the cost of additional cache footprint, plus optimizer interference, just because they might want to possibly do some trivial tracing. DEBUG_INFO is The Right Thing for this, as it carries all the information you may want in a well-defined format. You don't necessarily have to keep all this information around, of course; you can distill out the information for the trace sites at compile time and keep a tracer information file, after which you can strip the information. There is actually yet another alternative, though, which is to build the tracer at compile time. The tricky part of this is that it almost requires inserting a preprocessor before the assembler, and use really ugly asm() macros to extract the very information that the debug format is designed explicitly to extract! Personally, I think requiring DEBUG_INFO is a helluva lot less ugly than these branch hacks. -hpa --
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Greg Kroah-Hartman | [PATCH 008/196] Chinese: add translation of volatile-considered-harmful.txt |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Alex Chiang | [PATCH 1/4] Remove path attribute from sgi_hotplug |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [GIT]: Networking |
| Eric Dumazet | Re: [PATCH 3/3] Convert the UDP hash lock to RCU |
