Ming Zhang wrote: > Hi All > > I wonder if it possible to have this feature - user defined symbol. > > for example, define inode1 = 0x1234 > > then in all place has this 0x1234 in bt or rd command, show inode1 > instead of numeric value, > > This should be very helpful when these value pop up in a haystack of > numeric values... > > Thanks > Why not just pipe the relevant command to grep to pin-point the locations of the value you're tracking? I know it's tempting, but creating a crash command/option for specific kernel-debug cases would soon become overwhelming. So I'm not particulary excited about this suggestion; maybe others would be...

BTW, as you requested earler, I've got the "kmem -s <address>" output changed such that the base address of the object is shown instead of the <address> argument which may be offset into the slab object. With CONFIG_SLUB kernels, that's how it currently works, although I'm also fixing "kmem -S" and "kmem -s address" failures to handle some 2.6.25 kernel changes to SLUB object free-list tracking. And there still appears to be more SLUB-related churn being proposed on LKML on the horizon.

Dave

Ming Zhang wrote: > On Wed, 2008-03-05 at 15:57 -0500, Dave Anderson wrote: >> Ming Zhang wrote: >>> Hi All >>> >>> I wonder if it possible to have this feature - user defined symbol. >>> >>> for example, define inode1 = 0x1234 >>> >>> then in all place has this 0x1234 in bt or rd command, show inode1 >>> instead of numeric value, >>> >>> This should be very helpful when these value pop up in a haystack of >>> numeric values... >>> >>> Thanks >>> >> Why not just pipe the relevant command to grep to pin-point the >> locations of the value you're tracking? >> >> I know it's tempting, but creating a crash command/option for >> specific kernel-debug cases would soon become overwhelming. >> So I'm not particulary excited about this suggestion; maybe >> others would be... > > understood. > > >> BTW, as you requested earler, I've got the "kmem -s <address>" >> output changed such that the base address of the object is shown >> instead of the <address> argument which may be offset into the >> slab object. With CONFIG_SLUB kernels, that's how it currently >> works, although I'm also fixing "kmem -S" and "kmem -s address" >> failures to handle some 2.6.25 kernel changes to SLUB object >> free-list tracking. And there still appears to be more >> SLUB-related churn being proposed on LKML on the horizon.

> > cool. where i can get this updated code? > > >> Dave Remove the previous patch I sent you and apply the attached one. Dave