From: "Udo A. Steinberg" <us15@os.inf.tu-dresden.de>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Cc: John Reiser <jreiser@BitWagon.com>
Subject: Re: Linux 2.2. ELF loader mystery
Date: Sat, 10 Jan 2004 16:19:36 +0100 [thread overview]
Message-ID: <20040110161936.57954de8@argon.inf.tu-dresden.de> (raw)
In-Reply-To: <4000135C.4060008@BitWagon.com>
[-- 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 --]
next prev parent reply other threads:[~2004-01-10 15:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-10 13:53 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 [this message]
2004-01-10 16:24 ` John Reiser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040110161936.57954de8@argon.inf.tu-dresden.de \
--to=us15@os.inf.tu-dresden.de \
--cc=jreiser@BitWagon.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®