From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Modra Newsgroups: gmane.emacs.devel Subject: [PATCH 0/8] ELF unexec (bug#20614) Date: Mon, 2 Nov 2015 12:23:34 +1030 Message-ID: <20151102015334.GO13961@bubble.grove.modra.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1446434976 12001 80.91.229.3 (2 Nov 2015 03:29:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Nov 2015 03:29:36 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 02 04:29:36 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Zt5oL-0006Qz-0l for ged-emacs-devel@m.gmane.org; Mon, 02 Nov 2015 04:29:33 +0100 Original-Received: from localhost ([::1]:39838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zt5oJ-0001VN-Oi for ged-emacs-devel@m.gmane.org; Sun, 01 Nov 2015 22:29:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37786) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zt4Jc-0001Ji-Bt for emacs-devel@gnu.org; Sun, 01 Nov 2015 20:53:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zt4JZ-0001Es-5i for emacs-devel@gnu.org; Sun, 01 Nov 2015 20:53:44 -0500 Original-Received: from mail-pa0-x234.google.com ([2607:f8b0:400e:c03::234]:35966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zt4JY-0001Eo-Vr for emacs-devel@gnu.org; Sun, 01 Nov 2015 20:53:41 -0500 Original-Received: by pacfv9 with SMTP id fv9so136851896pac.3 for ; Sun, 01 Nov 2015 17:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=/mer1B7TvftGynZzTqDfrRjx6B53tHbZi//T1HDFyjs=; b=Wd/12JfOQi/s4ZGYby3l6fPDc0k6n4L3db/W+l/aN4S/bfY1bn/RATzu2+Si7orkaR 0+PldvUCQTWW62iX0HFvaIPWQ1BlRn5Oc2Lh/vOg6OMEZ2wSOwFjNURWgZh4UT759PCW mVL3jDcYnEF+dd7E2dOABQj7tysZPmV36w2EmaGI+54eZNhVdqTrgBQOv8yIfOPmP2mX bnwzfi/A5Eafe5F40Z1BK6Y/q29NYH7Fqnn9nnBksZ7HKcJqNo67HrgKalyKuEl9Cr4Q JnELyrVGHinwmPRJaY7+Tgf4XhN5YnRvwdUdUjfZ7vuIdyntVgWzjWTV3y4I2ge5JiyN HjNg== X-Received: by 10.66.188.49 with SMTP id fx17mr23912106pac.95.1446429220236; Sun, 01 Nov 2015 17:53:40 -0800 (PST) Original-Received: from bubble.grove.modra.org (CPE-58-160-163-67.gqzg1.fli.bigpond.net.au. [58.160.163.67]) by smtp.gmail.com with ESMTPSA id of1sm20615575pbc.11.2015.11.01.17.53.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Nov 2015 17:53:39 -0800 (PST) Original-Received: by bubble.grove.modra.org (Postfix, from userid 1000) id A92E6EA1537; Mon, 2 Nov 2015 12:23:34 +1030 (ACDT) Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c03::234 X-Mailman-Approved-At: Sun, 01 Nov 2015 22:29:06 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193090 Archived-At: 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