----- 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 -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility