[Crash-utility] question about kernel module dwarf unwinder support

[Dave Anderson]

----- 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