6:49 a.m.
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.
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
9:08 a.m.
----- 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?
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
10:53 p.m.
于 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
>
>
.
8:41 a.m.
----- Original 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.
Let me be clear from the start -- I am *not* interested in such an invasive
patch-set such as this. If you search the archives for the "cross-crash"
discussions several years ago, you can see that such support in the
top-level crash sources is far to invasive to accept at this point.
It was a 13000+ line patchset that touched virtually every file/function
in the top-level crash sources. It also made the simplest of source file
functions difficult to understand and maintain. It was eventually branched
into its own tree:
http://sourceforge.net/projects/crosscrash/
But given that it's still apparently based upon crash-4.0.3, I think it's
pretty much abandoned.
If you cannot look at your big-endian dumpfiles on a big-endian host, I
would suggest considering creating your own branch.
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)".
The vast majority of dumpfile reads are initiated from the crash sources
and utilize its readmem() function, and don't involve gdb. When crash uses
does use the embedded gdb to accomplish a read, gdb calls its target_read_memory()
function, which is patched to pass the request back up to the crash readmem()
function. Perhaps there is a way gdb could somehow be leveraged to perform the
byte-order switch from readmem()?
Thanks,
Dave
3622
days inactive
3630
days old
devel@lists.crash-utility.osci.io
3 comments
3 participants
participants (3)
-
Dave Anderson -
Hu Keping -
HuKeping