Re: [Crash-utility] [PATCH] Endian-mismatch: crash shows a contrary error message
δΊ 2014/9/30 22:08, Dave Anderson ει:
----- Original Message -----
> When the vmcore or vmlinux is not the same endian with the host,
> crash will give out a error message to show that mismatching, but
> the message itself is not correct.
> This patch fix that logical bug.
Interesting -- I've never been able to actually test this until now -- with
a ppc64/ppc64le combination. I'm guessing you saw this on a big-endian
32-bit ARM?
Yes, the kdump file i used was generated by a network device -- a
big-endian 32-bit ARM board.
As we all known, the network byte order is big-endian, so we chose to
use the same byte order on the network device. Actually, almost all the
network devices are big-endian.
Unfortunately, CRASH is not support big-endian yet. I've added some
codes to make it to pass through the init routines and make some
commands say, kmem -i, ps, log, etc. works.
It seems to me that you are interested about the big-endian enabled.But
the pathes are all too rough, so I havn't sent them out yet.For example,
when CRASH wants to use a unsigned long variable, it will first use
readmem() to get that, what I did was just make some reverse before
using it.
There is a discussion -- "gdb on KDUMP files" -- on the mailing list. I
have been considering something similar with that these days.If we can
use gdb to read the memory, the byte-order-problem will never be a
problem again, because gdb can change byte order automatically,
meanwhile it can change the byte order by sending a command "set endian
big(small/auto)".
Thanks,
Hu Keping
Good catch -- queued for crash-7.0.9:
https://github.com/crash-utility/crash/commit/5b78ac40710048705108cbd2e44...
Thanks,
Dave
>
> Signed-off-by: Hu Keping <hukeping(a)huawei.com>
> ---
> tools.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools.c b/tools.c
> index 4ff3fd5..cb684b1 100644
> --- a/tools.c
> +++ b/tools.c
> @@ -5515,12 +5515,12 @@ endian_mismatch(char *file, char dumpfile_endian,
> ulong query)
> case ELFDATA2LSB:
> if (__BYTE_ORDER == __LITTLE_ENDIAN)
> return FALSE;
> - endian = "big-endian";
> + endian = "little-endian";
> break;
> case ELFDATA2MSB:
> if (__BYTE_ORDER == __BIG_ENDIAN)
> return FALSE;
> - endian = "little-endian";
> + endian = "big-endian";
> break;
> default:
> endian = "unknown";
> --
> 1.8.5.5
>
>
.