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

[Mark Kettenis <kettenis at gnu dot org>]

   Date: Mon, 13 Dec 2004 15:41:05 +0100
   From: Orjan Friberg <orjan.friberg@axis.com>

   >    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

   What I meant was that I couldn't find any other port that looked at
   the mach in their grok_prstatus/grok_prinfo, which led me to think
   there might be a reason they didn't.

Well, needlessly setting the machine could cause problems, and we
shouldn't blindly do that.  But I think it's safe to say that it's
just because it didn't matter.  GDB didn't really pay attention to the
architecture of the core file until rather recently.

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

   Yes, that makes sense.  Thanks.

   I guess the answer to this is 'no', but would it be possible (and
   correct) to use whatever machine was set when loading the
   corresponding program into GDB?

No.  (See you got it right.)  The machine in the core file doesn't
necessarily match the machine for the loaded executable.  This mainly
arises in 32-bit x 64-bit cross-debugging.  Some 64-bit operating
systems will generate 64-bit core files, even when running 32-bit
code.  GDB uses the machine type to recognize the layout of the core
file in such a situation.  Example are sparc/sparcv9 or i386/x86_64.

Mark