From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Re: Segmentation fault in static binaries built with recent binutils
Date: Wed, 18 Jul 2018 16:50:57 -0400 [thread overview]
Message-ID: <20180718205057.GQ1392@brightrain.aerifal.cx> (raw)
In-Reply-To: <20180718201928.GN4418@port70.net>
On Wed, Jul 18, 2018 at 10:19:28PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@port70.net> [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
next prev parent reply other threads:[~2018-07-18 20:50 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-18 16:39 Reiner Herrmann
2018-07-18 17:37 ` Rich Felker
2018-07-18 18:14 ` Reiner Herrmann
2018-07-18 19:00 ` Szabolcs Nagy
2018-07-18 19:38 ` Szabolcs Nagy
2018-07-18 20:19 ` Szabolcs Nagy
2018-07-18 20:24 ` Szabolcs Nagy
2018-07-18 20:50 ` Rich Felker [this message]
2018-07-18 20:53 ` Reiner Herrmann
2018-07-18 21:37 ` Szabolcs Nagy
2018-07-18 21:49 ` Reiner Herrmann
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=20180718205057.GQ1392@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/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 public inbox
https://git.vuxu.org/mirror/musl/
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).