Re: Microblaze libgloss and gdb simulator
Michael Eager <[email protected]>
| Newsgroups | gmane.comp.lib.newlib,gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On 4/25/21 4:34 PM, Mike Frysinger wrote: >> If you are simulating a program which uses libgloss and you expect the >> behavior of brki to be a syscall, then this is a very reasonable way >> to implement system calls. Instead of taking the branch to the handler, >> the simulator does whatever host system call it is supposed to do, then >> returns, just as if there was an OS handling the system call. (This is >> what QEMU calls "semihosting".) > > yes, this is exactly what we were thinking. i wasn't aware of the QEMU > terminology, thanks. in the GNU sim, we call them "environments". the > default is the virtual environment which behaves this way: there is only > one privilege level, and any exception processing is handled entirely in > the sim itself. The "semihosting" terminology may be an ARM-ism, rather than a QEMU-ism, although that's where I saw it first mentioned. https://www.keil.com/support/man/docs/armcc/armcc_pge1358787046598.htm https://community.nxp.com/t5/LPCXpresso-IDE-FAQs/What-are-none-nohost-and-semihost-libraries/m-p/475327 The debugger (or debugger agent on the target) uses a side channel to perform I/O on the host. I wasn't aware of sim environments. I haven't looked at gdb/sim in a long time. :-) >> I was thinking about the more general case, where you might be >> simulating an image which includes an exception handler. In this >> case, the behavior you want is to take the exception and jump to the >> excption handler address, instead of the simlator interpreting the >> brki as a syscall. > > absolutely this makes sense. this would be the "operating" environment > where the sim wouldn't hijack anything, and it would be responsible for > emulating the various privilege levels such as setting mode bits and > transferring control to any registered exception handlers. this would > be useful for e.g. fully simulating the Linux kernel & userland. > > it sounds like we're in agreement. if there's anyone you think we could > or should consult before moving forward, please loop them in. Go for it! -- Michael Eager