2

running the code below generates a file with Welcome to jj Shashwat as content. what i didn't get is why does it writes Shashwat at the end of the file, Shashwat is in a totally different variable. Any idea why does this happen?

section .text
   global _start         ;must be declared for using gcc

_start:  

   ;create the file
   mov  eax, 8
   mov  ebx, file_name
   mov  ecx, 0777        ;read, write and execute by all
   int  0x80             ;call kernel

   mov [fd_out], eax

   ; close the file
   mov eax, 6
   mov ebx, [fd_out]

   ;open the file for reading
   mov eax, 5
   mov ebx, file_name
   mov ecx, 2             ;for read/write access
   mov edx, 0777          ;read, write and execute by all
   int  0x80

   mov  [fd_out], eax

   ; write into the file
   mov  edx,len          ;number of bytes
   mov  ecx, msg         ;message to write
   mov  ebx, [fd_out]    ;file descriptor 
   mov  eax,4            ;system call number (sys_write)
   int  0x80             ;call kernel

   ; close the file
   mov eax, 6
   mov ebx, [fd_out]

   mov  eax,1             ;system call number (sys_exit)
   int  0x80              ;call kernel

section .data
        file_name db 'myfile.txt', 0
        msg db 'Welcome to jj', 0
        mgafter db ' Shashwat', 0
        lntwo equ $-mgafter
        len equ  $-msg

section .bss
        fd_out resb 1
        fd_in  resb 1
        info resb  26
Shashwat shagun
  • 121
  • 1
  • 6
  • 2
    Not sure why this surprises you. You asked it to write `len` bytes of data to the file, and you have defined `len` to be all of the bytes between your definition of `msg` and the end of your definition of `msgafter`. So both are being written. – lurker Feb 27 '18 at 11:57
  • 1
    Upvoted because this contains all bits and pieces a good question should contain (source code, observed behaviour, expected behaviour, explanation of why the behaviour is unexpected) and the code is well commented. If more questions would be written that well, answering questions would be a much more pleasurable experience. – fuz Feb 27 '18 at 11:58
  • 2
    There are no variables in assembly, just bytes... and when you write 24 bytes instead of 14 bytes, then you have in file 24 bytes. Also you probably don't want to store the zero bytes into the text file? That's very rare, I would rather add newline character, i.e. I would change the source data definition to: `...to jj', 10` to have newline in the final text file. (BTW there's some reasonably good duplicate about what `$` does in those `equ`, so in case the fuz answer is not completely clear, search for some questions about nasm, equ and $. (although I think that answer is pretty clear :) )) – Ped7g Feb 27 '18 at 12:04
  • @fuz: there was already an exact duplicate of this. But yes, well-written questions are nice, and make it easy to see what the problem is. @ Shashwat: Closing as a duplicate doesn't mean it's a bad question; if you don't know why the problem's happening you can't search on the right terms to find the duplicate. – Peter Cordes Feb 27 '18 at 18:25
  • `fd_out: resb 1` is a problem. You're loading/storing *4* bytes, but you only reserved 1. `mov [fd_out], eax` overwrites the `resb` after `fd_in`, and the first 2 bytes of the `resb` after `info` as well. (As Ped7g said, assembly doesn't have variables: labels are simply markers that let you refer to places, it's up to you to make the data layout + your load/store instructions make sense.) – Peter Cordes Feb 27 '18 at 18:28

1 Answers1

4

That's because you said len equ $-msg after defining both msg and msgafter, so len is set to the length of both msg and msgafter, making your write call write both strings. This is because len equ $-msg means “set len to be the difference between the current location ($) and the location of msg.”

To fix this, move the len equ $-msg line right after the definition of msg.

fuz
  • 88,405
  • 25
  • 200
  • 352