Why is data stored in memory reversed?

Question

This is the source code I have:

section .data           
msg:    db "pppaaa"     
len:    equ $
section .text           
    global  main    
main:                    
    mov     edx,len 
    mov     ecx,msg 
    mov     ebx,1   
    mov     eax,4   
    int     0x80

And when I debug this code I will see:

(gdb) info register ecx
ecx            0x804a010        134520848
(gdb) x 0x804a010
0x804a010 <msg>:        0x61707070
(gdb) x 0x804a014
0x804a014:      0x00006161

"70" here represents the character 'p' and "61" the character 'a' obviously.

What I am confused about is, why is the data in location 0x804a010 is 0x61707070 (appp) and moving 4 bytes forward at 0x804a014 the data is --aa ?

I would expect to see (pppa) for the first location and (aa--) for the second location. Why is this the case?

You're likely working in little-endian environment. Bytes are just stored "the other way". [See here](http://en.wikipedia.org/wiki/Endianness) — lared, Jan 08 '15 at 21:29
@KorayTugay: You don't (most architectures can't, and the ones that can, would cause all your programs to break). What you do is stop looking at byte arrays in a 32-bit view. Use a byte-oriented view, to match your data. You went wrong when you said "the data in location 0x804a010 is 0x61707070" Actually the data in location 0x804a010 is 0x70 — Ben Voigt, Jan 08 '15 at 21:31
You (most likely!) can't. When I said environment I also meant the hardware you're using. Could you please tell me what processor does your computer have? — lared, Jan 08 '15 at 21:31
As I've thought you use x86 compatible processor - Intel has historically been using little endian convention in its processors and it doesn't allow switching it (unlike certain ARM processors). In general your programs should be endianness-independent, but when using x86 assembly you can assume it's little endian. There's really nothing you can do. — lared, Jan 08 '15 at 21:40
@lared Thanks for the information.. However is it possible that Java uses High Endian even in this system? — Koray Tugay, Jan 08 '15 at 21:42
Unfortunately I don't possess necessary knowledge to answer your question. You might want to make a separate question on that to get more experienced developers to answer it. — lared, Jan 08 '15 at 21:51
JVM is big-endian, see e.g. this answer: http://stackoverflow.com/a/981568/477476 — Cactus, Jan 09 '15 at 03:30

score 3 · Accepted Answer · answered Jan 09 '15 at 06:56

3

GDB doesn't know that you have a bunch of chars. You are just asking it to look at a memory location and it is displaying what is there, defaulting to a 4-byte integer. It assumes the integer is stored least significant byte first, because that is how it is done on Intel, so you get your bytes reversed.

To fix this, use a format specifier with your x command, like this:

 x/10c 0x804a010

(will print 10 chars beginning at 0x804a010).

help x in GDB will give more information.

answered Jan 09 '15 at 06:56

Tony

1,645
1
10
13

So can we say that, actually the bytes are not stored in reversed order, but gdb shows me so because it assumes I am looking at an integer? – Koray Tugay Jan 09 '15 at 07:24
@KorayTugay, yes, that is my understanding. – Tony Jan 09 '15 at 07:25
@lared Lared, does this mean bytes are actually not stored "the other way" but it only is a representation by gdb? – Koray Tugay Jan 09 '15 at 07:42
2

@KorayTugay They are stored the other way in the registers. Endianness only affects blocks of more than 1 bytes interpreted as distinct variables (or elements of array). What Tony said is true, each char is 1 byte long so endianness doesn't come into play. However if you interpret them as ints, they are interpreted as if they had been flipped when written into the memory which means that they're automatically flipped when read. In memory they're not flipped, but in the processor's registry - yes. – lared Jan 09 '15 at 14:08

Why is data stored in memory reversed?

1 Answers1

Linked