From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11614 invoked by alias); 2 Oct 2018 14:57:56 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 11514 invoked by uid 89); 2 Oct 2018 14:57:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=U*hjl, 000000 X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ot1-f46.google.com Received: from mail-ot1-f46.google.com (HELO mail-ot1-f46.google.com) (209.85.210.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Oct 2018 14:57:54 +0000 Received: by mail-ot1-f46.google.com with SMTP id e21-v6so2156393otk.10; Tue, 02 Oct 2018 07:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TOZuPj5VXEv+fDqschgGIqMqqm3RFbrWHpthHbwZAww=; b=rOaT5OZPRET25c0LY91N1VZlqM8h7WRfv8xkM6OWS40X4iMiJurS4TdTdbQZJ9bLXm bvdTKX6SHDeZQzj0jyZDFD7E62F1sgo4kvU6HqHBgxhMLOTm3qf3NaOInhxai/N0fQzM 0tA0VtKuO7QJGPJrSrzvono6QqQx3w2uj9H3ojVM5FgS/2sK+8VFwcYjUsJ2iBYF05z0 RoWvk/OHdELqt6vJtm/s8i4ntNOR9eV6R4B+BEuqCdrbxv/R/U/JsTodS2XgNVHnzWSL XdARH1eT67Sc7G155Hp5IZCcrVcULlTmzE87vYkFUKpnWg5ocbNqx7LLEght0Jf/unZP V5JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TOZuPj5VXEv+fDqschgGIqMqqm3RFbrWHpthHbwZAww=; b=uN9QQPZ0YhYcR+Gj5OBvR3gsIKGbwnGAEMvb3oc4WFqD+TqktaPN+U34TWDENMWOYg 8OMrWRnuYJTSCUm9x89lcxjEg3SozczpJcMc1PesE59cdVgDRs5aDDzWltUT6lPle308 fYjoMSoH1wMznD78JGQb/zNGL8jnJ1kylcpwYwmEbh2tc1sxRbqTATOMFTdBg9VsFfRQ lvtGC9Aua1GFSs6Kb+8ejI9AnchbJSG5pHw2x+D6ggLgFRzN0RET9TO3oI6ftnQfT+5Q rknI67GwTX5qNQL1ray8CfQzlPzRcRknmHOi7Wy5pnKajVla0Q2It1u9dHulYXMOWdN/ qttQ== X-Gm-Message-State: ABuFfojcszxdVFKwObIDRns6iQz0dI3mQ3Vkbvw+JuTm/5sn+zgM2863 1zxcqUVsPMViiZxpqZwh9QYroXWJTOnBBrx1Tz8= X-Google-Smtp-Source: ACcGV60rZ887r4Xddlvh+KF12TSHZXS/JvvWDXwnR8bqpvX+J1lvOQQblQD1zesOskUopKrB4Ts3EkexMuPUp6QPN1k= X-Received: by 2002:a9d:3c5a:: with SMTP id j26-v6mr8923970ote.118.1538492272230; Tue, 02 Oct 2018 07:57:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Add GNU_PROPERTY_NEED_PHDRS To: Michael Matz Cc: Rich Felker , Cary Coutant , "Carlos O'Donell" , Florian Weimer , Szabolcs Nagy , Jan Beulich , Binutils , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00001.txt.bz2 On Tue, Oct 2, 2018 at 7:52 AM Michael Matz wrote: > > Hi, > > On Fri, 28 Sep 2018, H.J. Lu wrote: > > > >> AT_PHDR to main, which points to the unmmaped address. We can ask > > >> for kernel change or make kernel happy. > > > > > > Kernel change does not help because nobody is obligated to use a new > > > kernel. Binutils would be producing binaries that don't work on > > > existing kernels (if the note hack were reverted or if similar changes > > > were added to other archs without a note hack; right now of course > > > it's working again). > > > > True. > > > > >> My current .note.gnu.property patch only works for x86. We can add > > >> > > >> #define GNU_PROPERTY_PHDRS 3 > > >> > > >> so that it can be used for all targets. > > > > > > What would this do? > > > > These are what I have in mind. > > I don't see how the patches fix anything, in particular making sure that > the phdrs are always mapped. If your intention is (it would be good if > you can explain it with words) that they only would be made mapped if this > new property is set, then I'd disagree. I think they should always be > made mapped unconditionally. There are two ways for this: (a) add a new > PT_LOAD that covers them, (b) move the phdrs into the ro data segment. I > find all approaches that add properties or new section types or anything > else that needs documentation and definition dubious. > A .note.gnu.property section will lead to a read-only data PT_LOAD segment as the first PT_LOAD segment: [hjl@gnu-17 ld]$ readelf -WlS tmpdir/pr23428 There are 16 section headers, starting at offset 0x2ed0: Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ 0] NULL 0000000000000000 000000 000000 00 0 0 0 [ 1] .note.gnu.property NOTE 0000000000400158 000158 000030 00 A 0 0 8 [ 2] .text PROGBITS 0000000000401000 001000 0000ea 00 AX 0 0 16 [ 3] .rodata PROGBITS 0000000000402000 002000 000006 01 AMS 0 0 1 [ 4] .comment PROGBITS 0000000000000000 002006 00002d 01 MS 0 0 1 [ 5] .debug_aranges PROGBITS 0000000000000000 002040 000060 00 0 0 16 [ 6] .debug_info PROGBITS 0000000000000000 0020a0 0002f7 00 0 0 1 [ 7] .debug_abbrev PROGBITS 0000000000000000 002397 000137 00 0 0 1 [ 8] .debug_line PROGBITS 0000000000000000 0024ce 0001a7 00 0 0 1 [ 9] .debug_frame PROGBITS 0000000000000000 002678 000040 00 0 0 8 [10] .debug_str PROGBITS 0000000000000000 0026b8 0002a1 01 MS 0 0 1 [11] .debug_loc PROGBITS 0000000000000000 002959 000295 00 0 0 1 [12] .debug_ranges PROGBITS 0000000000000000 002bee 000020 00 0 0 1 [13] .symtab SYMTAB 0000000000000000 002c10 0001e0 18 14 14 8 [14] .strtab STRTAB 0000000000000000 002df0 000030 00 0 0 1 [15] .shstrtab STRTAB 0000000000000000 002e20 0000ab 00 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), I (info), L (link order), O (extra OS processing required), G (group), T (TLS), C (compressed), x (unknown), o (OS specific), E (exclude), l (large), p (processor specific) Elf file type is EXEC (Executable file) Entry point 0x4010c0 There are 5 program headers, starting at offset 64 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x000000 0x0000000000400000 0x0000000000400000 0x000188 0x000188 R 0x1000 LOAD 0x001000 0x0000000000401000 0x0000000000401000 0x0000ea 0x0000ea R E 0x1000 LOAD 0x002000 0x0000000000402000 0x0000000000402000 0x000006 0x000006 R 0x1000 NOTE 0x000158 0x0000000000400158 0x0000000000400158 0x000030 0x000030 R 0x8 GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RWE 0x10 Section to Segment mapping: Segment Sections... 00 .note.gnu.property 01 .text 02 .rodata 03 .note.gnu.property 04 [hjl@gnu-17 ld]$ -- H.J.