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) (gdb) 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: powerpc:EC603e powerpc:e500mc powerpc:e500mc64 powerpc:vle powerpc:titan powerpc:e5500 powerpc:e6500
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.