On Tue, Apr 17, 2012 at 10:27:12AM +0100, Julius Baxter wrote: > On Mon, Apr 16, 2012 at 12:46 PM, Stefan Kristiansson > <[email protected]> wrote: > > On Mon, Apr 16, 2012 at 01:58:01PM +0300, Stefan Kristiansson wrote: > >> On Sun, Apr 08, 2012 at 06:33:53AM +0100, Julius Baxter wrote: > >> > diff --git a/arch/openrisc/cpu/cpu.c b/arch/openrisc/cpu/cpu.c > >> > index 25cd624..fa43bf5 100644 > >> > --- a/arch/openrisc/cpu/cpu.c > >> > +++ b/arch/openrisc/cpu/cpu.c > >> > @@ -151,7 +151,9 @@ extern void __reset(void); > >> > int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) > >> > { > >> > disable_interrupts(); > >> > - __reset(); > >> > + __asm__("l.movhi r1,hi(__reset); \ > >> > + l.ori r1,r1,lo(__reset); \ > >> > + l.jr r1"); > >> > >> Isn't this jump generated by the compiler? > >> I assume we can count on that doing the right thing? > >> > > > > To clarify, the compiler can of course not know where __reset is, > > but I would have for some reason expected it to emmit a l.jr sequence... > > Checking is knowing, it does not. > > I guess the real issue here is that the current toolchain doesn't complain > > about it. > > > > But I still would like to get that __asm__ statement hidden away somewhere, > > perhaps in a openrisc_jr inline function? > > And/or a comment above it why we are doing it. > > I'm still a bit confused why we got this (a link-time failure due to > the C-compiler emitting a "l.j __reset") and the only way I could fix > it was by putting in an absolute jump. Maybe some C attribute or > something could force the jump to be absolute (put in a register and > then use l.jr) >
Googling a bit I find the -mlong-calls/mmno-long-calls option (which can be turned on and off with #pragma long_calls and #pragma long_calls_off) I don't know if our gcc port supports them. I presume compiling with -mlong-calls will turn all out of file-scope calls into loadreg->l.jr calls, which perhaps is a bit overboard. The pragmas are even more undesired, so I'm more and more inclined to go with what you suggested in the patch. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
