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.) >From what I recall, though, some architectures appeared to have some sort of MMU-like capability. But I really don't think it's worth it. What would be very cool, though, is that QEMU userspace emulator (this would help a lot to check our uClibc-based tool chain, which right now requires a very elaborate set up.) Cheers Julius _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
