Question

If I understand corretly, by creating a section of .bss type (as below code example) the write/read area of the .bss section is from section's offset in the file to N and in this case phdr.p_memsz gets incremented by N bytes and it's up to operating system/kernel zero this memory area. Is my intepretation right?

    Elf32_Phdr phdr;
    // ...
    phdr.p_memsiz = somevalue;
    Elf32_Shdr sec;
    // ...
    sec.sh_name   = bss_name;
    sec.sh_type   = SHT_nobits;
    sec.sh_flags  = SHF_alloc + SHF_write;
    sec.sh_size = N;
    phdr.p_memsiz += N;
Was it helpful?

Solution

Yes, the OS will fill the .bss section with zeros.

In general, the Linux (and other versions of Unix) will zero all "new" pages in a process anyway, to avoid leaking content from the "previous owner" (think of it like shredding your recycling).

Edit:

Ulitimately, the linker and loader are responsible for the actual location of the .bss section. Typically, it is at the end of the data section, as described in the ELF specification 1.2, Figure 2.5.

As "Sections" describes, the .bss section has the type SHT_NOBITS. Although it occupies no space in the file, it contributes to the segment's memory image. Normally, these uninitialized data reside at the end of the segment, thereby making p_memsz larger than p_filesz.

(Elsewhere it explains that the content is guaranteed to be zero)

You can find the specification here (and many other places, but this site also has some of the useful extension documents, etc) http://refspecs.linuxbase.org/

The LLVM source code and related docs are also fairly readable (IMO): http://llvm.org/docs/doxygen/html/Support_2ELF_8h_source.html

Information on how to specify linking and order, location of sections: http://www.math.utah.edu/docs/info/ld_3.html

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top