Re: Microblaze libgloss and gdb simulator

[Michael Eager <eager@eagercon.com>]

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