From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13063 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Segmentation fault in static binaries built with recent binutils Date: Wed, 18 Jul 2018 16:50:57 -0400 Message-ID: <20180718205057.GQ1392@brightrain.aerifal.cx> References: <20180718163940.gnx6jkia4i5qdjua@reiner-h.de> <20180718181438.nl4e333zkzw36rzl@reiner-h.de> <20180718190024.GL4418@port70.net> <20180718193833.GM4418@port70.net> <20180718201928.GN4418@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1531946946 25011 195.159.176.226 (18 Jul 2018 20:49:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 18 Jul 2018 20:49:06 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13079-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 18 22:49:02 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fftNe-0006Qo-8e for gllmg-musl@m.gmane.org; Wed, 18 Jul 2018 22:49:02 +0200 Original-Received: (qmail 5870 invoked by uid 550); 18 Jul 2018 20:51:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 5849 invoked from network); 18 Jul 2018 20:51:10 -0000 Content-Disposition: inline In-Reply-To: <20180718201928.GN4418@port70.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13063 Archived-At: On Wed, Jul 18, 2018 at 10:19:28PM +0200, Szabolcs Nagy wrote: > * Szabolcs Nagy [2018-07-18 21:38:34 +0200]: > > seems like another musl-gcc wrapper issue, if i do the linking > > manually then i get a working binary, havent yet figured out why > > > > manual linking: > > > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x0001ec 0x0001ec R 0x1000 > > LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0005a4 0x0005a4 R E 0x1000 > > LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00004c 0x00004c R 0x1000 > > LOAD 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000018 0x0002a8 RW 0x1000 > > NOTE 0x0001c8 0x00000000004001c8 0x00000000004001c8 0x000024 0x000024 R 0x4 > > GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10 > > GNU_RELRO 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000010 0x000010 R 0x1 > > > > musl-gcc linking: > > > > Program Headers: > > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > > LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0005a4 0x0005a4 R E 0x1000 > > LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x00004c 0x00004c R 0x1000 > > LOAD 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000018 0x0002a8 RW 0x1000 > > GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10 > > GNU_RELRO 0x002ff0 0x0000000000403ff0 0x0000000000403ff0 0x000010 0x000010 R 0x1 > > the difference between the two cases was --build-id > > --build-id=sha1 works, --build-id=none segfaults > > i assume the note section with the build id happens > to force ld to keep the initial load segment, but > that should be there without any note section, so > it's likely a binutils bug (i see it on 2.30 and > master branch too) So am I understanding correctly that binutils ld is considering the program headers section not to be something that has to live in loaded memory? And it's putting a whole 4k of padding below the first load segment? These both seem to be significant bugs. Rich