Re: [Crash-utility] [PATCH] arm64: exclude mapping symbols in modules

2016-10-06 Thread Dave Anderson 

Hi Akashi,

I was playing around with this, and noted that if a module's debuginfo data is 
not
loaded into a crash session with the "mod" command, branch instruction targets 
that are within the module space are not translated.  For example, note the 
handful
of "bl" instructions with module address targets are empty:
  
  crash> dis dm_create | grep bl
  0xfdfffc003814 :bl  0xfe226ce0 

  0xfdfffc003828 :bl  0xfe143754 

  0xfdfffc003850 :   bl  0xfe3c4f08 
  0xfdfffc00385c :   bl  0xfe78241c 
<_raw_spin_lock>
  0xfdfffc003874 :   bl  0xfe3c5d90 
  0xfdfffc00388c :   bl  0xfe123044 

  0xfdfffc0038b0 :   bl  0xfe10f9d0 
<__mutex_init>
  0xfdfffc0038c0 :   bl  0xfe10f9d0 
<__mutex_init>
  0xfdfffc0038d4 :   bl  0xfe10f9d0 
<__mutex_init>
  0xfdfffc003918 :   bl  0xfe3968c4 

  0xfdfffc003948 :   bl  0xfe3ab298 
  0xfdfffc003968 :   bl  0xfe10a878 
<__init_waitqueue_head>
  0xfdfffc003994 :   bl  0xfe10a878 
<__init_waitqueue_head>
  0xfdfffc0039a8 :   bl  0xfe10a878 
<__init_waitqueue_head>
  0xfdfffc0039f8 :   bl  0xfe3d1224 
  0xfdfffc003a00 :   bl  0xfe3aab08 
  0xfdfffc003a1c :   bl  0xfe3d1224 
  0xfdfffc003a34 :   bl  0xfe0e3acc 
<__alloc_workqueue_key>
  0xfdfffc003a48 :   bl  0xfe3a9a8c 
  0xfdfffc003a58 :   bl  0xfe38ea84 
  0xfdfffc003a70 :   bl  0xfdfffc00e418
  0xfdfffc003a78 :   bl  0xfe78241c 
<_raw_spin_lock>
  0xfdfffc003a88 :   bl  0xfe3c4e54 
  0xfdfffc003aa4 :   bl  0xfdfffc00d270
  0xfdfffc003ad8 :   bl  0xfe143860 
  0xfdfffc003ae0 :   bl  0xfe228464 
  0xfdfffc003b08 :   bl  0xfe3c4f08 
  0xfdfffc003b14 :   bl  0xfe78241c 
<_raw_spin_lock>
  0xfdfffc003b2c :   bl  0xfe3c5d90 
  0xfdfffc003b4c :   bl  0xfdfffc001220
  0xfdfffc003b54 :   bl  0xfdfffc0012e0
  0xfdfffc003b60 :   bl  0xfe1c4828 
  crash> 
  
With this patch: 

  --- a/arm64.c
  +++ b/arm64.c
  @@ -2977,6 +2977,16 @@ arm64_dis_filter(ulong vaddr, char *inbuf, unsigned 
int output_radix)
  sprintf(p1, "%s", buf1);
  }
   
  +   if (IS_MODULE_VADDR(vaddr)) {
  +   p1 = [strlen(inbuf)-1];
  +   strcpy(buf1, inbuf);
  +   argc = parse_line(buf1, argv);
  +   if (STREQ(argv[argc-2], "bl") &&
  +   extract_hex(argv[argc-1], , NULLCHAR, TRUE))
  +   sprintf(p1, " <%s>\n",
  +   value_to_symstr(value, buf2, output_radix));
  +   }
  +
  console("%s", inbuf);
   
  return TRUE;

module addresses are translated without having to load the module's debuginfo:

  crash> dis dm_create | grep bl
  0xfdfffc003814 :bl  0xfe226ce0 

  0xfdfffc003828 :bl  0xfe143754 

  0xfdfffc003850 :   bl  0xfe3c4f08 
  0xfdfffc00385c :   bl  0xfe78241c 
<_raw_spin_lock>
  0xfdfffc003874 :   bl  0xfe3c5d90 
  0xfdfffc00388c :   bl  0xfe123044 

  0xfdfffc0038b0 :   bl  0xfe10f9d0 
<__mutex_init>
  0xfdfffc0038c0 :   bl  0xfe10f9d0 
<__mutex_init>
  0xfdfffc0038d4 :   bl  0xfe10f9d0 
<__mutex_init>
  0xfdfffc003918 :   bl  0xfe3968c4 

  0xfdfffc003948 :   bl  0xfe3ab298 
  0xfdfffc003968 :   bl  0xfe10a878 
<__init_waitqueue_head>
  0xfdfffc003994 :   bl  0xfe10a878 
<__init_waitqueue_head>
  0xfdfffc0039a8 :   bl  0xfe10a878 
<__init_waitqueue_head>
  0xfdfffc0039f8 :   bl  0xfe3d1224 
  0xfdfffc003a00 :   bl  0xfe3aab08 
  0xfdfffc003a1c :   bl  0xfe3d1224 
  0xfdfffc003a34 :   bl  0xfe0e3acc 
<__alloc_workqueue_key>
  0xfdfffc003a48 :   bl

Re: [Crash-utility] [PATCH] arm64: exclude mapping symbols in modules

2016-10-06 Thread Dave Anderson 


- Original Message -
> Dave,
> 
> One question.
>
... 
>
> On arm64, when KASLR is enabled, a function call between a module and
> the kernel will be done via a veneer (PLT) if the displacement is more
> than +/-128MB. So disassembled code looks a bit useless:
> 
> ===8<===
> crash> mod -S
>  MODULE   NAME  SIZE  OBJECT FILE
> 04d78f4b8000  testmod  16384  
> /opt/buildroot/15.11_64/root/kexec/testmod.ko
> crash> bt
> PID: 1102   TASK: b4da8e91  CPU: 0   COMMAND: "insmod"
>  #0 [b4da8e9afa30] __crash_kexec at 0e0045020a54
>  #1 [b4da8e9afb90] panic at 0e004505523c
>  #2 [b4da8e9afc50] testmod_init at 04d78f4b6014 [testmod]
>  #3 [b4da8e9afb40] do_one_initcall at 0e0044f7333c
> ---  ---
>  PC: 000a  LR:   SP: 04d78f4b6000  PSTATE: 
> 7669726420656c75
> X12: b4da8e9ac000 X11: 04d78f4b6018 X10: b4da8e9afc50  X9: 
> 20676e6973756143
>  X8:   X7: 0e0045e5ce00  X6: 0e0045e5c000  X5: 61c5
>  X4: 0e0045020a58X3: b4da8e9afa30  X2: 
> 0e004502098c  X1: b4da8e9afa30
>  X0: 0124
> crash> dis testmod_init
> 0x04d78f4b6000 :   stp x29, x30, [sp,#-16]!
> 0x04d78f4b6004 :mov x29, sp
> 0x04d78f4b6008 :ldr x0, 0x04d78f4b6018
> 0x04d78f4b600c :   bl  0x04d78f4b6090
> 0x04d78f4b6010 :   ldr x0, 0x04d78f4b6020
> 0x04d78f4b6014 :   bl  0x04d78f4b6080
> 
>   => branch to a veneer
> crash> dis 0x04d78f4b6080 4
> 
> 0x04d78f4b6080 :   mov x16, #0x5120  // 
> #-44768
> 0x04d78f4b6084 :   movkx16, #0x4505, lsl #16
> 0x04d78f4b6088 :   movkx16, #0xe00, lsl #32
> 0x04d78f4b608c :  br  x16
> 
>   => branch to 0x0e0045055120
>(= panic())
> ===>8===
> 
> Is there any method to resolve such kind of indirect addressing
> to a symbolic name at dis command?
> (It may be difficult to discriminate PLT from normal branches, though).

Maybe something could be kludged up by the machdep->dis_filter() call?

In arm64_dis_filter(), whenever there is a "bl " instruction,
the 12 bytes at the PLT target address could be read, parsed, and the
real target address reconstructed.  If the reconstructed address resolves
to a kernel text address, it could be appended to the line.

Dave


 

> Thanks,
> -Takahiro AKASHI
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility