linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Linux 2.2. ELF loader mystery
@ 2004-01-10 13:53 Udo A. Steinberg
  2004-01-10 14:13 ` Udo A. Steinberg
  2004-01-10 14:59 ` John Reiser
  0 siblings, 2 replies; 5+ messages in thread
From: Udo A. Steinberg @ 2004-01-10 13:53 UTC (permalink / raw)
  To: Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 3724 bytes --]


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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Linux 2.2. ELF loader mystery
  2004-01-10 13:53 Linux 2.2. ELF loader mystery Udo A. Steinberg
@ 2004-01-10 14:13 ` Udo A. Steinberg
  2004-01-10 14:59 ` John Reiser
  1 sibling, 0 replies; 5+ messages in thread
From: Udo A. Steinberg @ 2004-01-10 14:13 UTC (permalink / raw)
  To: Linux Kernel Mailing List

[-- Attachment #1: Type: text/plain, Size: 749 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Linux 2.2. ELF loader mystery
  2004-01-10 13:53 Linux 2.2. ELF loader mystery Udo A. Steinberg
  2004-01-10 14:13 ` Udo A. Steinberg
@ 2004-01-10 14:59 ` John Reiser
  2004-01-10 15:19   ` Udo A. Steinberg
  1 sibling, 1 reply; 5+ messages in thread
From: John Reiser @ 2004-01-10 14:59 UTC (permalink / raw)
  To: Linux Kernel Mailing List

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, jreiser@BitWagon.com


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Linux 2.2. ELF loader mystery
  2004-01-10 14:59 ` John Reiser
@ 2004-01-10 15:19   ` Udo A. Steinberg
  2004-01-10 16:24     ` John Reiser
  0 siblings, 1 reply; 5+ messages in thread
From: Udo A. Steinberg @ 2004-01-10 15:19 UTC (permalink / raw)
  To: Linux Kernel Mailing List; +Cc: John Reiser

[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Linux 2.2. ELF loader mystery
  2004-01-10 15:19   ` Udo A. Steinberg
@ 2004-01-10 16:24     ` John Reiser
  0 siblings, 0 replies; 5+ messages in thread
From: John Reiser @ 2004-01-10 16:24 UTC (permalink / raw)
  To: Udo A. Steinberg; +Cc: Linux Kernel Mailing List

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.

-- 


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2004-01-10 16:25 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-01-10 13:53 Linux 2.2. ELF loader mystery Udo A. Steinberg
2004-01-10 14:13 ` Udo A. Steinberg
2004-01-10 14:59 ` John Reiser
2004-01-10 15:19   ` Udo A. Steinberg
2004-01-10 16:24     ` John Reiser

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).