1

I have been learning how to program x86 assembly on windows. I am using NASM to assemble, and MinGW GCC to link the program with glibc so that I can have access to a basic print function. Here is my code:

    global  _main
    extern  _printf

section .text

_copystring:
    ; ebx : our string
    ; ecx : our buffer
    
    call _copyloop
    
    ret

_copyloop:
    cmp byte[ebx], 0
    je _copyret
    mov ah, byte[ebx]
    mov byte[ecx], ah
    add ebx, 1
    add ecx, 1
    jmp _copyloop
    
_copyret:
    ret

_main:
    push message
    call _printf
    add esp, 4
    
    mov ebx, gb_msg
    mov ecx, buffer
    call _copystring
    
    push buffer
    call _printf
    add esp, 4
    
    ret

section .data
    message db 'Hello, World', 10, 13, 0
    gb_msg db 'goodbye!', 10, 13, 0
    
section .bss
    buffer: resb 128

This is what I use for compiling:

nasm -fwin32 -o test.obj test.asm
gcc -o test test.obj -m32

What it does is print a message to the screen. Then it copies another string into a buffer (which is declared in .bss). The weird part is that when I opened the .exe executable in 7-zip (an archiving program) and viewed the .bss section in notepad, I expected that there should be 128 bytes hard coded in. To my amazement, there are none... In fact, there is no data in the .bss section. The program works perfectly fine, and I am not really concerned at the moment about my assembly skills so far, but I am mainly wondering why there is no data in the .bss section of the program. Any ideas?

TheDude04
  • 107
  • 9
  • 5
    What you observe is basically the entire point of the `.bss`. Since it defines a region of memory that will be filled with zeros, there is no point wasting disk space with a huge block of zeros in the executable. The OS will instead zero out that region of memory when the program is initially loaded. If it weren't for this optimization, you might as well just put your `buffer` in `.data` instead, as there's no other difference between them. – Nate Eldredge Jun 13 '21 at 20:13
  • if you use objdump or readelf you should see the .bss and its size, the binary should only need to know, name of segment, label, address(es), size. and one would expect most binary file formats to do that. if you use objcopy -O binary then you might see it depending on the order and contents of the other segments – old_timer Jun 13 '21 at 21:10

0 Answers0