Re: [Crash-utility] vmss.core and kernel dbgsym do not match!
- Original Message - > Hi, > > In reference to bug : https://bugzilla.redhat.com/show_bug.cgi?id=233151 > > I have the same problem trying to analyze a vmss.core file with kernel > v4.4.0-36-generic (Ubuntu) : > q > crash: /usr/lib/debug/boot/ vmlinux-4.4.0-36-generic and /var/vmss_m.core do > not match! > > I also tried with the following (as recommended in the bug threads) without > success : > --machdep phys_base=0x20 That was an old Xen RHEL5 kernel issue, so I don't know if that applies to your 4.4-based VMware vmss dumpfile (?). Although I only have a 4 sample vmss dumpfiles, one of does happen to be a RHEL5 kernel and it does require --machdep phys_base=0x20. But it's certainly possible that could be the issue. If you run the guest again and log into it, you could try running crash on the live system. If it comes up OK, run the "help -m" command and grep for "phys_base". Then try that value as the --machdep phys_base= argument with the dumpfile. Worse case, you could try different phys_base values and basically fish for the correct value. > > > > I'm using the right -dbgsym for the right kernel as confirmed here : > > > $ strings vmss_m.core | grep "Linux version" > Linux version 4.4.0-36-generic (buildd@lgw01-20) (gcc version 4.8.4 (Ubuntu > 4.8.4-2ubuntu1~14.04.3) ) #55~14.04.1-Ubuntu SMP Fri Aug 12 11:49:30 UTC > 2016 (Ubuntu 4.4.0-36.55~14.04.1-generic 4.4.16) What does "strings vmlinux-4.4.0-36-generic" show? You'll need to verify that the full string above is exactly the same. > > > $ readelf -a vmss_m.core > > Program Headers: > Type Offset VirtAddr PhysAddr > FileSiz MemSiz Flags Align > NOTE 0x00e8 0x 0x > 0x0218 0x 0 > LOAD 0x80001000 0xfff8 0xfff8 > 0x0008 0x0008 RWE 1000 > LOAD 0x1000 0x 0x > 0x8000 0x8000 RWE 1000 > > The VirtAddr and PhysAddr are just zero. It's the PhysAddr that's the key to crash -- the header is showing that the dumpfile contains 2GB (0x8000) of physical memory starting at physical address 0. > > > I tried with the latest and greatest crash-utility from [ > https://github.com/crash-utility/crash.git ] using version 7.1.5++ but this > has no effect, I still have the error : > > crash: /usr/lib/debug/boot/ vmlinux-4.4.0-36-generic and /var/vmss_m.core do > not match! > > Any ideas ? > > - Eric If you show the output of "crash -d8 ..." it may yield some more clues. Dave -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
[Crash-utility] vmss.core and kernel dbgsym do not match!
Hi, In reference to bug : https://bugzilla.redhat.com/show_bug.cgi?id=233151 I have the same problem trying to analyze a vmss.core file with kernel v4.4.0-36-generic (Ubuntu) : crash: /usr/lib/debug/boot/*vmlinux-4.4.0-36-generic* and /var/vmss_m.core do not match! I also tried with the following (as recommended in the bug threads) without success : --machdep phys_base=0x20 I'm using the right -dbgsym for the right kernel as confirmed here : $ strings vmss_m.core | grep "Linux version" Linux version *4.4.0-36-generic* (buildd@lgw01-20) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.3) ) #55~14.04.1-Ubuntu SMP Fri Aug 12 11:49:30 UTC 2016 (Ubuntu 4.4.0-36.55~14.04.1-generic 4.4.16) $ readelf -a vmss_m.core Program Headers: Type Offset VirtAddr PhysAddr FileSizMemSiz Flags Align NOTE 0x00e8 0x 0x 0x0218 0x 0 LOAD 0x80001000 0xfff8 0xfff8 0x0008 0x0008 RWE1000 LOAD 0x1000 0x 0x 0x8000 0x8000 RWE1000 The VirtAddr and PhysAddr are just zero. I tried with the latest and greatest crash-utility from [https://github.com/crash-utility/crash.git] using version 7.1.5++ but this has no effect, I still have the error : crash: /usr/lib/debug/boot/*vmlinux-4.4.0-36-generic* and /var/vmss_m.core do not match! Any ideas ? - Eric -- Crash-utility mailing list Crash-utility@redhat.com https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [RFC] arm64: symbolize PLT entries in disassembling module functions
Takahiro,
Nice! Queued for crash-7.1.6:
https://github.com/crash-utility/crash/commit/f08a9c8bceadcbd15a21b5dc314aa84353a26547
Thanks,
Dave
- Original Message -
> Signed-off-by: AKASHI Takahiro
> ---
> arm64.c | 69
> +
> 1 file changed, 69 insertions(+)
>
> diff --git a/arm64.c b/arm64.c
> index b9fa14d..8235e3c 100644
> --- a/arm64.c
> +++ b/arm64.c
> @@ -2540,6 +2540,59 @@ arm64_is_task_addr(ulong task)
> return (IS_KVADDR(task) && (ALIGNED_STACK_OFFSET(task) == 0));
> }
>
> +static ulong
> +PLT_veneer_to_kvaddr(ulong value)
> +{
> + uint32_t insn;
> + ulong addr = 0;
> + int i;
> +
> + /*
> + * PLT veneer always looks:
> + * movn x16, #0x
> + * movk x16, #0x, lsl #16
> + * movk x16, #0x, lsl #32
> + * br x16
> + */
> + for (i = 0; i < 4; i++) {
> + if (!readmem(value + i * sizeof(insn), KVADDR, &insn,
> + sizeof(insn), "PLT veneer", RETURN_ON_ERROR)) {
> + error(WARNING, "cannot read PLT veneer\n");
> + return value;
> + }
> + switch (i) {
> + case 0:
> + if ((insn & 0xffe0001f) != 0x92800010)
> + goto not_plt;
> + addr = ~((ulong)(insn & 0x1fffe0) >> 5);
> + break;
> + case 1:
> + if ((insn & 0xffe0001f) != 0xf2a00010)
> + goto not_plt;
> + addr &= 0x;
> + addr |= (ulong)(insn & 0x1fffe0) << (16 - 5);
> + break;
> + case 2:
> + if ((insn & 0xffe0001f) != 0xf2c00010)
> + goto not_plt;
> + addr &= 0x;
> + addr |= (ulong)(insn & 0x1fffe0) << (32 - 5);
> + break;
> + case 3:
> + if (insn != 0xd61f0200)
> + goto not_plt;
> + break;
> + default:
> + return value; /* to avoid any warnings */
> + }
> + }
> +
> + return addr;
> +
> +not_plt:
> + return value;
> +}
> +
> /*
> * Filter dissassembly output if the output radix is not gdb's default 10
> */
> @@ -2589,6 +2642,22 @@ arm64_dis_filter(ulong vaddr, char *inbuf, unsigned
> int output_radix)
> sprintf(p1, "%s", buf1);
> }
>
> + if (IS_MODULE_VADDR(vaddr)) {
> + ulong orig_value;
> +
> + p1 = &inbuf[strlen(inbuf)-1];
> + strcpy(buf1, inbuf);
> + argc = parse_line(buf1, argv);
> +
> + if ((STREQ(argv[argc-2], "b") || STREQ(argv[argc-2], "bl")) &&
> + extract_hex(argv[argc-1], &orig_value, NULLCHAR, TRUE)) {
> + value = PLT_veneer_to_kvaddr(orig_value);
> + sprintf(p1, " <%s%s>\n",
> + value == orig_value ? "" : "plt:",
> + value_to_symstr(value, buf2, output_radix));
> + }
> + }
> +
> console("%s", inbuf);
>
> return TRUE;
> --
> 2.10.0
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
Re: [Crash-utility] [PATCH] arm64: exclude mapping symbols in modules
On Tue, Oct 11, 2016 at 10:57:37AM +0900, AKASHI Takahiro wrote:
> Dave,
>
> On Fri, Oct 07, 2016 at 11:02:01AM -0400, Dave Anderson wrote:
> >
> > - Original Message -
> > > Dave,
> > >
> > > >
> > > > Now, this sample patch doesn't deal with branch instructions other than
> > > > "bl",
> > > > so perhaps it could just check whether the last argument in the
> > > > instruction
> > > > line is a translatable address.
> > > >
> > > > On the other hand, for the PLT veneer issue, it would have to:
> > > >
> > > > (1) make sure it's a "bl", and
> > >
> > > and other variants of "bl"
> >
> > Specifically what other variants? Do you mean any instruction that begins
> > with "b."?
>
> I double-checked and found out that R_AARCH64_CALL26 and R_AARCH64_JUMP are
> the only elf relocation types for which PLT veneers will be generated at
> module loading.
> That is, "b" and "bl," but "b" is unlikely.
>
> > >
> > > > (2) instead of blindly doing a translation of the PLT veneer label
> > > > address,
> > > > it would first have to check whether it points to a 12-byte chunk
> > > > of
> > > > kernel address construction, and if so, translate the reconstructed
> > > > address.
> > >
> > > Actually, a veneer always consists of 4 instructions:
> > > mov x16, #imm16
> > > movk x16, #imm16, lsl #16
> > > movk x16, #imm16, lsl #32
> > > br x16
> >
> > Right, I meant that the target address is constructed in the first 12 bytes.
> >
> > I'm not at all familiar with arm64 assembly. It seems that each of the
> > instructions consume 4 bytes, but unlike the other architectures, I cannot
> > find any documentation as to how the instruction type, the target register,
> > the immediate value, etc., actually get encoded into the 32-bit instruction.
> > The documentation shows the assembly mnemonics themselves, but not how the
> > instruction is actually laid out it in memory. Maybe I'm looking in the
> > wrong
> > place.
>
> Well, formally, you should consult, what is called, "ARM ARM(Architecture
> Reference Manual," but practically, you can find all the information that
> you need in arch/arm64/kernel/module-plts.c.
>
> > Taking the simplest of examples, here's a mov immediate instruction:
> >
> > crash> dis 0xfe0fbc84 2
> > 0xfe0fbc84 : mov x7,
> > #0x // #-1
> > 0xfe0fbc88 : add x0, x0, x26
> > crash>
> >
> > And here's the encoding:
> >
> > crash> rd -32 0xfe0fbc84
> > fe0fbc84: 9287
> > crash>
> >
> > Presumably the 7 is the register field, but how does it get -1 out of the
> > rest
> > of the instruction?
>
> Haha, mov is not mov, but movn (inverted immediate).
> the inverse of bit[20:5] will be stored in x7.
>
> > Anwyay, without some basic understanding, I'm not touching this. I was
> > kind
> > of hoping you could whip up the function... ;-)
>
> I hope so if I have time this week.
Please take a look at my RFC. Disassembled code looks like:
crash> mod -S ./
MODULE NAME SIZE OBJECT FILE
04d78f4b8000 testmod 16384 ./testmod.ko
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
Thanks,
-Takahiro AKASHI
> > > It would be safe to identify any veneers with this type of sequence,
> > > but I'm wondering if there is any other trick of directly checking
> > > if the label address is fit in PLT section of a module.
> >
> > I have no idea.
> >
> > > (On arm64, this section is dynamically allocated on module loading,
> > > and so it's not trivial.)
> > >
> > > >
> > > > So I'm thinking something along these lines, say, where "value" may or
> > > > may
> > > > not be modified by your new function:
> > > >
> > > >if (IS_MODULE_VADDR(vaddr)) {
> > > >p1 = &inbuf[strlen(inbuf)-1];
> > > >strcpy(buf1, inbuf);
> > > >argc = parse_line(buf1, argv);
> > > >if (STREQ(argv[argc-2], "bl") &&
> > > >extract_hex(argv[argc-1], &value, NULLCHAR, TRUE)) {
> > > > + value = PLT_veneer_to_kvaddr(value);
> > > >sprintf(p1, " <%s>\n",
> > > >value_to_symstr(value, buf2,
> > > > output_radix));
> > > >}
> > > >}
> > >
> > > Looks nice.
> > >
> > > > However, another thing to consider is what "dis" shows if the "mod"
> > > > command
> > > > has already loaded the debuginfo data. In that case, I'm guessing that
> > > > gdb
> > > > would translate the address of the PLT veneer location?
> > >
> > > Give that the output from "bt" command shows "test
[Crash-utility] [RFC] arm64: symbolize PLT entries in disassembling module functions
Signed-off-by: AKASHI Takahiro
---
arm64.c | 69 +
1 file changed, 69 insertions(+)
diff --git a/arm64.c b/arm64.c
index b9fa14d..8235e3c 100644
--- a/arm64.c
+++ b/arm64.c
@@ -2540,6 +2540,59 @@ arm64_is_task_addr(ulong task)
return (IS_KVADDR(task) && (ALIGNED_STACK_OFFSET(task) == 0));
}
+static ulong
+PLT_veneer_to_kvaddr(ulong value)
+{
+ uint32_t insn;
+ ulong addr = 0;
+ int i;
+
+ /*
+* PLT veneer always looks:
+ * movn x16, #0x
+ * movk x16, #0x, lsl #16
+ * movk x16, #0x, lsl #32
+ * br x16
+*/
+ for (i = 0; i < 4; i++) {
+ if (!readmem(value + i * sizeof(insn), KVADDR, &insn,
+ sizeof(insn), "PLT veneer", RETURN_ON_ERROR)) {
+ error(WARNING, "cannot read PLT veneer\n");
+ return value;
+ }
+ switch (i) {
+ case 0:
+ if ((insn & 0xffe0001f) != 0x92800010)
+ goto not_plt;
+ addr = ~((ulong)(insn & 0x1fffe0) >> 5);
+ break;
+ case 1:
+ if ((insn & 0xffe0001f) != 0xf2a00010)
+ goto not_plt;
+ addr &= 0x;
+ addr |= (ulong)(insn & 0x1fffe0) << (16 - 5);
+ break;
+ case 2:
+ if ((insn & 0xffe0001f) != 0xf2c00010)
+ goto not_plt;
+ addr &= 0x;
+ addr |= (ulong)(insn & 0x1fffe0) << (32 - 5);
+ break;
+ case 3:
+ if (insn != 0xd61f0200)
+ goto not_plt;
+ break;
+ default:
+ return value; /* to avoid any warnings */
+ }
+ }
+
+ return addr;
+
+not_plt:
+ return value;
+}
+
/*
* Filter dissassembly output if the output radix is not gdb's default 10
*/
@@ -2589,6 +2642,22 @@ arm64_dis_filter(ulong vaddr, char *inbuf, unsigned int
output_radix)
sprintf(p1, "%s", buf1);
}
+ if (IS_MODULE_VADDR(vaddr)) {
+ ulong orig_value;
+
+ p1 = &inbuf[strlen(inbuf)-1];
+ strcpy(buf1, inbuf);
+ argc = parse_line(buf1, argv);
+
+ if ((STREQ(argv[argc-2], "b") || STREQ(argv[argc-2], "bl")) &&
+ extract_hex(argv[argc-1], &orig_value, NULLCHAR, TRUE)) {
+ value = PLT_veneer_to_kvaddr(orig_value);
+ sprintf(p1, " <%s%s>\n",
+ value == orig_value ? "" : "plt:",
+ value_to_symstr(value, buf2, output_radix));
+ }
+ }
+
console("%s", inbuf);
return TRUE;
--
2.10.0
--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
