Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jan Kratochvil <jan.kratochvil@redhat.com>
To: gdb-patches@sourceware.org
Cc: Thiago Jung Bauermann <bauerman@br.ibm.com>,
	        Peter Bergner <bergner@vnet.ibm.com>
Subject: [patch] Fix power7 ppc64 binaries loading
Date: Mon, 02 Mar 2009 21:03:00 -0000	[thread overview]
Message-ID: <20090302210237.GA23798@host0.dyn.jankratochvil.net> (raw)

Hi,

on the binary from:
./gas/as-new -mpower7 -o /tmp/power7c.o ./gas/testsuite/gas/ppc/power7.s
  Class:                             ELF64
  Machine:                           PowerPC64
Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 4] .PPC.EMB.apuinfo  PROGBITS         0000000000000000  000001e0
       0000000000000018  0000000000000000           0     0     1

FSF GDB HEAD prints:
$ ./gdb -q -nx -ex 'set pagination off' -ex 'x/100i 0' /tmp/power7.o 
</dev/null 
Architecture of file not recognized.
0x0: Cannot access memory at address 0x0
(gdb) quit

With the attached patch it prints an instruction dump.

It is a regression for power7 ppc64 binaries by:
http://sourceware.org/ml/gdb-patches/2002-08/threads.html#00629
http://sourceware.org/ml/gdb-cvs/2002-08/msg00263.html

> A powerpc executable doesn't have indications of which variant it is meant to
> run on.
There is the tdesc_* infrastructure for this purpose for remote targets, there
is a `info->disassembler_options = "any"' hack for local target by:
http://sourceware.org/ml/gdb-patches/2007-02/msg00000.html
http://sourceware.org/ml/gdb-cvs/2007-02/msg00061.html

Regression tested on powerpc64-unknown-linux-gnu (PPC970MP).


Thanks,
Jan

gdb/
2009-03-02  Jan Kratochvil  <jan.kratochvil@redhat.com>

	Fix power7 ppc64 binaries loading.
	* rs6000-tdep.c (rs6000_gdbarch_init): Remove variable `sect'.  Remove
	the ppc32 e500 detection from `.PPC.EMB.apuinfo' section existence.

diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c
index 926d0b6..1c59a42 100644
--- a/gdb/rs6000-tdep.c
+++ b/gdb/rs6000-tdep.c
@@ -3326,7 +3331,6 @@ rs6000_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
   enum bfd_architecture arch;
   unsigned long mach;
   bfd abfd;
-  asection *sect;
   enum auto_boolean soft_float_flag = powerpc_soft_float_global;
   int soft_float;
   enum powerpc_vector_abi vector_abi = powerpc_vector_abi_global;
@@ -3375,26 +3379,6 @@ rs6000_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
   arch = info.bfd_arch_info->arch;
   mach = info.bfd_arch_info->mach;
 
-  /* For e500 executables, the apuinfo section is of help here.  Such
-     section contains the identifier and revision number of each
-     Application-specific Processing Unit that is present on the
-     chip.  The content of the section is determined by the assembler
-     which looks at each instruction and determines which unit (and
-     which version of it) can execute it. In our case we just look for
-     the existance of the section.  */
-
-  if (info.abfd)
-    {
-      sect = bfd_get_section_by_name (info.abfd, ".PPC.EMB.apuinfo");
-      if (sect)
-	{
-	  arch = info.bfd_arch_info->arch;
-	  mach = bfd_mach_ppc_e500;
-	  bfd_default_set_arch_mach (&abfd, arch, mach);
-	  info.bfd_arch_info = bfd_get_arch_info (&abfd);
-	}
-    }
-
   /* Find a default target description which describes our register
      layout, if we do not already have one.  */
   if (! tdesc_has_registers (tdesc))


             reply	other threads:[~2009-03-02 21:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-02 21:03 Jan Kratochvil [this message]
2009-03-02 21:24 ` Daniel Jacobowitz
2009-03-02 21:34   ` Jan Kratochvil
2009-03-03 20:24     ` Thiago Jung Bauermann
2009-03-03 20:31       ` Daniel Jacobowitz
2009-03-03 20:54         ` Peter Bergner
2009-03-03 23:16           ` Alan Modra
2009-03-03 23:30             ` Joseph S. Myers
2009-03-03 23:36               ` Daniel Jacobowitz
2009-03-03 23:48               ` Alan Modra
2009-03-03 23:54                 ` Joseph S. Myers
2009-03-03 23:49             ` Thiago Jung Bauermann
2009-03-03 23:54               ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090302210237.GA23798@host0.dyn.jankratochvil.net \
    --to=jan.kratochvil@redhat.com \
    --cc=bauerman@br.ibm.com \
    --cc=bergner@vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox