PowerPC Tutorial

Previous Chapter

Chapter 26: Syscalls

Section 1: Intro

Back in Chapter 17 you have briefly learned about the Syscall Exception. The sc instruction will cause the System Call Exception to occur. Execution of the CPU is routed to 0x000000C00 (or 0xFFF00C00 depending on IP bit of MSR), CPU goes into Real Mode, and will start executing the System Call Handler's present code.

Let's look at a super basic program that prints "Hello via Syscall!"

.section .text
    .global _start

_start:
#Set Args for Write and initiate its Syscall
    li r3, 1
    lis r4, msg@ha
    la r4, msg@l (r4)
    li r5, len
    li r0, 4 #Syscall number for write for PPC
    sc

#syscall for exit
    li r3, 0
    li r0, 1 #Syscall number for exit for PPC
    sc

#Directives
msg:
    .asciz "Hello via Syscall!\n"
    len = . - msg

Save the file as hello_sys.s. Assemble the program. This is a "pure" Assembly Source File. The PowerPC C compiler won't be used. We will directly use the Assembler and then have to use the Linker.

powerpc-linux-gnu-as -mregnames hello_sys.s -o hello_sys.o
powerpc-linux-gnu-ld hello_sys.o -o hello_sys

Before dissecting the program, I want you to run it in GDB. First, launch the Program using QEMU-PPC...

qemu-ppc -g 1234 ./hello_sys

Now bring up GDB in a 2nd terminal...

Once GDB launches, keep issuing a stepi command until you reach the sc instruction. Like below..

Okay now issue 1 more stepi. Let's see what happens...

Huh? Well that ain't right. Why didn't we go the System Call Exception Handler?

Section 2: Explanation of QEMU Exception Emulation

In the Linux OS, regardless of the machine's architecture (PPC, ARM, x86-64, etc), the syscall exception handler of the specific architecture will have code in it that acts as a Function. It takes arguments in the parameter registers like any standard function, but it takes a syscall number in a register as a "special" arg. For Linux OS's that run on PowerPC, this syscall special arg goes in r0. We know that r0 is a not an Argument register under the standard PPC Calling Convention.

QEMU has to emulate these syscall functions, meaning if you write PPC code to lets say execute the Linux's openat function (this is sort of similar to C's fopen), it needs a way to tell the Linux OS to execute it in the OS's actual real machine architecture. For example, let's say your Linux laptop runs on an Intel processor, that means its running on x86-64 Assembly/Architecture. QEMU is emulating PPC since the Program is in PPC. So when your program executes an "sc" instruction, QEMU has to emulate (fake) the syscall. It will take your PPC args and then "convert" them for the x84-64 assembly language, and then perform the actual real Linux OS syscall.

GDB knows this as well, which is why it won't let you stepi thru the sc instruction correctly. This is also true for all other exceptions. Therefore, with GDB, you cannot step/debug thru any PPC exceptions. If you need to for a better understanding of the exception handlers, you will need to install the Dolphin-Emulator, Dolphin-memory-engine, dump a legally purchased Wii Game into an ISO, and step thru some PPC exception code in Dolphin.

Section 3: Linux OS Syscalls

Linux, MAC, and Windows all their own unique syscalls. But the 3 will contain many syscalls that are smiliar/same to each other. To open a file on Linux, you would use the openat syscall. MAC and Windows don't have openat but they do have open with is almost identical in operation. The syscall numbers (the special arg mentioned earlier) may vary per Operatin System. Here is a link to a table of all Syscall numbers for Linux, Mac, Windows for a variety of Architectures - LINK

In our Program from Section 1, you see we use the write syscall to print to the console. The write syscall is used for writing to files, but your console (or output thru the console) is considered a file in Linux. We need to understand the openat syscall before we can explain why write applies to the console output.

Openat has the following args~

• r0 = openat's syscall number
• r3 = directory fd
• r4 = filepath relative to directory that was indicated by fd
• r5 = flags
• r6 = mode

Openat will return a file descriptor which is a bit different than a File Stream Pointer. File descriptor is an integer value, and you would use this integer value for future file-based syscalls (i.e. read, write, close). If openat failed, a negative value is returned.

The output buffer for your console has already been opened by your Linux OS after it has been booted. It always has the fd value of 1. Console input always has the fd value of 0. These fd's have known nicknames..

• stdin = 0 (console input)
• stdout = 1 (console output)
• stderr = 2

Let's go back to a portion of our Program that executes the write syscall

#Set Args for Write and initiate its Syscall
    li r3, 1
    lis r4, msg@ha
    la r4, msg@l (r4)
    li r5, len
    li r0, 4 #Syscall number for write for PPC
    sc

Write has the following args~

• r0 = Write syscall number (which is 4 for Linux PowerPC 32-bit architecture)
• r3 = fd #Notice this is stdout's fd!
• r4 = Pointer to contents that will be written #For console output, this is the pointer to the string
• r5 = Size #For strings, this would be the string length

Write returns the size/length of what was written, which should match the r5 arg. If not, or if a negative value was returned, then write was not successful. Keep in mind that programs that execute write specifically for console output, usually don't check the return value.

stdout, stdin, stderr are to NEVER be closed, hence why the close syscall is absent in our Program.

Alrighty, and that should give you some insight on how Computer OS Syscalls work, and how to use them in your PPC Programs.

Next Chapter

Tutorial Index