PowerPC e7400 executable is type powerpc:e500 making debug difficult

Sat Mar 30 18:15:54 UTC 2024

On Sat, Mar 30, 2024, 12:18 PM Peter Dufault <dufault at hda.com> wrote:

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

It also leads to dead/unused code in any deployment whose BSP uses this file

Feel free to submit a patch

>

> > 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
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20240330/16ddf177/attachment-0001.htm>