From: Alan Modra <amodra@gmail.com>
To: emacs-devel@gnu.org
Subject: [PATCH 0/8] ELF unexec (bug#20614)
Date: Mon, 2 Nov 2015 12:23:34 +1030 [thread overview]
Message-ID: <20151102015334.GO13961@bubble.grove.modra.org> (raw)
This series of patches addresses bug #20614 by rewriting the bss
handling code rather than adding yet more hacks. Finding bss sections
by name as we do currently results in complicated code that
- does not account for all names of possible bss sections,
- assumes specific ordering of bss sections,
- can wrongly choose a SHT_NOBITS section not in the bss segment,
- incorrectly calculates bss size (no accounting for alignment gaps),
- assumes .data and .bss are in the same segment.
All of these problems and more are solved by finding the bss segment
in PT_LOAD headers, ie. the address range included in p_memsz but not
p_filesz of the last PT_LOAD header, then matching SHT_NOBITS sections
in that address range.
I've split the patch into a series as there are multiple problems of
varying severity in this code, and it might be a little easier to
review this way. The series was tested indiviually on x86_64-linux
and on powerpc64-linux and powerpc64le-linux after fixing bug #20614
with patch 7/8.
Patch 8/8 goes further and removes the added .data2 section. I don't
see any need for a new SHT_PROGBITS section to cover the old bss
section(s) plus dumped data. Not adding a section means there is no
need to patch symbol st_shndx or section sh_info and sh_link fields,
which is fragile code. At least, sh_info shouldn't really be patched
unless SHF_INFO_LINK is set in sh_flags, but not all linkers set the
flag properly.
Alan Modra (8):
ELF unexec: Correct section header index
ELF unexec: Tidy code
ELF unexec: Merge Alpha and MIPS COFF debug handling
ELF unexec: Symbol table patching
ELF unexec: _OBJC_ symbols in bss sections
ELF unexec: R_*_NONE relocs
ELF unexec: Drive from PT_LOAD header rather than sections
ELF unexec: Don't insert a new section
src/unexelf.c | 1022 ++++++++++++---------------------------------------------
1 file changed, 206 insertions(+), 816 deletions(-)
--
Alan Modra
Australia Development Lab, IBM
next reply other threads:[~2015-11-02 1:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-02 1:53 Alan Modra [this message]
2015-11-02 3:40 ` [PATCH 0/8] ELF unexec (bug#20614) Eli Zaretskii
2015-11-02 4:00 ` bug#20614: " Paul Eggert
2015-11-02 4:07 ` Paul Eggert
2015-11-04 22:35 ` Alan Modra
2015-11-05 0:31 ` John Wiegley
2015-11-05 22:44 ` Richard Stallman
2015-11-08 18:07 ` bug#20614: " Paul Eggert
2016-02-23 10:33 ` Lars Ingebrigtsen
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=20151102015334.GO13961@bubble.grove.modra.org \
--to=amodra@gmail.com \
--cc=emacs-devel@gnu.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.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.