Constant (.equ) in asm

Question

Let's say I define a constant such as the following in asm:

.data
SYS_EXIT = 60

.text
.globl _start
_start:
    mov $SYS_EXIT,  %eax
   syscall

Does the assembler literally do the equivalent of a 'find-replace' at run-time to replace the value of SYS_EXIT with 60? In other words, the program becomes the following after substitution?

.text
.globl _start
_start:
    mov $60,  %eax
   syscall

If so, does it make a difference 'where' I define the SYS_EXIT variable? For example, does it need to go in a particular section, and if not, what is the convention of where to put it? For example:

.data
SYS_EXIT = 60

------------------------

.rodata
SYS_EXIT = 60

------------------------

(start of file)
SYS_EXIT = 60

Finally (perhaps a separate question), is there a way to view all constants in gdb? I can view the manually by knowing the label, but not in doing something like info va:

>>> info va
All defined variables: [empty]
>>> p/d &SYS_EXIT
$1 = 60

Answer 1

It's a numeric value substitution, not a text substitution, but basically yes.

re: definition order, see Distinguishing memory from constant in GNU as .intel_syntax - with $SYS_EXIT in AT&T syntax there's no ambiguity even if the constant is defined later. With .intel_syntax it can matter whether a constant is defined before or after an instruction that uses it.

(These are not like C preprocessor macros, they're more like labels; you can reference later definitions from earlier code, like normal for assembler.)

And no, assemble-time constants don't have a section. Switching to a section just to use a foo = number directive is misleading, don't do it.

---

Values defined with = do appear in the symbol table of object files, like other symbols. (That's why you can see it with GDB or nm). If you use .globl they'll be visible for use in other files, like label addresses are.

I'm not sure if that's useful for anything; it's probably best to .include a file of definitions for constants if you want to use them across files, rather than letting the linker fill them in.

I don't know why GDB's va didn't show them; probably because they don't have a .type marking them as variables.