From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by sourceware.org (Postfix) with ESMTPS id 46E5E3858D28 for ; Fri, 29 Apr 2022 19:26:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 46E5E3858D28 Received: by mail-pj1-x1034.google.com with SMTP id iq2-20020a17090afb4200b001d93cf33ae9so11343928pjb.5 for ; Fri, 29 Apr 2022 12:26:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=9OfWET3TBlDIPxQhjlS59HAjyr/1ZcDx7deL7sRdV1M=; b=tmgoiDjF+ehsWg1GuUnxycCdzbBZHQdS1WmguFkslE0Dwxf0/IrKdfgRDOc6cy8L99 ZI5biUYAUiNSiQU0pQUIreXkbMXIzKrUbDfT9E7EYImCP/EsbYBpIcoMsivQfwVPAwkH ol/1X2Kio3HOZzGsDpOPr7f8l8LFizQHi2vJCsmEP2XytwVXDGT/8Jx1F7LHZSguCz1w LEXhU+O5XjnWqPcw8mCUNybjlHhmHO5MZoOfalZfq1WiWmSygGC5vOr7fINg90CpF7oZ Umln740tGKm/ZB+P1ufD8yP6OzrmVkev0nSYeq6rsTchHCYgnZv5Tglxni7nX7F2uBqg TQRg== X-Gm-Message-State: AOAM530wKbD2BDobXuSCXc3zbrGbnsRaS+lG/UGHnZ9B4gyU0/M2Jyf/ 2k03q7BrvokQ3TwfMXB0HS0uRZZwCzqXRQ== X-Google-Smtp-Source: ABdhPJwX6SFM2khLUqcCa2xHCXz7HvC3M1v5XvDyCdhZjZ51u0+dQdgkaA/P0bC8fdWmQZbhVGe6YA== X-Received: by 2002:a17:902:7109:b0:15c:e11e:efd with SMTP id a9-20020a170902710900b0015ce11e0efdmr862341pll.110.1651260367133; Fri, 29 Apr 2022 12:26:07 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:d5a:e6d0:22b1:9ceb]) by smtp.gmail.com with ESMTPSA id l5-20020a63ea45000000b003c1b2bea056sm2272801pgk.84.2022.04.29.12.26.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Apr 2022 12:26:06 -0700 (PDT) Date: Fri, 29 Apr 2022 12:26:03 -0700 From: Fangrui Song To: Florian Weimer Cc: libc-alpha@sourceware.org Subject: Re: [PATCH v3 2/2] Default to --with-default-link=no (bug 25812) Message-ID: <20220429192603.5fie77dirvmc2gki@google.com> References: <15c7f6e9afe2c2b9c51ebc6372682a39b0932712.1649691083.git.fweimer@redhat.com> <20220428072502.4rpxnlreq72sgv5x@google.com> <87zgk5bnxo.fsf@oldenburg.str.redhat.com> <20220429060041.n24pkmlujglkumer@google.com> <87h76c74cb.fsf@oldenburg.str.redhat.com> <20220429074349.gna53j7ujgqql4ux@google.com> <875yms0wie.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <875yms0wie.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-19.9 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Apr 2022 19:26:10 -0000 On 2022-04-29, Florian Weimer wrote: >* Fangrui Song: > >> On 2022-04-29, Florian Weimer wrote: >>>* Fangrui Song: >>> >>>>>How does lld place sections without a linker script? Purely based on >>>>>names? >>>> >>>> It entirely uses code to describe the built-in rules like gold, while >>>> GNU ld uses an internal linker script plus built-in code. >>>> (some rules cannot be described by the linker script language and needs >>>> code anyway). >>> >>>How can we make sure that certain sections are covered by RELRO, and >>>still get start/stop symbols for them? >> >> About __start_/__stop_: >> __start_/__stop_ symbols are special. They don't need to be mentioned in a >> linker script to take effects for lld and modern GNU ld. I haven't checked >> whether there is an ancient GNU ld which requires symbol assignments when the >> output section description is specified. > >According to the BFD ld documentation, __start_/__stop_ symbols are only >generated if the resulting name is a C identifier and the name is the >same. That means that if we name the section .data.rel.ro.vtables or >something like that (to benefit from .data.rel.ro.* placement), we won't >get the start/stop symbols. If we use a C identifier name for the >section, it won't be covered by RELRO. I know the rule. I meant I don't find a way making lld build have RELRO __libc_* without the help of ld.bfd --verbose ;-) >> About RELRO: >> It seems that there is no section name convention to make a section >> RELRO. Having a SECTIONS command with DATA_SEGMENT_ALIGN / >> DATA_SEGMENT_RELRO_END can specify all RELRO sections. I do not know a >> simpler approach than postprocessing ld.bfd --verbose output. >> >> To make GNU ld work, the following linker script is sufficient: >> >> SECTIONS { >> __libc_subfreeres : { *(__libc_subfreeres) } >> __libc_atexit : { *(__libc_atexit) } >> __libc_IO_vtables : { *(__libc_IO_vtables) } >> } INSERT BEFORE .data.rel.ro; > >That might work. But if we cut down the number of vtables, I think we >can eliminate those special RELRO sections altogether. > >We have been slowly migrating off __libc_subfreeres and the like because >having shutdown order depend on link is very non-obvious and >problematic. For example, for optimimum results, we want to shut down >malloc last on a thread. If there is a way to get rid of __libc_* output sections, it will certainly be great! >Thanks, >Florian >