• Uncategorized

About assembly : gdb-behaves-differently-for-symbols-in-the-bss-vs-symbols-in-data

Question Detail

I recently started learning assembly language for the Intel x86-64 architecture using YASM. While solving one of the tasks suggested in a book (by Ray Seyfarth) I came to following problem:

When I place some characters into a buffer in the .bss section, I still see an empty string while debugging it in gdb. Placing characters into a buffer in the .data section shows up as expected in gdb.

segment .bss
result  resb    75
buf resw    100
usage   resq    1

    segment .data
str_test    db 0, 0, 0, 0

    segment .text
    global main
    mov rbx, 'A'
    mov [str_test], rbx     ; LINE - 2 PLACES CHARACTER NICELY. 

In gdb I get:

  • after LINE 1: x/s &buf, result – 0x7ffff7dd2740 <buf>: ""

  • after LINE 2: x/s &str_test, result – 0x601030: "A"

It looks like &buf isn’t evaluating to the correct address, so it still sees all-zeros. 0x7ffff7dd2740 isn’t in the BSS of the process being debugged, according to its /proc/PID/maps, so that makes no sense. Why does &buf evaluate to the wrong address, but &str_test evaluates to the right address? Neither are “global” symbols, but we did build with debug info.

Tested with GNU gdb (Ubuntu 7.10-1ubuntu2) 7.10 on x86-64 Ubuntu 15.10.

I’m building with

yasm -felf64 -Worphan-labels -gdwarf2 buf-test.asm
gcc -g buf-test.o -o buf-test

nm on the executable shows the correct symbol addresses:

$ nm -n  buf-test     # numeric sort, heavily edited to omit symbols from glibc
0000000000601028 D __data_start
0000000000601038 d str_test
000000000060103c B __bss_start
0000000000601040 b result
000000000060108b b buf
0000000000601153 b usage

(editor’s note: I rewrote a lot of the question because the weirdness is in gdb’s behaviour, not the OP’s asm!).

Question Answer

You may also like...

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.