From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vs1-xe43.google.com (mail-vs1-xe43.google.com [IPv6:2607:f8b0:4864:20::e43]) by sourceware.org (Postfix) with ESMTPS id EC56A385C8B2 for ; Tue, 30 Jun 2020 00:26:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org EC56A385C8B2 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jimw@sifive.com Received: by mail-vs1-xe43.google.com with SMTP id k7so8894520vso.2 for ; Mon, 29 Jun 2020 17:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VYGa45B4c9yzLL059+XqAj+rNNEXH/YDHcMR2rh5eKs=; b=B68Eeub418YSNILTheA0nJb/9WAflDzjrWJsS2RhukObgCC8vLsgW8LzVSbV7et32w ybxI2YQxohwjzBL5OwdnwcCyC4eSJ1WJR+KXTzu9yp0rjZzRDsi+kTXgBo5wHpGZiECu hWCWAbqrz0/EroB/Qw4+LInl/iEuWxseZQfsLtWzuyquvdtjbn4Gq1MsDdZ4R2GbN98t Xgkm169KKlrEQRW0e1giLEnSuTZov23lt0etvJdGySAemOlQaFOHBSxEszi9N96qOpqE chjq1NEYfqj1bJo+/LHXy/CnO72CYvzCZLLcka7I/je0VxfHfOjU5L6uo+g9E7UeidvW RqSQ== 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=VYGa45B4c9yzLL059+XqAj+rNNEXH/YDHcMR2rh5eKs=; b=CIiztx69707sn8i4drxywP7zHwTKXpzqzt4B6T+CmgwLBnqSeDIVNaTbJVct3oNxqH ZrvBMNRths0jNXZAOm2K7jmH8He4x9sgq0zhQwANONdWnZPAy+zSg9xQgMjqdsvTG/7S B2fjlVWwDerA+mbDZDyxXLzlGRvs7MIzjxToo3InVHqiOdKfLi7bM8QzFBWh/rsJwDtx 6icSyZk5U+SU2J+iPD0EQTJh57OVrExQML4/1iYim7s+MO0L8Wq8UukM4yFcEJdeitzc EpZ7AUxGpADAmxE4vzOl2kjByXW0iDzpwiUN39GY/nOaQ8muIHWvB3hjdnjUUZRt27oD 3+Lw== X-Gm-Message-State: AOAM533PKfJAMadIC+hSPx8EfufTwADzadbrfkJFTjUZBlQkn775otv/ YbW/T+EjuqrJTyGO5yw1sdDtrCb5Rjb2lD3AIBCUeIBM X-Google-Smtp-Source: ABdhPJzZqQr6KWH2zPUyEETYovdiKOruqJE4jt/vFxRM6aZ3xt7kNwuvDEqeoWjQbLs8D/iVbHJrS6geBMpo+l9VYGE= X-Received: by 2002:a67:eb98:: with SMTP id e24mr12843269vso.72.1593476780551; Mon, 29 Jun 2020 17:26:20 -0700 (PDT) MIME-Version: 1.0 References: <20200622211034.659739-1-alistair.francis@wdc.com> <87zh8u8d17.fsf@igel.home> <87o8p21bjh.fsf@oldenburg2.str.redhat.com> <87366dx35x.fsf@oldenburg2.str.redhat.com> <87sgedvnq3.fsf@oldenburg2.str.redhat.com> <87o8p1vnb9.fsf@oldenburg2.str.redhat.com> <87ftadvmnv.fsf@oldenburg2.str.redhat.com> <87r1txyfew.fsf@igel.home> <87a70lvm48.fsf@oldenburg2.str.redhat.com> In-Reply-To: <87a70lvm48.fsf@oldenburg2.str.redhat.com> From: Jim Wilson Date: Mon, 29 Jun 2020 17:26:09 -0700 Message-ID: Subject: Re: [PATCH] Allow memset local PLT reference for RISC-V. To: Florian Weimer Cc: Andreas Schwab , Alistair Francis , Alistair Francis via Libc-alpha Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Tue, 30 Jun 2020 00:26:31 -0000 On Mon, Jun 29, 2020 at 10:05 AM Florian Weimer via Libc-alpha wrote: > I think we should see R_RISCV_CALL instead of R_RISCV_CALL_PLT, like > here: There is a proposal to deprecate one of R_RISCV_CALL and R_RISCV_CALL_PLT, because whether you get a call to a plt or not depends on the symbol info, not the relocation type. We don't actually need two different relocs for this. Old ABIs like x86 have two relocs, but new ABIs like aarch64 have only one reloc for calls. So it was a mistake in the RISC-V ABI to define two relocs. The LLVM RISC-V port actually handles the two relocs exactly the same. GNU ld handles them slightly differently, but that is something that needs to be fixed when we deprecate one. I think that the RISC-V gcc port always emits the R_RISCV_CALL_PLT reloc when PIC, and always emits R_RISCV_CALL when not-PIC. Then the linker decides for R_RISCV_CALL_PLT whether we actually need a plt or not. Anyways, if you want to know where the PLT call is coming from, you can't rely on the relocs. R_RISCV_CALL_PLT is not necessarily a plt call. Jim