[Crash-utility] [PATCH] Endian-mismatch: crash shows a contrary error message

[Dave Anderson]

----- 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