0

My objective is to initialize a buffer in assembly. I use NASM on a 64bit-linux and gdb for debugging. The relevant assembler is the following (I copy-pasted from gdb's TUI mode, so you can see the line numbers):

│   4           section .data 
│   5            
│   6           length dd 4096       
│   7           format db "%20ld",10,0         
│   8         
│   9           section .bss 
│   10
│   11          buffer resd 4096

│   83          init_buffer: 
│   84            ;we will use r8 for our counter 
│   85            ;and r9 for the buffer base address 
│   86            xor r8,r8
│   87            lea r9, [buffer]
│   88            mov r10d, DWORD 0xDADADA; not 0 to make debugging easier
│   89            mov eax, [length]   
│   90            movsxd rax, eax
│   91          .init_buffer_loop:
│   92            mov [r9 + r8*4], r10d
│   93            inc r8 
│   94            cmp r8, rax 
│   95            jb .init_buffer_loop
│   96            ret

I use the following command to build the program (I use printf at another moment):

nasm -F dwarf -f elf64 myProgram.asm && gcc -g myProgram.o

While debugging another problem (I use gdb -tui a.out), I realised that the value in r9 and the address of buffer are different:

(gdb) b    87
Breakpoint 1 at 0x4011a8: file myProgram.asm, line 87.
(gdb) r
Starting program: /path/to/my/program

Breakpoint 1, init_buffer () at myProgram.asm:87
(gdb) p    &buffer
$1 = (char **) 0x7ffff7fa0250 <buffer>
(gdb) n
(gdb) i    r r9
r9             0x405034            4214836
(gdb) n
init_buffer.init_buffer_loop () at myProgram.asm:92
;//some next instructions are missing here, we are at line 94 now:
(gdb) x    /1xd 4214836
0x405034 <buffer>:    14342874
(gdb) x    /4x 4214836
0x405034 <buffer>:    0x00dadada    0x00000000    0x00000000    0x00000000
(gdb) p    (int[4])buffer
$3 = {0, 0, 0, 0}

Is there a mistake in the assembly code? Or am I debugging it wrong? I asked some programmers, who could not explain it to me, but they hadn't much experience with gdb-ing assembly...

ixolius
  • 202
  • 1
  • 11
  • 1
    You likely have multiple symbols named `buffer`. – Jester Feb 07 '20 at 16:47
  • `cat myProgram.asm | grep ^\s+buffer` gives only one result – ixolius Feb 07 '20 at 16:51
  • 1
    @Jester: Or glibc has some internal `static int buffer[]` in some source file; generic names like `buf` clashing with glibc debug symbols / global vars is a common problem for questions like this. – Peter Cordes Feb 07 '20 at 16:52
  • 1
    Yes, I meant "you" in the general sense. Of course there can't be multiple symbols with the same name in the same file. – Jester Feb 07 '20 at 16:53
  • Forgot that there was already a Q&A that explained this when I commented earlier, could have saved you the trouble of writing up your own answer. >.< For some reason this is the 2nd or 3rd time this issue has come up in the last week on SO. – Peter Cordes Feb 10 '20 at 09:52
  • Thanks for linking and closing, if you don't know the real reason for this behavior, it is hard to search for this problem. I spend some time to find a Q&A here before asking... – ixolius Feb 10 '20 at 10:29

1 Answers1

1

As the comments indicated, there is another variable called buffer in another source file of glibc. Changing the variable name to puffer gives the expected results. Furthermore, the following line should have made me skeptical:

$1 = (char **) 0x7ffff7fa0250 <buffer>

gdb did not interfered types in my assembler code, but it knew that I put char **s in my buffer.

ixolius
  • 202
  • 1
  • 11