[Crash-utility] dis command not correct in crash [ARM]

[Lei Wen]

Per,

On Fri, Mar 8, 2013 at 3:46 AM, Per Fransson <per.fransson.ml at gmail.com> wrote:
> Hi,
>
>>> Are you able to test with the same GDB version that is embedded in crash?
>>>
>>> I'm running out of ideas (I sure hope Per figures out what is going on :-)).
>>
>> Thanks for that vote of confidence =o)
>>
>> Alas, I must confess,
>> all I have is a guess
>> that "dot text" is partly a mess
>> ...no less
>>
>> /Per
>>
>>> Are you able to make the vmlinux/vmcore pair available to us?
>>>
>
> Short version:
> ##############
> It's the compressed kernel, including decompression stub, occupying
> the first 0x3ffe00 bytes of .text
>
> Long version:
> #############
> I extracted the .text parts of the vmlinux and dump and diffed:
>
> vmlinux
> -------
> .text:
> start: 0x0081c0 = 33216
> size:  0x4a85d4 = 4883924
> dd bs=1 count=4883924 skip=33216 if=vmlinux of=vmlinux_text
>
> dump
> ----
> .text:
> start: 0xc01081c0 - 0xc0000000 + 0x94 = 1081940
> size:  0x4a85d4 = 4883924
> dd bs=1 count=4883924 skip=1081940 if=233_0128.dump of=dump_text
>
> First I thought I had made a mistake, because, to begin with, it's all
> different, but then, after 0x3ffe00 bytes (that'd correspond to
> virtual address 0xc01081c0+0x3ffe00=0xc0507fc0 in crash), it's all
> identical (except for __v7_setup_stack, which for some reason is
> placed in .text.) This made me run 'string' on the data in those first
> 0x3ffe00 bytes of .text and they looked kind of familiar, for example:
>
>    3baf  -- System halted
>    3bc1 Attempting division by 0!
>    3bdb Uncompressing Linux...
>    3bf2 decompressor returned an error
>    3c11  done, booting the kernel.
>
> and that's when I realized it was the image from
> arch/arm/boot/compressed. I think you've loaded a new (capture?)
> kernel at the location where the original one was loaded before
> pulling out the dump. I also predict there will be a cut-off point at
> virtual address 0xc0507fc0, with all the code at lower addresses being
> bad and everything else being ok.
>
> If you need to you can probably replace those 0x3ffe00 bytes of the
> dump with those from the vmlinux.

Thanks for this finding!
It would well explain my previous issue now!

Thanks,
Lei