Microblaze libgloss and gdb simulator
Michael Eager
eager@eagercon.com
Mon Apr 26 00:44:28 GMT 2021
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
More information about the Gdb
mailing list