From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 13429 invoked from network); 5 Jan 2021 02:12:32 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 5 Jan 2021 02:12:32 -0000 Received: (qmail 26448 invoked by uid 550); 5 Jan 2021 02:12:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26430 invoked from network); 5 Jan 2021 02:12:28 -0000 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; bh=pIj6tURDPqKUW5cZ0nAm9dKDesIZpyu3wZobIq3r0mA=; b=aSP+uLK9feY7ei2o+ABCVxWZhQvfFnBjcaGzMepGbrlqjd+lDd30tDy3AKAXJbMshS ftddPPyVZcidAlg4DCnuk1i9LTuMpUj6jcPfXUvYISJEstdneV2s79VwwDK93kap0E/+ vFno6Sgemj5KOWZC1qDY7ovdPhlnwEm/OlpBEDWwBfP3FvsN26fNejVrZfw7v8swurxs Kskse8zbNBci20Zt3HxVv6BaBgYaBRjzUO2Uz2FdTb6ZhU/uB+0grc/6LXZ6CMRrk8i7 GKFWtpYjdF8MG9ekHby/kJEVDgDDYrDbBUC6HNsuNt2PmeVv7hqhvPgL0K+u9RMfEnZE Tang== 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; bh=pIj6tURDPqKUW5cZ0nAm9dKDesIZpyu3wZobIq3r0mA=; b=fonVqi8bF0NZ1CK4yCpkcET6iimLss8CLISZCByXJ1wchXBUdQO5KQs6bg4j3mdbSR CPR5h2QfQDdXgCC2e+2zbCgSbQq4HbwIvtcI+8GpZuxG74U3KEd+vPg65JXgiT9YHIgh Cf8pvo94chKxSQqfkGMtiPfhFzlFCTbZprZXIt50D6NTjrXGuWJNBDt8Xd1LekmRDLwW hGsGbtC/y53AhLskPKgm9Zb/flR+w80rFJYEl5ipvkldgl/VW5CQCsXEiSKdTD8SwnHn U6DNpe4h/cJnZy3kEDYjR5qRzz8afQ6nn91IuBS2pBbk/xQrP3kmIPZUk7hQFQRLmwpv Xqag== X-Gm-Message-State: AOAM533QXL+Y+Jqv2Srbnn3zdGFI6aMyFWaXFlJvhoXJA7FGIwMjxrvS kuGHhstzKsN4zoQTCNSVmpJkx+jHmROxpPRw+O3eeDx1GNE= X-Google-Smtp-Source: ABdhPJyrDEf3oehV2fxt7DAUnERODerO1//5xd62yWSPJtgC9N8jGQ+tjGA6D/LuSTS7O96t8c6X8G3IytvWbi4nSWE= X-Received: by 2002:a37:744:: with SMTP id 65mr70417506qkh.71.1609812736328; Mon, 04 Jan 2021 18:12:16 -0800 (PST) MIME-Version: 1.0 References: <20201030184402.807422-1-raj.khem@gmail.com> <20201030185016.GD534@brightrain.aerifal.cx> <20201030205416.l6mx5gtx6pftz2fw@gmail.com> In-Reply-To: From: Khem Raj Date: Mon, 4 Jan 2021 18:11:51 -0800 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] [PATCH] crt: Add .file directive Thanks for update thats right way to go as well. I think we can ignore this patch On Mon, Jan 4, 2021 at 12:08 PM Fangrui Song wrote: > > On Fri, Oct 30, 2020 at 1:54 PM Fangrui Song wrote: > > > > On 2020-10-30, Rich Felker wrote: > > >On Fri, Oct 30, 2020 at 11:44:02AM -0700, Khem Raj wrote: > > >> Musl linked binaries come out to be not reproducible because > > >> absolute build path is seen in debug info of crti.o and crtn.o > > >> This is due to the fact that these objects are built from assembly > > >> source files and they are missing .file directive > > >> if we add .file .s in them then debug info encodes this > > >> value instead of absolute path in debug_line section > > > > .debug_line is unrelated because there is no .loc directive in these > > crti.s and crtn.s files. > > > > Many architectures do not leave non-STT_SECTION STB_LOCAL symbols in > > crti.o and crtn.o, so they don't need to be patched (even if the > > maintainer agrees to add the workaround in musl, instead of fixing the > > toolchain). > > > > >Surely there should be some better way to achieve this with CFLAGS > > >instead of duplication across every source file..? > > > > > >Rich > > > > https://bugs.llvm.org/show_bug.cgi?id=48023 captures the nature of the > > problem. You may send a message to binutils@sourceware.org how GCC/gas > > should handle this situation. > > > > LLD and gold do not synthesize STT_FILE, hence no such problem. > > The binutils action is: GNU ld 2.36 will use the base name > (https://sourceware.org/bugzilla/show_bug.cgi?id=26822)