----- Original Message ----- Good question. And no good answer. I'm guessing that when you enter "struct log" as a crash command, it finds the base kernel's version first? It's a gdb question actually, and it comes down to gdb's lookup_symbol() function -- which has an optional "struct block" argument that narrows down the scope to a particular range of text. But the crash utility does not use the block argument when calling lookup_symbol() for a data structure declaration. So whatever you get, you get... There are a number of places where the "block" argument for a particular function are determined, but they seem to presume that you're working from a stack frame, which is not a concept when used with the crash utility, because it's invoked internally as "gdb vmlinux". I'm guessing that there are other paths that can be taken to find a legitimate "block" that will hopefully select the correct structure definition, but I'm not that familiar with the gdb code to tell you off-hand. And in any case, there's certainly no way that I'm aware of that it could be done without adding new functionality to the crash utility and its interface with the embedded gdb module. Interesting that nobody's ever brought this up before. There must be other examples. Dave

----- Original Message ----- I can't help myself -- maybe it wouldn't be so hard to implemente if I take a sledgehammer approach... For example, I created a global "crash_block" pointer in the crash sources like this: struct block *crash_block; extern struct block *block_for_pc(ulong); And then hacked up the built-in-but-hidden "test" command to accept a text address, call block_for_pc() to get its block address, and assign it to the global crash_block above. Then in the gdb code, I put this in place, where lookup_symbol() currently always receives a NULL block pointer: struct symbol * lookup_symbol (const char *name, const struct block *block, domain_enum domain, int *is_a_field_of_this) { + if (!block) { + extern struct block *crash_block; + block = crash_block; + } return lookup_symbol_in_language (name, block, domain, current_language->la_language, is_a_field_of_this); } So without setting the crash_block, you get the normal behavior: crash> struct log struct log { u64 ts_nsec; u16 len; u16 text_len; u16 dict_len; u16 level; } SIZE: 16 crash> Then I load the xfs module debuginfo, and dump its symbols: crash> mod -s xfs MODULE NAME SIZE OBJECT FILE ffffffffa02d67c0 xfs 816241 /lib/modules/3.5.0-0.rc1.git0.1.fc18.x86_64/kernel/fs/xfs/xfs.ko crash> sym -m xfs ffffffffa0239000 MODULE START: xfs 14700 (D) xfsstats ffffffffa0239000 (t) ftrace_raw_output_xfs_discard_class ffffffffa02390e0 (t) ftrace_raw_output_xfs_log_recover_ino_item_class ffffffffa02391f0 (t) ftrace_raw_output_xfs_log_recover_buf_item_class ffffffffa02392e0 (t) ftrace_raw_output_xfs_free_extent ffffffffa0239410 (t) ftrace_raw_output_xfs_trans_commit_lsn ffffffffa02394f0 (t) ftrace_raw_output_xfs_extent_busy_trim ffffffffa02395e0 (t) ftrace_raw_output_xfs_extent_busy_class ffffffffa02396c0 (t) ftrace_raw_output_xfs_pagecache_inval ffffffffa02397b0 (t) ftrace_raw_output_xfs_itrunc_class ffffffffa0239890 (t) ftrace_raw_output_xfs_simple_io_class ffffffffa0239990 (t) ftrace_raw_output_xfs_page_class ffffffffa0239a90 (t) ftrace_raw_output_xfs_log_force ffffffffa0239b60 (t) ftrace_raw_output_xfs_rename ... [cut] ... Picking out the address of "ftrace_raw_output_xfs_rename" (because it's it's one of the xfs addresses that sees its own "struct log"), I get its block address, and set the global "crash_block" to 6495890: crash> test ffffffffa02397b0 block_for_pc(ffffffffa02397b0): 6495890 crash> And lo and behold: crash> struct log struct log { struct xfs_mount *l_mp; struct xfs_ail *l_ailp; struct xfs_cil *l_cilp; struct xfs_buf *l_xbuf; struct xfs_buftarg *l_targ; uint l_flags; uint l_quotaoffs_flag; struct list_head *l_buf_cancel_table; int l_iclog_hsize; int l_iclog_heads; uint l_sectBBsize; int l_iclog_size; int l_iclog_size_log; int l_iclog_bufs; xfs_daddr_t l_logBBstart; int l_logsize; int l_logBBsize; wait_queue_head_t l_flush_wait; int l_covered_state; xlog_in_core_t *l_iclog; spinlock_t l_icloglock; int l_curr_cycle; int l_prev_cycle; int l_curr_block; int l_prev_block; atomic64_t l_last_sync_lsn; atomic64_t l_tail_lsn; crash> To set it back to base kernel, I can either clear the "crash_block", or for example, set it to sys_read()'s block, and I get the base kernel's view: crash> sym sys_read ffffffff81185000 (T) sys_read ../debug/k3.nel-3.4.fc18/linux-3.5.0-0.rc1.git0.1.fc18.x86_64/fs/read_write.c: 461 crash> test ffffffff81185000 block_for_pc(ffffffff81185000): 69648f0 crash> struct log struct log { u64 ts_nsec; u16 len; u16 text_len; u16 dict_len; u16 level; } SIZE: 16 crash> So I suppose we *could* have a new crash "block" environment variable, settable with the "set" command, and then while it's in play you would see stuff based upon that particular scope. Hmmm... I just wonder if it's worth it given the parcity of actual examples of multiple structs with the same name. That's why I'm wondering if anybody else on the list has run into this kind of problem? Dave

----- Original Message ----- Yeah, OK -- in fact, I've got to believe that there must be examples that exist within the base kernel itself, and not just with modules. Anyway, for crash-6.0.8 I'll queue up a "set context" (or "set scope"?) environment variable that takes a kernel/module text address -- with a default of 0 to keep the behavior the same as it is now. Thanks, Dave

On Fri, Jun 15, 2012 at 6:36 PM, Dave Anderson <anderson(a)redhat.com&gt; wrote: We'll need to use this feature from the trace extension too. In recent kernels, the perf subsystem has its own struct ring_buffer so if CONFIG_PERF_EVENTS is enabled, the trace extension finds the wrong struct ring_buffer. Rabin