RTEMS 4.7.99.2 Available -- PowerPC/virtex feedback

[gregory.menke at gsfc.nasa.gov]

I don't have any machines up with the RTEMS ppc build, so I am going
from memory.  I looked at the printf suite since that stuff comes with
newlib and is independent of whatever flags RTEMS and user software are
compiled with and issues due to newlib will arise no matter what you do
with your makefiles.

I use "powerpc-rtems-objdump -dst xxxxx > tmpfile" (where xxxx is the
rtems library that contains the newlib stuff) then search tempfile for
the printf library code & examine it.  The problem is not necessarily
floating point opcodes but the use of floating point registers (FPR0 and
similar) in any of the general cpu instructions.

OTOH your toolchain results suggest it is likely not a fpu related
problem; newlib comes from the gcc build, not RTEMS so this could be a
bsp related issue.  When we were running into startup problems because
of the use of FPU registers, we couldn't even finish the executive
startup before being caught in an infinite exception loop.

Regards,

Greg




Robert S. Grimes writes:
 > Chris and Greg, you seem to be right - see below.
 > gregory.menke at gsfc.nasa.gov wrote:
 > > I ended up using the newlib printf suite as the test- if fp registers
 > > are shown in the instructions, then it meant I had a build problem w/
 > > newlib.  The assembly is dramatically different when the fp registers
 > > are excluded.
 > >   
 > Don't know what you are talking about ("newlib printf suite"), so I
 > checked my own code.
 > > Chris Caudle writes:
 > >  > Doesn't that imply that the tools for PPC405 should already be using soft
 > >  > float?
 > >  > Everyone is scurrying around figuring out how to rebuild tools with soft
 > >  > float, but it looks like that should be the default already, and so far no
 > >  > one has presented any code which confirms that the exception was actually
 > >  > caused by using a floating point register.
 > >  > 
 > >  > Shouldn't looking at the instructions to see if that is a feasible
 > >  > explanation be the first step?
 > >
 > >   
 > I did this instruction:
 > 
 >     $ powerpc-rtems-objdump -d --architecture=powerpc:403 myprog.exe >
 > myprog.exe.disasm.txt
 > 
 > and examined the results.  Now, I'm not 100% sure what I'm looking for,
 > but I figured the floating point store instructions (e.g.stfd, stfx,
 > etc.) were good candidates.  In fact, searching for "stf" turned up
 > nothing.  I also couldn't find any floating point load, nor any of the
 > operations that I looked for.  So I think, Chris, your comment from your
 > first email on this is likely closer to the truth:
 > 
 >     "More accurately it is "program exception," which is also triggered
 > by illegal opcode."
 > 
 > You had followed this up by asking if the tool chain had changed between
 > head from a month ago and 4.7.99.2, and the answer is: No.
 > 
 > So I'm a bit stumped right now.  On the one hand I have an application
 > that works with the older RTEMs, but fails on startup with 4.7.99.2 -
 > sounds bad for 4.7.99.2!  On the other hand, its failure sounds a bit
 > like that of my earlier post regarding "isync, exceptions, et. al" from
 > last Thursday - similar, but worse.
 > 
 > Any ideas?
 > 
 > Does it seem correct to rule out (at least temporarily) the tool chain
 > as the culprit?
 > 
 > Thanks!
 > -Bob
 >