[CRIS] Reading core file selects "wrong" mach

[CRIS] Reading core file selects "wrong" mach

[Orjan Friberg]

When reading a CRISv32 Linux core file, the "wrong" mach is selected, causing 
cris_elf_grok_prstatus to not find the general-purpose registers (because unlike 
other ports it actually checks bfd_get_mach (abfd)).

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

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

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

-- 
Orjan Friberg
Axis Communications

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

[Randolph Chung]

> (For reference: e_flags, checked in set_mach_from_flags, is hardcoded to 0 in 
> the Linux kernel,

fwiw this is no longer true in 2.6 kernels, you can override this by
setting "#define ELF_OSABI xxx" in your asm-xxx/elf.h. see parisc for an
example.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

[Orjan Friberg]

Randolph Chung wrote:
>>(For reference: e_flags, checked in set_mach_from_flags, is hardcoded to 0 in 
>>the Linux kernel,
> 
> 
> fwiw this is no longer true in 2.6 kernels, you can override this by
> setting "#define ELF_OSABI xxx" in your asm-xxx/elf.h. see parisc for an
> example.

Ok, but that sets e_ident[EI_OSABI] and not e_flags.  (Or did I misunderstand 
your point?)

-- 
Orjan Friberg
Axis Communications

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

[Randolph Chung]

> >fwiw this is no longer true in 2.6 kernels, you can override this by
> >setting "#define ELF_OSABI xxx" in your asm-xxx/elf.h. see parisc for an
> >example.
> 
> Ok, but that sets e_ident[EI_OSABI] and not e_flags.  (Or did I 
> misunderstand your point?)

no, i misunderstood what you were trying to do. but you can easily
change this in the kernel as well.... not that it will help you if you
need this to work with old kernels, but on parisc we decided to just
change this (i.e. ELF_OSABI) rather than hacking things in the 
toolchain.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

[Mark Kettenis]

   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

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

[Orjan Friberg]

Mark Kettenis wrote:
>    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.

Yes, I didn't mean to say that the call to bfd_default_set_arch_mach was wrong 
or superfluous, I was just describing the effect it had.

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

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

-- 
Orjan Friberg
Axis Communications

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

[Hans-Peter Nilsson]

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

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

(I assume by that, you mean "as opposed to the core file".)
IMHO when there's a difference, the mach setting from the core
file should override (or at least augment) what's in the
program, because the core file supposedly comes from the "real"
hardware, so it supposedly has a narrower mach setting than that
in the program.  Incompatible differences should be flagged as
an error (as in: wrong program used with the core file).
So, in my opinion "no".

(In this case, I think there should be no difference in mach
settings between core and program, but that wasn't the
question.)

brgds, H-P

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

[Mark Kettenis]

   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

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

[Orjan Friberg]

Mark Kettenis wrote:
> 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.

Maybe there's an easier way to do it - simply call the elf backend before 
processing the program headers, and have the backend set the correct machine 
like they all seem to do already.  Since the decision of whether to act on the 
e_flags value is pushed to the elf backend I don't see how this could break 
anything (which I assume could happen if it was done in elf_core_file_p).

(Of course, for this to have any effect in my particular case, e_flags must be 
set in the core file.)

I understand this will have to be sent to the binutils mailing list for 
approval, but I'd appreciate if someone on this list could tell me if it's a 
sane solution.

Oh, and no regressions on i386 and CRIS.


2005-01-14  Orjan Friberg  <orjanf@axis.com>

	* elfcore.h (elf_core_file_p): Move the call to elf_backend_object_p
	to allow the correct machine to be set before processing the program
	headers.


  Index: elfcore.h
===================================================================
RCS file: /cvs/src/src/bfd/elfcore.h,v
retrieving revision 1.20
diff -u -p -r1.20 elfcore.h
--- elfcore.h	7 Aug 2003 08:38:09 -0000	1.20
+++ elfcore.h	14 Jan 2005 17:03:02 -0000
@@ -214,6 +214,15 @@ elf_core_file_p (bfd *abfd)
  	goto fail;
      }

+  /* Let the backend double check the format and override global
+     information.  We do this before processing the program headers
+     to allow the correct machine (as opposed to just the default
+     machine) to be set, making it possible for grok_prstatus and
+     grok_psinfo to rely on the mach setting.  */
+  if (ebd->elf_backend_object_p
+      && (! (*ebd->elf_backend_object_p) (abfd)))
+    goto wrong;
+
    /* Process each program header.  */
    for (phindex = 0; phindex < i_ehdrp->e_phnum; ++phindex)
      if (! bfd_section_from_phdr (abfd, i_phdrp + phindex, (int) phindex))
@@ -222,12 +231,6 @@ elf_core_file_p (bfd *abfd)
    /* Save the entry point from the ELF header.  */
    bfd_get_start_address (abfd) = i_ehdrp->e_entry;

-  /* Let the backend double check the format and override global
-     information.  */
-  if (ebd->elf_backend_object_p
-      && (! (*ebd->elf_backend_object_p) (abfd)))
-    goto wrong;
-
    bfd_preserve_finish (abfd, &preserve);
    return abfd->xvec;


-- 
Orjan Friberg
Axis Communications

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

[Hans-Peter Nilsson]

> Date: Fri, 14 Jan 2005 18:10:33 +0100
> From: Orjan Friberg <orjanf@axis.com>

> Maybe there's an easier way to do it - simply call the elf backend before 
> processing the program headers, and have the backend set the correct machine 
> like they all seem to do already.  Since the decision of whether to act on the 
> e_flags value is pushed to the elf backend I don't see how this could break 
> anything (which I assume could happen if it was done in elf_core_file_p).

Sure.  Seems right at a glance, but you should check
elf_backend_object_p of all ports so they don't use data set in
the code around which you moved the call.

> I understand this will have to be sent to the binutils mailing list for 
> approval, but I'd appreciate if someone on this list could tell me if it's a 
> sane solution.

The people at binutils@ are supposedly more aware of issues
related to this kind of change, meaning you're likely to get
more initiated feedback there regarding the saneness.

mvh H-P