Frank Ch. Eigler wrote:DWARF processing done after the kernel build isn't really a problem, although it requires a large vmlinux(.gz) file to be kept around. As part of the kernel build is probably better, at least in the case of static markers. Well, it depends a bit on what kind of expressions you put in there. You don't really want to put *expressions* in there as much as you want to put *data* references in there, although, of course, if your have something like "foo->bar[baz]->quux" then it's easy to trip upon. One advantage of using the debugging information in this manner is that you can write the actual markers long after the kernel has compiled, as long as the data happens to be available at the call site. Once again, the *proper* way to do this is with compiler support. That way we can do patched branches and out-of-line everything with impunity. -hpa --
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 006/196] Chinese: add translation of oops-tracing.txt |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Roland Dreier | Re: Integration of SCST in the mainstream Linux kernel |
git: | |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Linus Torvalds | Re: iptables very slow after commit 784544739a25c30637397ace5489eeb6e15d7d49 |
| Herbert Xu | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
