On Sat, 2008-03-01 at 17:15 -0800, James Washer wrote:
I think you'll have better luck consulting the source code, and
disassembly to figure out what is on the stack.
checking asm code and finding out what is on the stack is sure the most
accurate way. but a hint could speed up the process.
For the example you've cited, if a given function uses an inode pointer,
it shouldn't take but a minute or so to determine where in the stack
frame this inode is located. (unless of course it turns out to be in a
register only, in which case you have to look for it to be spilled in a
subsequent frame)
quite some time you can see from the asm code that a important parameter
is stored in register and you have to go several level deeper before
finding it. so a hint which quickly locate a potential 'hot' data and
later revalidate with code reading is still very appealing.
- jim
On Sat, 2008-03-01 at 17:38 -0500, Ming Zhang wrote:
> Hi All
>
> When use bt -f to show stack data, I need a quick way to find out what
> are these stack data. For example, does any of these data are a inode
> pointer, or ... So here is always what i do.
>
> bt -f > stack
> kmem -S inode_cache > inode
>
> then use sort and comm utility to find value that appear in both files.
>
> Is there a better way to do this?
>
> I wish we can have a bt -f slab1 slab2...
>
> and try to match the stack data with content from these slab cache
> automatically.
>
> Thanks!
>
>
--
Ming Zhang
@#$%^ purging memory... (*!%
http://blackmagic02881.wordpress.com/
http://www.linkedin.com/in/blackmagic02881
--------------------------------------------