[Crash-utility] [PATCH] Improve error handling when architecture doesn't match

[Dave Anderson]

Bernhard Walle wrote:
> * Dave Anderson <anderson at redhat.com> [2007-12-21 15:42]:
> 
>>Bernhard Walle wrote:
>>
>>>* Dave Anderson <anderson at redhat.com> [2007-12-21 15:25]:
>>>
>>>
>>>>Bernhard Walle wrote:
>>>>
>>>>
>>>>>* Dave Anderson <anderson at redhat.com> [2007-12-21 15:00]:
>>>>>
>>>>>
>>>>>
>>>>>>I like the addition of the machine-type verification error message.
>>>>>>
>>>>>>But why bother with the endian check?  Using your ppc64/x86_64
>>>>>>example, an architecture check/error message would make far
>>>>>>more sense.  The "endianness" error message implies that if
>>>>>>they re-compiled their ppc64 kernel little-endian that things
>>>>>>would work.
>>>>>
>>>>>
>>>>>I added it because if the dump is BE (like PPC64) then the
>>>>>elf64->e_type == ET_CORE check (also with ELF32) is always false and
>>>>>the code never got into the switch that checks the machine type.
>>>>
>>>>I don't follow -- the e_type is not ET_CORE?
>>>
>>>
>>>Well, it is, but not 0x??04 but 0x04??. But of course, it's also
>>>possible to check the byte-toggled value. I'll send a new patch.
>>
>>Won't that also affect the e_machine, e_version, e_phnum fields
>>as well?
> 
> 
> Yeah.
> 

Maybe it should cut down on the initial 32/64-bit verifier
to check only the ELFMAG and the bytes in the E_IDENT string.
Then inside of the 32 and 64 bit blocks, first check for
the architecture and bail out with a "arch-mismatch" error.
(although in doing so, the e_machine switch statement would
have to have cases for each arch and its byte-toggled version)

Then the current endian check could be made, and if it
doesn't match bail out with an "endian" error.

And then for sanity's sake, the remainder of header checks
could be done, which if we get that far, are pretty much
guaranteed to never happen.

Something like that...

Dave