[Linux-Xtensa] RAM load/store reorder
baruch at tkos.co.il
Wed Nov 27 19:46:50 UTC 2013
On Wed, Nov 27, 2013 at 11:22:08AM -0800, Marc Gauthier wrote:
> Baruch Siach wrote:
> > Thanks for you prompt response.
> > On Wed, Nov 27, 2013 at 08:39:25AM -0800, Marc Gauthier wrote:
> > > Baruch Siach wrote:
> > > > 1. Why is this seemingly NOP store/load pair at 0x5f3d414
> > and 0x5f3d416
> > > > needed at all?
> > >
> > > Looks like you're compiling at -O0. In that case, the compiler
> > > ensures that all variables are in memory at every source line
> > > boundary ie. nothing is cached in registers across such boundaries,
> > > so debuggers can access/modify variables in memory (eg. stack) only,
> > > and the right thing happens.
> > The source file in question builds with -Os. I checked this
> > again by looking
> > at the actual build command line. Also, a3 holds an internal
> > function pointer, not a user set variable.
> Is fdt_next_node() a macro? what does it expand to?
No. fdt_next_node() is a regular function. See its full listing in my first
> Is this GCC or XCC?
It's GCC version 4.7.2.
> > The FPGA runs at 25MHz which I believe is nowhere near the limit of this
> > board. I'll check here how exactly this bitstream was generated.
> Ok. I can't explain the behavior otherwise.
> Can you also try different ML605 board?
It's a KC705. I'm not sure we have another one, but I'll check.
> Am assuming the code works fine when single-stepped, or putting
> breakpoints after each instruction?
Yes. Single stepping through the code makes the problem magically disappear.
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
More information about the linux-xtensa