Re: Using newlib in simulators.

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

"J. Johnston" wrote:
> 
> Recently, I have received two questions regarding newlib and simulators.

Jeff .. this is a nice write up.. is there anywhere in the docs it could
go?
 
> "Karthick.P.T" wrote:
> >
> > Hi all,
> >          I just got to know about newlib.  I went through some little
> > documentations of newlib.  Now, I want to use newlib in my simulator,  so
> > please could I  get the answers for the following :-
> >
> > 1)  Should I write my own system call implementation to use newlib, so that
> > I can run the application correctly?
> >
> > 2)  If I have to write my implementation for sys calls,  is it just enough
> > to write into 17 stubs in newlib?  Or should I do something more to use
> > newlib in simulator?
> >
> > 3)  Is there any other approach through which I can get library support in
> > the simulator?
> >
> 
> "Shrikar" wrote
> 
> > Hi,
> > I am New to this mailing list. I have some basic and small doubts regarding
> > Newlib.
> > I want to know where can I get the information about adding a new target to
> > the newlib ? Also I want know that is it possible to add a "simulated
> > target" to newlib ?.
> > If  'yes' then how really it differes from adding a regular target ?
> 
> I might as well answer both these questions at the same time.
> 
> First of all, newlib sits on a OS syscall layer.  Besides the syscall layer,
> there is no difference when targetting newlib for a simulator vs a real
> target.  This is intentional.  What this means is that you only have to change
> the low layer syscalls and you can run the code on various evaluation boards
> or just the simulator.
> 
> The syscall layer for a new platform belongs in libgloss (sibling to newlib directory).
> There are examples where this is not true, but they are simply historic and you
> should ignore them.
> 
> For a new platform, you want to add a platform directory in newlib/libc/machine.
> In this directory, you want to add your setjmp/longjmp implementation.  See
> newlib/libc/machine/fr30 for example.  You need to alter newlib/libc/include/machine/setjmp.h
> to add your jmp_buf structure.  Typically, a compiler for your platform will define
> a special flag to indicate that platform (e.g. __PLATFORM_X__).  You will see that
> platforms key off of such special flags so they may define their version of jmp_buf.
> 
> In addition to your machine directory, you want to specify various things like
> data endianness, IEEE endianness, and in some cases, special items such as
> "doubles are 32-bits".  If you look at newlib/libc/include/sys/config.h you will
> see examples of what you need to define.  The IEEE endianness needs to specified
> in newlib/libc/include/machine/ieeefp.h.  As before, you can use your __PLATFORM_X__
> flag.
> 
> Now, you have to add your platform to the configuration.  This is easy to do in
> newlib/configure.host.  In there, you will specify your machine directory created
> earlier.  Note that are tabs required in some places and you should be careful
> to ensure they are used when needed.  See what similar entries use or copy sections
> within the file to make sure you get it right.
> 
> Regarding the syscall layer, you have some choices.  Read newlib/libc/include/reent.h
> for details.  The choices involve the external names and whether reentrancy is supported.
> Look at the mn10300 if you want a standard example.
> 
> Now, there is the question about what to put in libgloss for the simulator.  The key
> to note is that they are syscalls so the most work you have to do is to figure
> out how to code a syscall for the simulator.  If you are the writer of the simulator,
> you have complete flexibility.  The only requirement is that the simulator recognizes the
> syscall and knows how to extract parameters.  If there isn't a syscall insn in the
> insn set, you might try to use a designated trap or interrupt number.  Failing that, you
> can steal an unused opcode or even set it up as a write to a special memory location.
> It doesn't matter.  The layer is just for the simulator so it can be anything as long
> as you adhere to whatever the simulator expects.  You obviously don't want to choose
> something likely to be generated by the C compiler or else you will be seeing extraneous
> syscalls out of nowhere.  If you are not the writer of the simulator, you will have
> to find out what it expects.
> 
> Typically, once the simulator recognizes a syscall, it uses a similar call on the
> native platform that the simulator is running on.  This may require endianness
> reversal, fetching of arguments into temporaries, whatever, depending on the platform
> and the host.  For example, a open syscall may just translate to be an open of the
> file locally.
> 
> Take a look at some of the libgloss libraries in place (e.g. mn10300, m32r).  Note how
> they set up a trap or interrupt routine which actually makes a generic syscall.  The open,
> close, read, etc.. routines are quite trivial once this is set up and you can copy
> them.  In some cases, platforms define special linker scripts (.ld files).  These are
> used when the default linker doesn't output what is needed to run programs on the
> simulator (e.g. you need a bigger stack than the default given by the linker).
> You should try without one first and then see if it is needed.
> 
> -- Jeff J.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985