Hi Chris and I discussed this for a few minutes last night and wondered if code like this which includes arbitrary CPU model specific code could be the culprit?
https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c#n65 There may be other sections that do this. If this were wrapped in a conditional for the proper CPU core variants, it might resolve the issue. One would hope that if there were no e500 code, binutils and gdb wouldn't get confused. --joel On Wed, Mar 27, 2024 at 12:19 PM Peter Dufault <dufa...@hda.com> wrote: > The PowerPC e7400 executables I built for the PowerPC-Beatnik BSP have an > architecture of "powerpc:e500". I assume it is like this for any powerpc > target that includes "ppc_exc_initialize.c". This causes "GDB" to use the > wrong size register set in remote debugging, and I couldn't figure out how > to convince "gdb" to do something different. I tried multiple settings but > the "bfd_arch_info" wouldn't change from "powerpc:e500" (seen with "maint > print architecture") and "gdb" continued to use the wrong register set size. > > (gdb) set powerpc vector-abi altivec > (gdb) set arch powerpc:7400 > The target architecture is set to "powerpc:7400". > (gdb) set gnutarget powerpc:7400 > (gdb) target remote 192.168.240.3:2159 > Remote debugging using 192.168.240.3:2159 > Remote 'g' packet reply is too long (expected 292 bytes, got 412 bytes): > 003a5914007a0ae0007a7b6000000000006577e00052af140052af1c007a0ac80a010014003764ec000000000000000020000000006288500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000645760007a0ae0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000037265c0202b0324000000000376508003764ec00000000fff80000 > (gdb) maint print architecture > gdbarch_dump: GDB_NM_FILE = <not-defined> > gdbarch_dump: bfd_arch_info = powerpc:e500 > gdbarch_dump: byte_order = 0 > gdbarch_dump: byte_order_for_code = 0 > (...) > > This is because "ppc_exc_initialize.o" has a ".PPC.EMB.apuinfo" section > that says it needs the "E500 SPE APU". Here's what is in that section. > > 0 | 00000008 | 8 bytes in "APUinfo\0" > 4 | 00000008 | 8 bytes (2 words) of APU information. > 8 | 00000002 | Section type is rev 2. > 12 | "APUinfo\0" > 16 | 01000001 | APU 0x100 "e500 SPE APU" revision 1 > 20 | 00410001 | APU 0x041 "Motorola Book E Performance Monitor APU" > revision 1. > > The resultant linked output is the superset of all requirements, so the > linked output is also "powerpc:e500". > > This is because "ppc_exc_initialize.c" includes instructions for different > targets that it avoids at run time. > > These code lines cause the ".o" to be "powerpc:e500": > > ppc_mtivor(32, ppc_exc_vector_address(ASM_E500_SPE_UNAVAILABLE_VECTOR, > vector_base)); > ppc_mtivor(33, ppc_exc_vector_address(ASM_E500_EMB_FP_DATA_VECTOR, > vector_base)); > ppc_mtivor(34, ppc_exc_vector_address(ASM_E500_EMB_FP_ROUND_VECTOR, > vector_base)); > > This line causes the ".o" to be "powerpc:titan" (if the above E500 lines > are removed): > > ppc_mtivor(35, ppc_exc_vector_address(ASM_E500_PERFMON_VECTOR, > vector_base)); > > I "#ifdef'd" them out to get it to "work" but unless someone can figure > out how to get rid of that section in the output "ppc_exc_initialize.c" > needs to be changed to be conditionally compiled. > > If no one has any good ideas I'll open a bug with this. > > Peter > ----------------- > Peter Dufault > HD Associates, Inc. Software and System Engineering > > > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel