CODEWITHSUNDEEP
gccassemblystackosdev
chpatrick
chpatrick

Reputation: 481

Mysterious stack issue with GCC 4.6.2

I'm working on the Pintos toy operating system at university, but there's a strange bug when using GCC 4.6.2. When I push my system call arguments (just 3 pushl-s in inline assembly), some mysterious data also appears on the stack, and the arguments are in the wrong order. Setting -fno-omit-frame-pointer gets rid of the strange data, but the arguments are still in the wrong order. GCC 4.5 works fine. Any idea what specific option could fix this?

NOTE: the problem still occurs with -O0.

Upvotes: 0

Views: 378

Answers (3)

Non-maskable Interrupt
Non-maskable Interrupt

Reputation: 3911

Did you clean the parameters on stack after the syscall? gcc may not be aware that you touch the stack and generate code depends on the stack pointer it expected. -fno-omit-frame-pointer force gcc to use e/rbp for accessing locate data but it just hide the actual problem.

Upvotes: 0

chpatrick
chpatrick

Reputation: 481

The culprit was -fomit-frame-pointer, which has been enabled by default since 4.6.2. -fno-omit-frame-pointer fixed the issue.

Upvotes: 0

Anders Sjöqvist
Anders Sjöqvist

Reputation: 3482

Without a code example and a listing of the result from your different compilations, it's difficult to help you. But here are three possible causes for your problems:

  1. Make sure you understand how arguments are pushed to the stack. Arguments are pushed from the back. This makes it possible for printf(char *, ...) to examine the first item to find out how many more there are. If you want to call the function int foo(int a, int b, int c), you'll need to push c, then b and finally a.
  2. Could the strange data on the stack be a return address or EFLAGS? I don't know Pintos and how system calls are made, but make sure that you understand the difference between CALL/RET and INT/IRET. INT pushes the flags onto the stack.
  3. If your inline assembly has side effects, you might want to write volatile/__volatile__ in front of it. Otherwise GCC is allowed to move it when optimizing.

I need to see your code to better understand what's going on.

Upvotes: 1

Related Questions