So I've run into a couple conflicts while merging this, I'm working on fixing them now.
One of them involves 2 of my patches, one in which I cleared LDFLAGS in testsuite/test-code-or1k/configure.ac, and another where I clear CCASFLAGS (also in that file). Jeremy, you asked in another message why I cleared these flags. My reasoning is this: First, we're already clearing CFLAGS in that file. Second, there can actually be problems if LDFLAGS *aren't* cleared, because the LDFLAGS get carried down from the top-level configure. *Those* LDFLAGS are likely intended to be used *only* when compiling the simulator, and not when cross-compiling the testsuite code. One potential problem is the inclusion of -L flags while compiling the testsuite, which may end up causing the linker to attempt to link against a library native to the host, which causes the compile to fail. The reason I cleared CCASFLAGS was because (up until recently) I compiled or1ksim with -m32 in my CFLAGS. Since CCASFLAGS is initialized from CFLAGS, this caused -m32 to be passed to cross-compile commands, when it shouldn't be. In summary, the problem at the moment is there's no way to specify which CFLAGS/LDFLAGS/CCASFLAGS are to be used when compiling the simulator, and which are to be used when compiling the testsuite. Some values for these flags can break the compile. I thought it was best to force some safe and consistent flags when compiling the testsuite. Incidentally, I fixed the bug that was leading me to add -m32 to my compiles (the "<invalid>" printout for some instructions when tracing). I tracked that down to the insn_extract function, which sometimes will sign-extend an intermediate value when it shouldn't be. That fix is in another patch in my repo on the or1k-master branch. -Pete On Fri, Apr 5, 2013 at 1:27 PM, Jeremy Bennett <[email protected]>wrote: > Hi Peter, > > Thanks for all this. This looks good. Please commit them upstream (or > send me a pull request). > > The other thing I would ask is if you can merge them into the OR32 > branch. I know it's not sexy, but most ordinary users are still using > the or32 version, and divergence will just store up nightmares for the > future. I think these commits are all clear of the or32/or1k divide, so > should just apply cleanly. > > Many thanks, > > > Jeremy > > On Thu, 2013-04-04 at 15:34 -0400, Peter Gavin wrote: > > Hi guys, > > > > > > I just pushed some patches to my repo that implement the AECR/AESR > > bits from the new architecture manual for the arithmetic instructions, > > as well as a few other small things. I updated the testsuite to > > match, everything seems to be working correctly. > > > > > > Please review :) > > > > > > https://github.com/pgavin/or1ksim/commits/or1k-master > > > > > > > > -Pete > > _______________________________________________ > > Openrisc mailing list > > [email protected] > > http://lists.opencores.org/listinfo/openrisc > > -- > Tel: +44 (1590) 610184 > Cell: +44 (7970) 676050 > SkypeID: jeremybennett > Email: [email protected] > Web: www.embecosm.com > > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc >
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
