<div dir="ltr">Hi<div><br></div><div>Chris and I discussed this for a few minutes last night and wondered if </div><div>code like this which includes arbitrary CPU model specific code could</div><div>be the culprit? <br><br><a href="https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c#n65">https://git.rtems.org/rtems/tree/bsps/powerpc/shared/exceptions/ppc_exc_initialize.c#n65</a><br><br>There may be other sections that do this.<br><br>If this were wrapped in a conditional for the proper CPU core variants, it</div><div>might resolve the issue. One would hope that if there were no e500 code,</div><div>binutils and gdb wouldn't get confused.</div><div><br></div><div>--joel</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 27, 2024 at 12:19 PM Peter Dufault <<a href="mailto:dufault@hda.com">dufault@hda.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
(gdb) set powerpc vector-abi altivec<br>
(gdb) set arch powerpc:7400<br>
The target architecture is set to "powerpc:7400".<br>
(gdb) set gnutarget powerpc:7400<br>
(gdb) target remote <a href="http://192.168.240.3:2159" rel="noreferrer" target="_blank">192.168.240.3:2159</a><br>
Remote debugging using <a href="http://192.168.240.3:2159" rel="noreferrer" target="_blank">192.168.240.3:2159</a><br>
Remote 'g' packet reply is too long (expected 292 bytes, got 412 bytes): 003a5914007a0ae0007a7b6000000000006577e00052af140052af1c007a0ac80a010014003764ec000000000000000020000000006288500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000645760007a0ae0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000037265c0202b0324000000000376508003764ec00000000fff80000<br>
(gdb) maint print architecture<br>
gdbarch_dump: GDB_NM_FILE = <not-defined><br>
gdbarch_dump: bfd_arch_info = powerpc:e500<br>
gdbarch_dump: byte_order = 0<br>
gdbarch_dump: byte_order_for_code = 0<br>
(...)<br>
<br>
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.<br>
<br>
0 | 00000008 | 8 bytes in "APUinfo\0"<br>
4 | 00000008 | 8 bytes (2 words) of APU information.<br>
8 | 00000002 | Section type is rev 2.<br>
12 | "APUinfo\0"<br>
16 | 01000001 | APU 0x100 "e500 SPE APU" revision 1<br>
20 | 00410001 | APU 0x041 "Motorola Book E Performance Monitor APU" revision 1.<br>
<br>
The resultant linked output is the superset of all requirements, so the linked output is also "powerpc:e500".<br>
<br>
This is because "ppc_exc_initialize.c" includes instructions for different targets that it avoids at run time.<br>
<br>
These code lines cause the ".o" to be "powerpc:e500":<br>
<br>
ppc_mtivor(32, ppc_exc_vector_address(ASM_E500_SPE_UNAVAILABLE_VECTOR, vector_base));<br>
ppc_mtivor(33, ppc_exc_vector_address(ASM_E500_EMB_FP_DATA_VECTOR, vector_base));<br>
ppc_mtivor(34, ppc_exc_vector_address(ASM_E500_EMB_FP_ROUND_VECTOR, vector_base));<br>
<br>
This line causes the ".o" to be "powerpc:titan" (if the above E500 lines are removed):<br>
<br>
ppc_mtivor(35, ppc_exc_vector_address(ASM_E500_PERFMON_VECTOR, vector_base));<br>
<br>
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.<br>
<br>
If no one has any good ideas I'll open a bug with this.<br>
<br>
Peter<br>
-----------------<br>
Peter Dufault<br>
HD Associates, Inc. Software and System Engineering<br>
<br>
<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div>