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