Re: [CRIS] Reading core file selects "wrong" mach

[Mark Kettenis <kettenis@gnu.org>]

   Date: Wed, 01 Dec 2004 14:59:55 +0100
   From: Orjan Friberg <orjan.friberg@axis.com>

   The reason seems to be the call to bfd_default_set_arch_mach (abfd,
   ebd->arch, 0) in elf_core_file_p in elfcore.h which will select the
   default mach for that arch.  Directly after this we start reading the
   core file which results in a call to cris_elf_grok_prstatus (which
   fails because the default mach doesn't match the current mach).

Without that call to bfd_default_set_arch_mach(), the
architecture/machine wouldn't be set at all for the core file BFD.

   Is there an implicit assumption that the mach is not to be trusted
   when reading a core file?

What do you mean by "not to be trusted"?  It's simply always set to
the default machine for ELF core files.  For most architectures this
is what makes the most sense anyway.  Setting it to anything different
from the default would involve some architecture-dependent code.  I
guess the correct way to do this would be adding
elf_set_mach_from_flags() to `struct elf_backend_data', and use that
in elf_core_file_p() to set the machine after the architecture has
been set.

In principle, GDB can deal with core file BFD's that set the BFD
machine as well as the BFD architecture.  This is done in
netbsd-core.c to distinguish between 32-bit and 64-bit processors
(sparc vs. sparc64, i386 vs. amd64).  There are some issue's though
with compatibility between various BFD machines.  Depending on how
compatibility is defined for a certain BFD architecture, you might
need to register a GDB OS/ABI for every BFD machine for your BFD
architecture.

   (For reference: e_flags, checked in set_mach_from_flags, is
   hardcoded to 0 in the Linux kernel, but setting it correctly (to
   EF_CRIS_VARIANT_V32 in this case) wouldn't change a thing because
   of the above.)

(That would have to change then.  The file gcore.c will probably also
need some changes.)

Mark