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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.