On Fri, May 11, 2012 at 12:57 PM, Julius Baxter <[email protected]> wrote: > On Fri, May 11, 2012 at 12:50 PM, Peter Gavin <[email protected]> wrote: >> On Fri, May 11, 2012 at 1:45 PM, Julius Baxter <[email protected]> >> wrote: >>> I'm not sure if I drew your attention to it a while back but I got gdb >>> sim to about the same stage (could run helloworld.) >>> >>> https://github.com/juliusbaxter/binutils-or1k/tree/gdb-sim-addon/sim >>> >>> (it was on a different branch.) >>> >>> I never got useful tracing out of it, though. I just got the result, >>> essentially. >> >> Oh, I didn't realize you had done that. Does it print using a >> syscall, or with the nop hack? > > l.nop hack, but it performs system calls and traps OK. > >> >>> I'm not sure we need one to help verify the newlib-based toolc hain. >> >> Yeah, I don't think so either. But it would be really nice to be able >> to debug a simulated linux kernel using it :) > > I wouldn't try with this sim. I would stick with or1ksim. It's going > to be more work than it's worth to get gdbsim going properly, and it's > not really needed. We need this gdbsim so tool chain regressions can > be run the usual way (via the or1k-elf-run executable gdb builds) and > thus removing the requirement that or1ksim is built before the tool > chain (or gdb, at least.) It would be nice to load up gdb and run > bare-metal apps (although, without peripherals.... which will be > another problem running Linux in it - you'll have practically no > peripherals, and what will do you - reimplement them all? It'd be less > work to port QMEU to OR1K.)
Sorry by "getting gdbsim going properly" I meant going properly running Linux, not bare metal which is the very worthwhile goal. I just got stuck trying to get a full trace out of it so it was rather difficult to debug. Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
