> On Mar 30, 2024, at 2:15 PM, Joel Sherrill wrote:
>
> It also leads to dead/unused code in any deployment whose BSP uses this file
>
I don't know the full definition of code coverage. I suppose code that can
never be exercised on a given platform is "dead code"? Even if the code as a
On Sat, Mar 30, 2024, 12:18 PM Peter Dufault 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
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
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
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
