From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id E429D3858402 for ; Thu, 28 Oct 2021 01:18:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E429D3858402 Received: by mail-pg1-x52a.google.com with SMTP id 83so4733555pgc.8 for ; Wed, 27 Oct 2021 18:18:58 -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:content-transfer-encoding :in-reply-to; bh=Wn21CcYkr8TdV1kMS8R5I4aqry0ibYsZa1lO1enorFA=; b=35nKxDqe+bFYrCYJnRBIIFygKmI/fWvZkCoFSzc5e9xmBBGEPlVXJMEYz6G6+0qBbh rxPKLlzLFMFVJvYVbXNAHFMJ13vpiPPx+oI1uQQ5Z6LnJiHmgUmbiae2wDU3M90ls74g Q6clFAWL84xzxb3fSze/u6Br+d29hq4mqWKFtvwGWGK/hPEfnYW4W2DKwguWY8jLAvU8 oP/+tcGy6LogTE+YXRbzCjaobmKFylqpph+6FUNywjKbe/CVGg7+bxBVbmvdEnTlRuqJ 5XXOl4elnwCuNoSklao0QsGMrhQ1DrwpXYsJxgsxPX2COarErB7pf03RimmlnQmkdV4Y Lz5w== X-Gm-Message-State: AOAM531NXk0bh/SxWp3AmYIqPmmu4LOcd7IfVF12vpq9ZwjjIQCqAfqi ZrTd5GDG6t4x+3Xc3fCdn3N239Zr5I2dcQ== X-Google-Smtp-Source: ABdhPJxbhm2mHadeVbKStI3BCa35ld6H/dtMO1TZmXkgDO+WXh/0LUbxHcjW8DWtokpYcAmjyTxb0A== X-Received: by 2002:a05:6a00:21c1:b0:47c:11e0:84e9 with SMTP id t1-20020a056a0021c100b0047c11e084e9mr1155752pfj.23.1635383937826; Wed, 27 Oct 2021 18:18:57 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:5bee:97c3:491b:d4cf]) by smtp.gmail.com with ESMTPSA id q10sm894197pgn.31.2021.10.27.18.18.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Oct 2021 18:18:57 -0700 (PDT) Date: Wed, 27 Oct 2021 18:18:54 -0700 From: Fangrui Song To: Adhemerval Zanella , Joseph Myers Cc: libc-alpha@sourceware.org, "H.J. Lu" , Tulio Magno Quites Machado Filho Subject: Re: [PATCH 0/3] Improve lld support and current status Message-ID: <20211028011854.yrenushtllg23qop@google.com> References: <20211026200346.3371750-1-adhemerval.zanella@linaro.org> <20211026203327.6b2o5k4cmkuzzm6j@google.com> <20211028010630.dagff7p6rvygziho@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20211028010630.dagff7p6rvygziho@google.com> X-Spam-Status: No, score=-18.7 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, FSL_HELO_FAKE, 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: Thu, 28 Oct 2021 01:19:00 -0000 On 2021-10-27, Fangrui Song wrote: > >On 2021-10-27, Adhemerval Zanella wrote: >>>>Similar to mips64/mips64el: >>>> >>>> ld.lld: warning: ../sysdeps/unix/sysv/linux/setitimer.c:(function >>>> _dl_runtime_resolve: .text+0x18954): found R_MIPS_JALR relocation >>>> against non-function symbol . This is invalid and most likely a compiler >>>> bug. >>>> ld.lld: error: can't create dynamic relocation R_MIPS_64 against local >>>> symbol in readonly segment; recompile object files with -fPIC or pass >>>> '-Wl,-z,notext' to allow text relocations in the output >>>> >>> defined in >>>> >>> /home/azanella/Projects/glibc/build/mips64-linux-gnu-lld/elf/librtld.os >>>> >>> referenced by ../sysdeps/unix/sysv/linux/setitimer.c >>>> >>>               /home/azanella/Projects/glibc/build/mips64-linux-gnu-lld/elf/librtld.os:(.eh_frame+0x20) >>> >>>I took a look at LLD's R_MIPS_JALR code and I am inclined to trust it >>>reporting a genuine issue. >> >>I give you that loader code is tricky, but it does not really explain why >>lld is failing to link the eh_frame. It *might* due some internal assembly >>routines, but at least from logs it does not seem so. > >Hope Joseph can answer the question. > >If we have easy-to-follow instructions building glibc mips with LLD, I can >forward it to Simon Atanasyan (MIPS code owner of llvm-project and the major >contributor of LLD's MIPS port)... > >But see below (for riscv/), I suspect this is a glibc sysdeps/ problem. jrtc27 told me that BFD mips has a hack to rewrite R_MIPS_64 in .eh_frame to avoid such a R_MIPS_64 diagnostic. LLD doesn't implement it. Clang's mips port emits relative relocations in .eh_frame (DW_EH_PE_pcrel | dwarf::DW_EH_PE_sdata4) to avoid the linker issue: https://reviews.llvm.org/D72228 Lack of 64-bit PC-relative relocation is a longstanding problem for mips. LLVM integrated assembler and linker actually support `.quad foo - .` via composed relocations, but it is still unsupported in GNU as (feature request: https://sourceware.org/bugzilla/show_bug.cgi?id=26222) I know really little about MIPS but I'd wish that GNU as implements .quad foo-. and GCC migrates to PC-relative relocations like Clang.