Hi,
Linux 2.2 refuses to allocate certain .bss ELF sections in memory if there
are PT_LOAD sections following them. Is there any convention saying that
.bss must always be the last section and must not be followed by PT_LOAD
sections? OTOH both Linux 2.4 and 2.6 have no trouble getting this right
and load the binary just fine.
Here is an example. There is an .initcall section following .bss and
.bss (sections 13 and 14) are not being allocated with zero-pages on startup.
Program thus crashes with SIGSEGV.
Any hints welcome.
-Udo.
prog: file format elf32-i386
Program Header:
LOAD off 0x00000000 vaddr 0x00001000 paddr 0x00001000 align 2**12
filesz 0x000a6468 memsz 0x000b8818 flags rwx
LOAD off 0x000a7000 vaddr 0x000ba000 paddr 0x000ba000 align 2**12
filesz 0x00005000 memsz 0x00005000 flags rwx
Sections:
Idx Name Size VMA LMA File off Algn
0 .init 00000017 00001200 00001200 00000200 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text 0007d640 00001220 00001220 00000220 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
2 .fini 0000001b 0007e860 0007e860 0007d860 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
3 .rodata 00027228 0007e880 0007e880 0007d880 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .eh_frame 00000000 000a5aa8 000a5aa8 000a4aa8 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
5 .preinit_array 00000000 000a5aa8 000a5aa8 000ac000 2**0
CONTENTS
6 .init_array 00000000 000a5aa8 000a5aa8 000ac000 2**0
CONTENTS
7 .fini_array 00000000 000a5aa8 000a5aa8 000ac000 2**0
CONTENTS
8 .data 000018f0 000a5ac0 000a5ac0 000a4ac0 2**5
CONTENTS, ALLOC, LOAD, DATA
9 .jcr 00000000 000a73b0 000a73b0 000a63b0 2**2
CONTENTS, ALLOC, LOAD, DATA
10 .ctors 000000a0 000a73b0 000a73b0 000a63b0 2**2
CONTENTS, ALLOC, LOAD, DATA
11 .dtors 00000008 000a7450 000a7450 000a6450 2**2
CONTENTS, ALLOC, LOAD, DATA
12 .got 00000010 000a7458 000a7458 000a6458 2**2
CONTENTS, ALLOC, LOAD, DATA
13 .bss 00011800 000a8000 000a8000 000a7000 2**5
ALLOC
14 __libc_freeres_ptrs 00000018 000b9800 000b9800 000a7000 2**2
ALLOC
15 .initcall 00005000 000ba000 000ba000 000a7000 2**5
CONTENTS, ALLOC, LOAD, CODE
16 .debug_pubnames 00000025 00000000 00000000 000ac000 2**0
CONTENTS, READONLY, DEBUGGING
17 .debug_info 0000096c 00000000 00000000 000ac025 2**0
CONTENTS, READONLY, DEBUGGING
18 .debug_abbrev 00000124 00000000 00000000 000ac991 2**0
CONTENTS, READONLY, DEBUGGING
19 .debug_line 000001c8 00000000 00000000 000acab5 2**0
CONTENTS, READONLY, DEBUGGING
20 .debug_str 00000674 00000000 00000000 000acc7d 2**0
CONTENTS, READONLY, DEBUGGING
21 .debug_aranges 00000058 00000000 00000000 000ad2f8 2**3
CONTENTS, READONLY, DEBUGGING
22 .stab 000dba14 00000000 00000000 000ad350 2**2
CONTENTS, READONLY, DEBUGGING
23 .stabstr 002ddbd6 00000000 00000000 00188d64 2**0
CONTENTS, READONLY, DEBUGGING
results in the following memory map after startup:
00001000-000a8000 rwxp 00000000 03:07 62988 /tmp/prog
000ba000-000bf000 rwxp 000a7000 03:07 62988 /tmp/prog
bffff000-c0000000 rwxp 00000000 00:00 0
On Sat, 10 Jan 2004 14:53:29 +0100 Udo A. Steinberg (UAS) wrote:
UAS> results in the following memory map after startup:
UAS>
UAS> 00001000-000a8000 rwxp 00000000 03:07 62988 /tmp/prog
UAS> 000ba000-000bf000 rwxp 000a7000 03:07 62988 /tmp/prog
UAS> bffff000-c0000000 rwxp 00000000 00:00 0
To illustrate my point, below is what the memory map for the exact same
binary looks like on 2.6. The VMA in question is the one between
0xa8000 and 0xba000, which 2.2. kernels don't zero-allocate.
00001000-000a8000 rwxp 00000000 03:07 62988 /tmp/prog
000a8000-000ba000 rwxp 00000000 00:00 0
000ba000-000bf000 rwxp 000a7000 03:07 62988 /tmp/prog
bffff000-c0000000 rwxp 00000000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
-Udo.
Udo A. Steinberg wrote:
> Linux 2.2 refuses to allocate certain .bss ELF sections in memory if there
> are PT_LOAD sections following them. Is there any convention saying that
> .bss must always be the last section and must not be followed by PT_LOAD
> sections? OTOH both Linux 2.4 and 2.6 have no trouble getting this right
> and load the binary just fine.
Please give the complete kernel version number: 2.2.19, 2.4.23, 2.6.0, etc.
binfmt_elf has had bugs that were introduced/fixed/re-introduced/re-fixed
within the 2.4 series, for example.
Yes, there was an interpretation of ELF that p_filesz < p_memsz implied .bss
only for the last PT_LOAD in the array of Elf32_Phdr. Later this was changed
so that .bss applied only on the PT_LOAD with the highest p_vaddr, regardless
of position in Elf32_Phdr. [In your example this accounts for the missing
.bss from 0x000a6468 to 0x000b8818, because the p_paddr is 0x00001000 but
the other p_vaddr is 0x000ba000 which is greater.] The best interpretation
is that p_filesz < p_memsz implies ".bss" [kernel-supplied, zeroed bytes
and/or pages] separately for _each_ PT_LOAD.
[Note that binfmt_elf ignores Sections. binfmt_elf pays attention only to
PT_LOAD. Aggregating from Elf32_Shdr into ELf32_Phdr is the job of /bin/ld.]
--
John Reiser, [email protected]
On Sat, 10 Jan 2004 06:59:40 -0800 John Reiser (JR) wrote:
JR> Please give the complete kernel version number: 2.2.19, 2.4.23, 2.6.0, etc.
JR> binfmt_elf has had bugs that were introduced/fixed/re-introduced/re-fixed
JR> within the 2.4 series, for example.
I've seen this effect on 2.2. kernels from 2.2.20 to 2.2.25 (not tested
earlier 2.2 kernels). Things work fine on all recent 2.4 and 2.6 kernels
including 2.4.24 and 2.6.1.
JR> Yes, there was an interpretation of ELF that p_filesz < p_memsz implied .bss
JR> only for the last PT_LOAD in the array of Elf32_Phdr. Later this was changed
JR> so that .bss applied only on the PT_LOAD with the highest p_vaddr, regardless
JR> of position in Elf32_Phdr. [In your example this accounts for the missing
JR> .bss from 0x000a6468 to 0x000b8818, because the p_paddr is 0x00001000 but
JR> the other p_vaddr is 0x000ba000 which is greater.]
Where did this interpretation come from? The ELF standard (1.2) I'm looking at
from: http://x86.ddj.com/ftp/manuals/tools/elf.pdf says for PT_LOAD sections
(page 41 of that document).
PT_LOAD
The array element specifies a loadable segment, described by p_filesz
and p_memsz. The bytes from the file are mapped to the beginning of the memory
segment. If the segment's memory size (p_memsz) is larger than the file size
(p_filesz), the "extra'' bytes are defined to hold the value 0 and to follow the
segment's initialized area. The file size may not be larger than the memory
size. Loadable segment entries in the program header table appear in ascending
order, sorted on the p_vaddr member.
JR> The best interpretation
JR> is that p_filesz < p_memsz implies ".bss" [kernel-supplied, zeroed bytes
JR> and/or pages] separately for _each_ PT_LOAD.
Yes, that is how I read the standard, too - and how 2.4 and 2.6 do it.
JR> [Note that binfmt_elf ignores Sections. binfmt_elf pays attention only to
JR> PT_LOAD. Aggregating from Elf32_Shdr into ELf32_Phdr is the job of /bin/ld.]
Of course. I only posted the section headers in case the program headers
didn't give enough information to some people.
-Udo.
JR> Yes, there was an interpretation of ELF that p_filesz < p_memsz implied .bss
JR> only for the last PT_LOAD in the array of Elf32_Phdr. Later this was changed
JR> so that .bss applied only on the PT_LOAD with the highest p_vaddr, regardless
JR> of position in Elf32_Phdr. ...
Udo> Where did this interpretation come from? The ELF standard (1.2) I'm looking at
Udo> from: http://x86.ddj.com/ftp/manuals/tools/elf.pdf says ...
Diffusion can be a slow and erratic process, resulting in "bugs." "The ELF
standard" (there have been different versions) was not widely available,
and/or not widely consulted, for some parts of its lifetime.
Also, the standard contains some generalizations that were not common usage;
common usage was [is] .text < .data < .bss, with single pieces of each.
--