-1

I need some help in AT&T assembly. I've load some data into memory like below (hex and dec)

(gdb) x/8xb &buffer_in
0x8049096:  0x03    0x02    0x10    0x27    0xe8    0x03    0x64    0x00


(gdb) x/8db &buffer_in
0x8049096:   3        2      16      39      -24      3      100      0

Lets say that first byte = number count, second = each number length in bytes and then we got (first * second) bytes of numbers. For this example, 3 numbers, 2 bytes each, first number is 16 39 and so one. I have no problems with implementing it, I can grab each byte and add.

The question is, why the hell hex numb 0xE8 = -24 in decimal after just loading data into memory (like below)?? It should be 232 in decimal.

Code for loading data is very simple:

.align 32
SYSEXIT = 1
SYSREAD = 3
SYSWRITE = 4
STDOUT = 1
STDIN = 0

.bss

buffer_in: .space 10000
buffer_in_len = . - buffer_in

.text
.global _start
_start:

    #STDIN READ
movl $SYSREAD, %eax
movl $STDIN, %ebx
movl $buffer_in, %ecx
movl $buffer_in_len, %edx
int $0x80


debug:
movl $0, %edi #do nothing

movl $SYSEXIT, %eax
int $0x80
Jester
  • 56,577
  • 4
  • 81
  • 125
Barcys
  • 1
  • 1
  • 3
  • @edit: I know that -24 is value of signed 0xE8 value to dec, but what can I do to have it unsigned. Moving just that byte to register and adding to current sum of lower bytes of each number doesnt really work, it's adding -24 instead of 232 – Barcys May 23 '17 at 19:35
  • Try printing with `x/8ub`. – fuz May 23 '17 at 19:38
  • Adding BYTE value -24 or 232 is the same thing. If your summing is wrong, then you are probably assuming something incorrect about what does it mean to add byte value. As single byte can contain only 8 bits, for integer values it usually can cover -128..+127 or 0..255 range. If you want larger sum, you need 16 or 32 bit value for the sum, and you should then extend the byte value to the same size. When extending 0xE8 in "zero-extended" fashion to 16b (`movzx` may help, or `and`), it will become 0x00E8 = +232. If you would "sign-extend" it (`movsx, sar, ...`), it would become 0xFFE8 = -24. – Ped7g May 23 '17 at 21:41
  • BTW, `movzx/movsx` is Intel syntax, AT&T is as always more explicit about what is happening, so `movsx` of byte to word is `movsbw`. In many other ways I find AT&T atrocious, but this particular case... has some merit in it. But I still prefer Intel's universal `movsx` and specifying argument size by prefixing arguments with byte/word/dword. – Ped7g May 23 '17 at 21:52

1 Answers1

1

The d format specifier prints its argument as a signed decimal number. To print unsigned decimal number, use u instead. Your command is x/8ub.

fuz
  • 88,405
  • 25
  • 200
  • 352