calling 32-bit printf from 64-bit binary?

I have this simple C code -

Code:

---

#include <stdio.h>

int main() {
        printf("asdf");
}

---

And decided to look at the assembly output by gcc and found something strange.

The relevant section -

Code:

---

main:
        pushq        %rbp
        movq        %rsp, %rbp
        movl        $.LC0, %edi
        movl        $0, %eax
        call        printf
        leave
        ret

---

The thing is, this is on 64-bit Linux, and this is apparently a 64-bit binary (since it's using all those r registers), but the call to printf is 32-bit (address of the format string via edi, and "number of SSE registers used" via eax, both 32-bit registers).

Quote:

---

cyberfish@cyberfish-desktop:/tmp$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)

---

Any clue what is going on?

Many thanks

I haven't worked with much 64-bit assembler outside of ALPHA but I don't believe I am seeing a problem here. Less I be reading your code incorrectly.

I just find it strange that it is not calling the 64-bit version of printf. Also, if the address of the format string is 64-bit, like I thought it should be on a 64-bit system, how can it be passed via edi, a 32-bit register?

Again, I am not 100% sure since I am not the foremost expert on 64-bit assembler, but is that not more a matter of calling convention than anything else?

The question is not about calling conventions. It's using the correct calling convention for 32-bit. My question is why is it using the 32-bit version instead of 64-bit.

Well, even if I can't explain why it uses EDI and EAX instead of RDI and RAX, I would say it's calling "64-bit" code since the convention of passing the first argument in RDI and the number of SSE registers used in RAX is a x86-64 calling convention (namely AMD64 ABI). It it was calling "32-bit" code, I guess it would use something like cdecl, no ?

I have just started learning assembly, so I have no idea what cdecl is... :). it makes sense that it should use rdi to pass the first argument, but it's using edi. If printf is 64-bit and reads rdi, it will only get half of the address? (the least significant dword would be garbage). Same goes for eax/rax. If printf reads rax, it will get a garbage value in the least significant dword?

Correct me if I am wrong (this is addressed more to matsp than anyone else). But is it not inferred by the C standard that the above would be the only valid way to even call a standard library function? For example, if you look at some of the libraries that are packed with your assembler you will see the way it documents how to use them by expressing which registers it alters and which it does not. In C the same holds true, but in a more uniform way.

Quote:

---

But is it not inferred by the C standard that the above would be the only valid way to even call a standard library function

---

How so?

You mean the C stdlib only exist in 32-bit? How can the standard say that? What about pure 8, 16, and 64 bit architectures? I don't see how the C standard can specify what registers to use to pass arguments to stdlib functions. The calling convention should be implementation-defined, no?

Quote:

---

if you look at some of the libraries that are packed with your assembler you will see the way it documents how to use them by expressing which registers it alters and which it does not

---

Sure, but what does that have to do with the C standard?

[edit]
The calling convention on x86 (64) is to use 6 registers (rdi, rsi, rdx, rcx, r8, r9) to pass the first 6 arguments. The assembly gcc spits out apparently defies that rule, by using edi. I would expect an implementation on 64-bit to follow 64-bit conventions?
[/edit]

Quote:

---

Originally Posted by cyberfish

I have just started learning assembly, so I have no idea what cdecl is... :). it makes sense that it should use rdi to pass the first argument, but it's using edi. If printf is 64-bit and reads rdi, it will only get half of the address? (the least significant dword would be garbage). Same goes for eax/rax. If printf reads rax, it will get a garbage value in the least significant dword?

---

It's the other way around. r** registers are 64-bit, e** are 32-bit.

The way it is done here will fail if the buffer is located at 0x0000000100000000 or higher memory address.

Let's make one thing clear here: The code is not calling the 32-bit version of printf - it can't do that, it wouldn't work.

Quote:

---

Originally Posted by maxorator

It's the other way around. r** registers are 64-bit, e** are 32-bit.

The way it is done here will fail if the buffer is located at 0x0000000100000000 or higher memory address.

---

Actually, it would fail for any address of $.LC0 that is above 0x80000000 (2 ^ 31), since move to %EDI (or any other Eregister) is sign-extended up to the 64-bit size, rather than zero-extended. So if the address of LC0 is outside the first or last 2GB of virtual address, it will fail. However, the linker will tell you if that is the case when it resolves the relocation of the address - and it is very unlikely that your static data will actually reach 2GB - the compiler assumes that this never happens.

EAX is the 32-bit version of RAX, and since the number of SSE registers that may hold data is always less then 16, it will nicely fit in the lower 32 bits with 28 bits to spare - so there is no need to use the 64-bit version of the register. We do however need to set the entire 32-bit value, so a mov to AL or some such would involve some other instruction to extend the operation, which would add extra instructions and not really help.

--
Mats

On the other hand, by not moving to the r** registers, but using the e** registers instead, the compiler saves a byte for the "large operand" instruction prefix that is required for many 64-bit opcodes.

Quote:

---

Originally Posted by CornedBee

On the other hand, by not moving to the r** registers, but using the e** registers instead, the compiler saves a byte for the "large operand" instruction prefix that is required for many 64-bit opcodes.

---

Not to mention the four bytes saved by not using a 64-bit operand on the %RDI load constant that would be all zero anyways.

--
Mats

Try compiling with -mcmodel=medium. This forces GCC not to assume that symbols are in the lower 2 GB. You should find that it then moves the string pointer to the full rdi.
It will still move the 0 constant to eax, of course.

the problem is more likely with your disassembler, since the binary for 32 bit instructions and 64 bit instructions are (mostly) identical. It just depends on what mode the processor is in when whether it executes a 32 bit or 64 bit version of the opcode.

Quote:

---

Originally Posted by abachler

the problem is more likely with your disassembler, since the binary for 32 bit instructions and 64 bit instructions are (mostly) identical. It just depends on what mode the processor is in when whether it executes a 32 bit or 64 bit version of the opcode.

---

No, the assembler output by the compiler is as above, and it is correct.

--
Mats

Thanks for the explanations. I think I get it now, with just one more question -

Since x86 is little-endian, doesn't edi represent the most significant dword of rdi? How does it work, then? I can understand if edi represent the least significant bits... Does printf do the shifting?

EDI represents the lower half of the 64-bit RDI register - the order those bytes are stored in memory is not important for the purpose of this discussion. When EDI is loaded with 32-bit value and the processor is in 64-bit mode [and that applies even when the current process is a 32-bit process in compatibility mode], the upper half of these registers are filled with bit 31 of the 32-bit value, so loading 0x00001234 into EDI will actually result in RDI containing 0000000000001234. Loading 0x80001234 will result in 0xFFFFFFFF80001234 - note that the behaviour of the upper bits in pure 32-bit mode is undefined, so when going to 64-bit mode, all registers need to be re-loaded to ensure that the upper 32 bits are set - this is usually not a problem tho', as most systems never switch back to 32-bit mode once 64-bit mode has been entered [because there are lots of other things that ALSO need to be changed when switching from one to the other mode].

It is a common misconception that registers somehow have an "endian" behaviour. The only time that "endian" is involved is when data is accessed as bytes in memory - once it is in a register, the bits go from right to left in the same order as you would do on paper [1].

[1] Of course, this is a logical left to right - there's nothing saying that the chip-layout people won't stack the bits in two rows, one with bits 0..15 going from left to right, the other with bits 31..16 from right to left - but that's not really what we care about - logically, the bits are number 0 at the rightmost and 31 or 63 at the left of the set.

--
Mats

Oh. I see what you mean now. I was under the misconception that registers have endian-ness, too (bytes in a register). Thanks for clearing it up.

And sorry for the late reply, for some reason the email notification thing, which I have been relying on, didn't work for this thread.