Why does an 8 byte array (C) in 64 bit Ubuntu take 16 bytes?
I recently was (retraining) low-level CS stuff and I was looking into buffer overflow. I have created a basic C program that has an 8 byte array char buffer[8];
. Then I used GDB to learn and demonstrate the program and make it run. I am on a 64 bit version of Ubuntu and I noticed that my 8 byte char array is actually represented in 16 bytes in memory - the top order bits are just 0.
eg. Instead 0xDEADBEEF 0x12345678
, as I might expect, to represent an 8 byte array, it is actually something like 0x00000000 0xDEADBEEF 0x00000000 0x12345678
.
I did some googling and was able to get GCC to compile my program as a 32 bit program (using the -m32 flag) which resulted in the expected 8 bytes as usual.
I'm just looking for an unambiguous explanation as to why an 8 byte character array is represented in 16 bytes on a 64 bit system. Is this because the minimum size / address block is 16 bits (64 bits), and GDB is just printing based on the size of 8 bytes?
Hope this is clear, but let me know if clarification is needed.
source to share
64-bit systems are designed to align all memory to 16 byte boundaries (16 byte alignment is part of the System-V ABI), there are two parts to stack allocation: first, the stack itself must be aligned, and second, any allocations then trying to keep that alignment.
This explains the first part of why an 8 byte array becomes 16 bytes on the stack, and why it is split into two 8 byte qwords, it is a little harder to say since you have not provided any code (assembly or C) regarding the use of this buffer. And trying to replicate this with mingw64 achieves 16 byte alignment, but not the funny layout you see.
Of course, another possibility related to the lack of ASM is that GDB displays 2xQWORD, when in fact it is 2xDWORD (in other words, try using p/x (char[8])
to dump the contents ...).
source to share