Bug 19797

Summary: Unsupported powerpc bfd arch/machine variants
Product: gdb Reporter: Pedro Alves <pedro>
Component: tdepAssignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: alfedotov, bala071985, luoyonggang, qiyao, tromey
Priority: P2    
Version: HEAD   
Target Milestone: ---   
Host: Target:
Build: Last reconfirmed:
Attachments: Tentative fixes this issue

Description Pedro Alves 2016-03-09 16:07:56 UTC
BFD/binutils/ld know about a few powerpc machines/variants that GDB does not know about.

When users try to select one such bfd arch, they get:

 (gdb) set architecture powerpc:EC603e 
 Architecture `powerpc:EC603e' not recognized.
 The target architecture is set automatically (currently i386)

Which indicates that loading an elf file for such a machine will probably fail.

The full powerpc bfd arch set is:

 (gdb) set architecture powerpc:<TAB>
 403       EC603e    e5500
 601       MPC8XX    e6500
 603       a35       rs64ii
 604       common    rs64iii
 620       common64  titan
 630       e500      vle
 7400      e500mc    
 750       e500mc64  

The ones that are not handled are:

Comment 1 Alexander Fedotov 2016-07-04 14:27:00 UTC

It seems I have faced with the same issue, but with older GDB (7.8.2). It doesn't matter actually because source of rs6000-tdep.c not changed significantly.

I added SPRs description for PowerPC VLE target and want to force target description by "set architecture powerpc:vle".

But problem is more general as I understand. When gdb client is connected to remote target, it throws any attempts to set architecture in function "rs6000_gdbarch_init()" because tdesc_has_registers(tdesc) returns true.
Comment 2 Alexander Fedotov 2016-07-04 14:28:48 UTC
Forgot to say. When I start gdb with elf, I see that architecture is set to "powerpc:vle" automatically. But target description still incorrect.
Comment 3 Pedro Alves 2016-12-09 12:31:11 UTC
*** Bug 20951 has been marked as a duplicate of this bug. ***
Comment 4 Pedro Alves 2016-12-09 12:32:00 UTC
Comment 5 Pedro Alves 2016-12-09 12:38:49 UTC
(I hadn't pushed in that test because I thought that maybe we could split the testing over a few files, in order to parallelize and bring that minute down.  Like, rename the test file to "all-architectures.exp.in" or something, and
have e.g., 4 files named "all-architectures-[0-3].exp" that would just set some variable and source all-architectures.exp.in.  That variable would tell all-architectures.exp.in which slice of architectures to exercise.)
Comment 6 Balamurugan 2019-09-20 04:42:15 UTC

With GDB version > 8.2 while loading elf for ppc architecture I am getting following error "Architecture of file not recognized"

Debugging found that 

static bfd_boolean
ppc_elf_object_p (bfd *abfd) when defaulting to Powerpc:common the function looks for APU information choose architecture accordingly based on APU information. This results in arch (Powerpc:e500mc) and I believe support for this arch is not available( though I am note very sure) and gdb rejects this architecture.

Can we have following patch in place ?

In function
static bfd_boolean ppc_elf_object_p (bfd *abfd)

-  return _bfd_elf_ppc_set_arch (abfd);
+ if (abfd->arch_info->the_default)
+    return TRUE;
+ else
+    return _bfd_elf_ppc_set_arch (abfd);


With this code in place we will just treat as powerpc:common
Please let me know if this approach is correct.
Comment 7 Yonggang Luo 2021-03-26 04:07:31 UTC
Hi I am using GNU gdb (GDB) 10.1, and it's doesn't support for remote debugging


PS C:\work\xemu\xemu-with-lib> powerpc-none-eabi-gdb.exe C:/work/windriver/vxworks-6.9/qsp/default/vxWorks
GNU gdb (GDB) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "--host=x86_64-w64-mingw32 --target=powerpc-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
Find the GDB manual and other documentation resources online at:

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from C:/work/windriver/vxworks-6.9/qsp/default/vxWorks...
(gdb) set arch powerpc:e500mc
Architecture `powerpc:e500mc' not recognized.
The target architecture is set to "auto" (currently "powerpc:common").
(gdb) set arch powerpc:common64
Architecture `powerpc:common64' not recognized.
The target architecture is set to "auto" (currently "powerpc:common").
(gdb) set arch powerpc:e6500
Architecture `powerpc:e6500' not recognized.
The target architecture is set to "auto" (currently "powerpc:common").
Anyway to resolve the issue?
Comment 8 Yonggang Luo 2021-03-26 18:54:00 UTC
Created attachment 13330 [details]
Tentative fixes this issue

I've trying to fixes this issue, but raise an new error.
I am trying running 32bit elf binary on 64bit machine.

How to add 32bit binary support in rs6000_gdbarch_init?
Comment 9 Tom Tromey 2023-03-17 13:36:16 UTC
I've run into this as well.
In particular _bfd_elf_ppc_set_arch can pick "titan" for a file
I have, but gdb doesn't recognzie this.

Also, moving this to tdep.
Comment 10 Tom Tromey 2023-03-17 14:24:31 UTC
For my file, a sufficiently old gdb (7.10) works
(or at least -- it does not complain) but a newer
one fails.

It comes from this patch:

commit 14b57c7c6a53c747a8819fed3da858eae4195a0e
Author: Alan Modra <amodra@gmail.com>
Date:   Tue Jun 7 22:04:38 2016 +0930

    PowerPC VLE

I'm not a PPC expert so I don't know whether gdb should
be trying to handle ever bfd_mach_* value, or if some
fallback is appropriate instead.

I do see that the logic in _bfd_elf_ppc_set_arch is a little
strange in that the order of entries in the apuinfo can
affect the result.  Like in my file, the order is

   description data: 00 43 00 01 00 40 00 01 00 42 00 01 

so it moves through the loop like:

		  if (mach == bfd_mach_ppc_titan)
		    mach = bfd_mach_ppc_e500mc;

		  if (mach == 0)
		    mach = bfd_mach_ppc_titan;

... so it ends up picking 'titan'.  But if the entries
were reordered, it would pick e500mc instead (which gdb
also doesn't handle :-)
Comment 11 Tom Tromey 2023-03-17 14:43:59 UTC
I don't think I'll look into this any more, but I do
wonder if gdb should perhaps fall back to some more generic
PPC if it find a bfd_mach_* value that it doesn't expect.
I don't know whether this is correct or not, but it might
let debugging work "well enough", whereas right now you can
be wholly prevented from doing anything if the remote, say,
reports a .so that gdb doesn't understand.