Hi

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.

Forgot to say. When I start gdb with elf, I see that architecture is set to "powerpc:vle" automatically. But target description still incorrect.

*** Bug 20951 has been marked as a duplicate of this bug. ***

Related:
 https://sourceware.org/ml/gdb-patches/2016-03/msg00132.html

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

Hi,

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.

Hi I am using GNU gdb (GDB) 10.1, and it's doesn't support for remote debugging

powerpc:e500mc
powerpc:common64
powerpc:e6500

```
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:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

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").
(gdb)
```
Anyway to resolve the issue?

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?

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.

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

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.