----- Original Message -----
 Hi All,
 
 We have ported crash-utility to TileGX arch and it generally works well.
 
 For stack backtrace, we are using dwarf based approach and using
 .debug_frame section.
 
 Currently, the problem is letting dwarf unwinder support kernel module
 (.ko), we have work out this problem by quite ugly way:
 
 * we modified target independent code in kernel.c to invoke new added
 tilegx hook "tilegx_add_module_unwind_table" for "mod -s" command.
 
 diff --git a/kernel.c b/kernel.c
 index 3fc0b68..5f3f2ef 100755
 --- a/kernel.c
 +++ b/kernel.c
 @@ -3760,6 +3760,10 @@ do_module_cmd(ulong flag, char *modref, ulong
 address,
 break;
 
 case LOAD_SPECIFIED_MODULE_SYMBOLS:
 + #ifdef TILEGX
 + if (!tilegx_add_module_unwind_table(modref, objfile, address))
 + error(FATAL, "cannot load debug frame from: %s\n", objfile);
 + #endif
 
 
 * in "tilegx_add_module_unwind_table" we parse .ko file, locate
 .debug_frame/.rela.debug_frame, perform relocation on .debug_frame, then
 add the relocated .debug_frame to module unwind table list. then later,
 the if the pc is in module address space, then module unwind table list
 will be searched instead of kernel unwinder table.
 
 I don't know if this approach will be accepted by the community when we
 return all our TileGX backend. Are there any better approach to support
 kernel module dwarf unwinding that will not affect the target-indepent code?
 
 thanks in advance. 
Hello Jiong,
So should I presume that you are ultimately planning to post a complete
patchset that introduces the TILE architecture?  I'm not at all familiar
with the processor type, but is there something that would differentiate
TILE and TILEGX?
Anyway, I do try to avoid "#ifdef <ARCH>" if at all possible.
A few questions:
 Your patch only makes the call if "mod -s <module>" is used -- but what
 if "mod -S" used?
 If your call fails, you force "mod -s <module>" to also fail -- do you
 really want to do that?
 There are a number of places where the subsequent load_module_symbols()
 call may fail -- do you still want to accept the data from your function
 in that case?
 Is it possible that you can call your function after load_module_symbols()
 has succeeded?  If that is possible, then perhaps you could at least move
 your function call location to here in load_module_symbols(), maybe at 
 line #10050:
  10042 
  10043 add_symbols:
  10044         result = add_symbol_file(st->current);
  10045 
  10046         if (CRASHDEBUG(2))
  10047                 check_for_dups(st->current);
  10048 
  10049         st->current = NULL;
  10050 
  10051         return result;
  10052 }
That would also cover the "mod -S" command as well.
Dave Anderson