1

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;
The Mask
  • 17,007
  • 37
  • 111
  • 185

1 Answers1

4

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

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • I think so, but I'm not entirely sure what you are trying to do - I though you were asking "Is the memory that gets allocated guaranteed to be zero" - I haven't looked that closely at how the regions are generated, but looks reasonable. – Mats Petersson Apr 04 '14 at 20:45
  • I'm just trying to know where start and end the region of a `.bss` section. – The Mask Apr 04 '14 at 23:14
  • Not sure what you mean... Where it gets located is a combination of linker and the loader that loads the file into memory. Your code looks OK for expanding the .bss by N bytes. – Mats Petersson Apr 04 '14 at 23:19
  • Sorry if I wasn't clear enough. Assume it's a static executable and not dynamic. It's has 2 sections also the fixed phdr and ehdr: .text and .bss. so I have a total of 4 sections. .bss is the last in the elf file and has sh_size = sizeof(int) * 2 meaning there's room to two static variables. What I'm looking for understand is where the area of this segment (in this case sizeof(int) * 2) start and end, ie., the memory address and offset it. It's not clear and so I'm assuming it's from end of offset .bss section in the elf file up to size I've specified: sizeof(int) * 2). – The Mask Apr 05 '14 at 00:17
  • 1
    Like I said, it depends on the linker - but typically, it will be immediately after the .data segment (or a preceeding .bss segment, if there is more than one). You can write a linker configuration file that places .bss at an address a long way from .data. It's just typically done that .bss follows immediately after .data. (And all .bss sections are following each other) – Mats Petersson Apr 05 '14 at 00:26
  • Edit your answer with this comment to I accept. Also, do you have any good resource (also ELF specification file) to I understand better these stuff related to ELF? – The Mask Apr 05 '14 at 01:59