PowerPC e7400 executable is type powerpc:e500 making debug difficult

[Peter Dufault]

It's the source code lines that I quoted that cause the problem.

To avoid getting the object defined as an e500 then that file needs to be conditionally compiled (I think that's the way it is, there should be another way, having a binary that adapts to its target isn't *that* evil.).  Including those e500 instructions "taints" the object.  That's the only object I could find that wasn't e7400.

I guess there is a rule for the ABI to promote objects up to whatever architecture includes all the instructions that are present.  And that survives through the linker stage.  So that particular object file winds up needing the "Signal Processing Extensions", as do any executables that it is linked into.

It makes sense, it also makes sense to have a way to avoid it.

> On Mar 29, 2024, at 2:05 PM, Joel Sherrill <joel at rtems.org> wrote:
> 
> 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 <dufault at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering