Prasad Venkata Boddupalli bprasad@CS.Arizona.EDU
Fri Jun 1 19:17:00 GMT 2001

Jeff, thanks for the reply. The simplescalar simulator reads the binary
(generated by arm-elf-gcc cross-compiler). If the instruction is a
software interrupt, it invokes the function "sys_syscall", which emulates
the behavior of the OS sys handler. The first statement of that function
       /* Figure out the system call number from the swi instruction
          Last 24 bits gives us this number */

          qword_t syscode = inst & 0x000fffff;

syscode is always 0x23456, no matter what system call I use in my C
program. I see from the arch/arm/kernel/entry-common.S, that the syscall
code is retrieved using the link register. I was confused a bit by this
inconsistency. The above cross-compiler (arm-elf-gcc) uses the newlib.
That made me wonder if glibc and newlib differ in the way they store
the syscall codes and if the numbers used for syscalls differ between
      I would be grateful for any clarification.


On Fri, 1 Jun 2001, J. Johnston wrote:

> Prasad Venkata Boddupalli wrote:
> >
> > Hi,
> >     We are adapting the simplescalar simulator to use the newlib system
> > calls. In the process I had this question.
> >     Instead of encoding differnet syscalls using different numbers in
> > the bits, 0-23, why is it that a single code, 0x123456 used ?
> >
> > thanks,
> > Prasad.
> Prasad,
>   Newlib doesn't dictate how syscalls are encoded in the language.  Usually, a syscall
> implementation is found in libgloss for the simulator as often, platforms do not have specified
> hardware syscalls.  When a simulator libgloss library exists, it simply uses an agreed-upon
> interface for the particular simulator.  This can be an insn opcode not being used, magic memory
> locations, whatever.
> -- Jeff J.

More information about the Newlib mailing list