1

I have started developing a small 16-bit OS under GCC/G++. I am using a GCC cross-compiler, which I compiled under Cygwin, I am putting asm(".code16gcc\n") as the first line of each .CPP file, using Intel ASM syntax and the command lines for compiling and linking a .CPP file look like this:

G++: i586-elf-g++ -c $(CPP_FILE) -o $(OBJECT_OUTPUT) -nostdinc -ffreestanding -nostdlib -fno-builtin -fno-rtti -fno-exceptions -fpermissive -masm=intel

LD: i586-elf-ld -T $(LD_SCRIPT) $(OBJECT_OUTPUT) -o $(BINARY_OUTPUT)

The problem I am currently facing is the way GCC translates function-calling code into assembly.

To be more specific, instead of using the PUSH instruction to pass the arguments, GCC "calculates" the offsets relative to ESP the arguments should be located at, and then uses the MOV instruction to write the stack manually.

This is not beneficial for me, since I rely on the PUSH instruction in my assembly code. To illustrate my problem clearer, take these 2 functions:

void f2(int x);

void f1(){
    int arg = 8;
    asm("mov eax, 5");  // note: super hacky unsafe use of GNU C inline asm
    asm("push eax");    // Writing registers without declaring a clobber is UB
    f2(arg);
    asm("pop eax");
}
void f2(int x){
}

In function f1, I am saving EAX using the PUSH instruction, and I would expect to have it restored to 5 after calling f2 and executing the "POP EAX" instruction. It turns out however that EAX becomes 8, not 5. That's because the ASSEMBLY CODE GCC generates looks like this (I've included the source as well for clarity):

void f1()
C++: {
    push ebp
    mov ebp,esp
    sub esp,byte +0x14

    C++: int arg = 8;
        mov dword [ebp-0x4],0x8
    
    C++: asm("mov eax, 5");
        mov eax,0x5
    
    C++: asm("push eax");
        push eax
    
    C++: f2(arg);
        mov eax,[ebp-0x4]
        mov [dword esp],eax =======>>>>>> HERE'S THE PROBLEM, WHY NOT 'PUSH EAX' ?!!
        call f2
        
    C++: asm("pop eax");
        pop eax
    
C++: }
    o32 leave
    o32 ret
    
void f2(int x)
C++: {
    push ebp
    mov ebp,esp
C++: }
    pop ebp
    o32 ret

I have tried using some G++ compilation flags like -mpush-args or -mno-push-args and another one which I can't remember and GCC still doesn't want to use PUSH. The version I'm using is i586-elf-g++ (GCC) 4.7.2 (Cross-Compiler recompiled in Cygwin).

Thank you in advance!

UPDATE: Here's a webpage I've found: http://fixunix.com/linux/6799-gcc-function-call-pass-arguments-via-push.html

That just seems really stupid for GCC to do, considering that it limits the usability of inline assembly for complex stuff. :( Please leave an answer if you have a suggestion.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
Zuzu Corneliu
  • 1,594
  • 2
  • 15
  • 27
  • So don't do that with inline asm. I don't see how that's possibly useful, compared to just telling gcc what arg you want it to pass. I mean `f2(5)` would compile to less code. Even `asm("push 5")` would be shorter, but can't possibly be safe because gcc might want to reference a local relative to `esp` (which you've modified without telling the compiler). – Peter Cordes Aug 30 '16 at 23:08
  • I can't remember exactly why I needed this, I posted this some time ago when I was just beginning to experiment with low-level programming. But I think the purpose was not to pass 5 as f2's argument but rather to save and restore some registers across function calls - in this case EAX across the function call f2(arg). – Zuzu Corneliu Aug 31 '16 at 05:14
  • That makes very little sense. If the compiler wanted the value in eax saved/restored, it would do that itself. You're not even telling the compiler about what you're doing to registers, so it's more likely you're just going to step on its toes. It doesn't know that `eax` is restored; it's assuming that it holds the function's return value (or is trashed, for void functions). I assume you know better now, but I can't imagine any case where this could do anything more than work by luck. `int foo asm("eax");` might be useful: https://gcc.gnu.org/onlinedocs/gcc/Local-Register-Variables.html – Peter Cordes Aug 31 '16 at 05:21
  • It's not the _compiler_ that wants the value in eax saved and restored, it's _me_, probably because of some logic in f1 before and after the push-f2-pop part. To achieve it, I figured I'd save the register on the stack and pop it after returning from f2. But for that we need to know that during the call to f2 the stack is accessed in a safe way that wouldn't alter the saved eax - e.g. push/pop. There probably is some better way to achieve this, but as I said, this is 4 years old now, if you feel like posting an answer do it and maybe others in need will find it useful. – Zuzu Corneliu Aug 31 '16 at 05:38
  • If you care about `eax` specifically and the compiler doesn't know about it, then you're using inline-asm incorrectly in the rest of `f1`. Use input/output operands to your other asm statements so the compiler knows what's going on, and can pick whatever registers lead to good register allocation for the whole function. See [my collection of inline-asm links](http://stackoverflow.com/questions/34520013/using-base-pointer-register-in-c-inline-asm/34522750#34522750) to guides and some of my other answers, explaining how to use it to make good code. – Peter Cordes Aug 31 '16 at 05:48
  • This kind of idea can't work in x86-64 code anyway, because you can't `push` from inline asm: it clobbers the red zone, which is what that linked question is about. Besides all that, `-fomit-frame-pointer` is the default in modern gcc, even for 32-bit, so if you leave `%esp` pointing in the wrong place, you'll break gcc's code which accesses `arg` on the stack. The only answer for this question is "don't do anything like this". – Peter Cordes Aug 31 '16 at 05:50
  • Sure, there are other reasons for wanting the compiler to emit push instead of mov, e.g. making it easier to read the asm while debugging. I meant to say that your original reason for wanting this doesn't make any sense (at least in my opinion), not that there weren't any good reasons for wanting it. – Peter Cordes Aug 31 '16 at 06:05

2 Answers2

5

I've been very lucky finding a solution to this problem, but it finally does what I want it to do. Here's what the GCC manual for version 4.7.2 state:

-mpush-args
-mno-push-args
Use PUSH operations to store outgoing parameters. This method is shorter
and usually equally fast as method using SUB/MOV operations and is enabled
by default. In some cases disabling it may improve performance because of
improved scheduling and reduced dependencies.

-maccumulate-outgoing-args
If enabled, the maximum amount of space required for outgoing arguments will
be computed in the function prologue. This is faster on most modern CPUs
because of reduced dependencies, improved scheduling and reduced stack usage
when preferred stack boundary is not equal to 2. The drawback is a notable
increase in code size. This switch implies ‘-mno-push-args’.

I'm saying I am lucky because -mpush-args does not work, what works is instead "-mno-accumulate-outgoing-args", which is not even documented!

Zuzu Corneliu
  • 1,594
  • 2
  • 15
  • 27
  • The canonical Q&A about this seems to be http://stackoverflow.com/questions/4534791/why-does-it-use-the-movl-instead-of-push. Note that `-mno-accumulate-outgoing-args` is the default now. Also note that only the non-default form of most options is documented separately, instead of always the `no-` form and the plain form. This fact *is* documented. – Peter Cordes Aug 31 '16 at 05:53
3

I had similar question lately and people didn't find it important I guess, I found out undocumented option at least for GCC 4.8.1, don't know about latest 4.9 version.

Someone said he gets the "warning: stack probing requires -maccumulate-outgoing-args for correctness [enabled by default]" error message.

To disable stack probing, use -mno-stack-arg-probe, so pass these options I guess to ensure:

-mpush-args -mno-accumulate-outgoing-args -mno-stack-arg-probe

For me this works now, it uses PUSH, much smaller and better code, and much easier to debug with OllyDbg.

kktsuri
  • 333
  • 2
  • 11