CODEWITHSUNDEEP
assemblynasmelfmemory-layout
Harel Rozental
Harel Rozental

Reputation: 191

(N)ASM, ELF64 - .data and .bss order in memory

I have a question regarding .data and .bss sections order in memory, couldn't google it for the life of me.

I'm trying to understand if it is guaranteed that .bss part will always come after the .data part, in terms of memory addresses.

My concrete need is this:

section .data
malloc_pointer:
    dq start_of_my_malloc

start_of_data:
; more stuff...

section .bss
; more stuff
start_of_my_malloc:
    resb 1 << 30 ; pre-allocate 1gig

And I need to sometimes use the offset [malloc_pointer] - start_of_data, so I need it to be positive, hence the question about .bss and .data order.

As a side - it would be nice to know if I can reference the label start_of_data to help me choose a size to reserve in start_of_my_malloc. What I would really like to do is:

start_of_my_malloc:
    resb (1 << 30) - start_of_data ; this won't compile though

Thanks!

Upvotes: 2

Views: 872

Answers (2)

yugr
yugr

Reputation: 21955

Decision about section positioning is done by the linker and can be controlled via linker scripts (default or custom). I'd try to not rely on them because they will make your code less self-contained.

As to your second question - you can assemble file once, extract size of .data from object file and then reassemble it with appropriate -DSTART_OF_DATA=....

Upvotes: 1

fuz
fuz

Reputation: 93082

Traditionally, memory is laid out so text comes first, then data, and finally bss. This design comes out of convenience as you can simply copy the entire binary into memory, zero out a chunk of memory after it and then (optionally) set up memory protection. To extend the bss segment, you can use the brk and sbrk system calls.

Three labels etext, edata, and end are defined by the linker pointing to the end of the text segment, the end of the initialised data and the end of the data segment. No label start exists as the program was traditionally mapped to address 0, eliminating the need for a label.

There is no guarantee that the layout is like this, but as quite a few programs rely on this design, it is unlikely to change in the near future.

If you want to write a memory allocation routine, I recommend you to use the sbrk system call. This eliminates the entire need for assumptions about the layout as sbrk always does the right thing.

Note that sbrk is a bit outdated today, so if you want to use something modern, I recommend you to implement your memory management on top of mmap.

Upvotes: 1

Related Questions