From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc36.google.com (mail-oo1-xc36.google.com [IPv6:2607:f8b0:4864:20::c36]) by sourceware.org (Postfix) with ESMTPS id 825963858D3C for ; Wed, 13 Dec 2023 03:10:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 825963858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 825963858D3C Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::c36 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702437047; cv=none; b=V48OAlwX/K1fd7A2xwAgeNgAf5NXFlBOH9mK4EP+EyKraojalWErKCJh/f6Ml36C2MdfqFUyT7zVOWBsUXZyUH3zPjUG2eG8gqOw4kYUl9uIHGT+qTsP4jZlpziBsPSeEHyqtynJ2QTyiYRojEbkBnH1x/wzwhACj8HTWGXfmMk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702437047; c=relaxed/simple; bh=RO0/iQngMx9yuC6YZfQVo5gWDQTBgEFXlcQOjTNRwj8=; h=DKIM-Signature:Date:Subject:From:To:Message-ID:Mime-Version; b=QyAWRVL2s9G8wto4WsoL22mO4ugEU2zg+861aQdmJbmrPbsk+1Rr3WrV8RX/3Mp4KYMIfe6VYWoFc9ZR8gxHpzK3c+PYVBtONQKDBunErFdgVx7/UAuZXxJ94tQx2nP3Io/K+INzlmk/7ZJmuLXL0DPuAnqbtgcPVPTw92AEISI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oo1-xc36.google.com with SMTP id 006d021491bc7-5906e03a7a4so3601114eaf.1 for ; Tue, 12 Dec 2023 19:10:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20230601.gappssmtp.com; s=20230601; t=1702437045; x=1703041845; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=UTT4utxcKp454Tow67nCV9vRW2H8R8yRl2SrZiGTQKw=; b=M0/zSq5tjg1x7zXsXZ26fEoZU7GyVXb0u0sdpMUOb9NDQZqblB+3MZwfv60YSJno9g N07ej7eA95r/3p687cOtSOtYza26BFs6Btq8CiIsIF5aUhH8Ers+hfcGpSj8xnx70xXE p1xONjDESN6u2vILZuQHPKSxJRvqHCnuECo3Vz79TCEXn0pNByFLHZX7uUkE2rC6STBu l0dYCf3Lr8yNq0u9VytwviBsAmluQgU8/xnmKStfDd5x3ESi3NZQdmQiZaoHoH2BkHQL /MKhk17OkMa4KdwM+MhHIAK7KhgHnH9Etz29KN256M1bB6gvyFs7I9ahERn1XruPzj9E UxNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1702437045; x=1703041845; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=UTT4utxcKp454Tow67nCV9vRW2H8R8yRl2SrZiGTQKw=; b=un8lpU0gZUa3MxlwyfofnFUnuMlC/q0V1HcJ2E2n5xn+GtdjCtNdN5gDu+vrqKzOV4 5c+ivo2ynIDZhscrxJqb136WKfTr1Cq/nak18bio/HzjAX9zHH5WnaE5/WlOHTJ3YzfO tELM05uVMOOeOnCzBPaeP8QZ1L5dZnU7YoTc1pipQ5GfzaahzYp4wSO2c1iLDqPGVajZ Mf6l0ErtZTpzrYGS0vMNCHomY3en4nyR2THa5r5AQcjDYMbRUkhoTwR4Y9q5QCHG/sF+ fp6pg4vyMG8djQz93f1zagFbYLxaACI8FaOjR0srZsUD7xr5DZHlfI3+DzGIwWYa2WlM Ev3g== X-Gm-Message-State: AOJu0YznpzyzuT978SAuMm6oV2mLOFw0kDI45tZDU0WTVJ6KwtyTqSdU EDLHI0SXgGPtf+/0051ovPNNJQ== X-Google-Smtp-Source: AGHT+IFXvMipCUP9Fr+7OYDoJxTFfY9jFRP3SSD5t3EfOObjWMSVgX+8vwNmSfBSGze8qR6LNhR7oA== X-Received: by 2002:a05:6870:e8d:b0:1fb:75a:de62 with SMTP id mm13-20020a0568700e8d00b001fb075ade62mr10452229oab.80.1702437044676; Tue, 12 Dec 2023 19:10:44 -0800 (PST) Received: from localhost ([192.184.165.199]) by smtp.gmail.com with ESMTPSA id gu11-20020a056870ab0b00b001fb3143cc0bsm3691932oab.44.2023.12.12.19.10.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Dec 2023 19:10:44 -0800 (PST) Date: Tue, 12 Dec 2023 19:10:44 -0800 (PST) X-Google-Original-Date: Tue, 12 Dec 2023 19:10:42 PST (-0800) Subject: Re: [PATCH] RISC-V: Do fixup for local symbols while with "-mno-relax" In-Reply-To: CC: lifang_xia@linux.alibaba.com, nelson@rivosinc.com, binutils@sourceware.org, Kito Cheng , Andrew Waterman From: Palmer Dabbelt To: i@maskray.me Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 12 Dec 2023 18:47:05 PST (-0800), Palmer Dabbelt wrote: > On Tue, 12 Dec 2023 17:26:03 PST (-0800), i@maskray.me wrote: >>> In the scenario of generating .ko files, the kernel does not relax the .ko >>> files. However, due to the large amount of relax and local relocation >>> information, this increases the size of the .ko files. >>> >>> In this patch, it will finish the fixup of the local relocations while with >>> "-mno-relax" option. This can reduce the size of the relocation table. >> >> Thanks for the patch. I was initially confused by the description. >> Perhaps clarify it to: "... the Linux kernel uses -mno-relax but still >> gets a lot of relocations which can be eliminated" and "... resolve >> some fixups to constants and remove relocations" >> >> On Tue, Dec 12, 2023 at 4:31 PM Palmer Dabbelt wrote: >>> >>> On Tue, 12 Dec 2023 02:44:07 PST (-0800), nelson@rivosinc.com wrote: >>> > There is another stuff, do we need to limit linkers that only can link the >>> > objects with -mno-relax if this optimization applied? If so, then we >>> > probably need, >>> > 1. An assembler option for this optimization >>> > 2. Record the object is relaxable or not into the elf attribute? or >>> > readelf header? or ... >>> > 2.1 Maybe we can record the relaxation information with >>> > Tag_RISCV_x3_reg_usage?, >>> > https://sourceware.org/pipermail/binutils/2023-September/129500.html? >>> > 2.2 Once the object enables relaxation for some code, the object needs to >>> > be marked as "relaxable", even if it sets `.option norelax' later. >>> > >>> > On Tue, Dec 12, 2023 at 5:46 PM Nelson Chu wrote: >>> > >>> >> The idea looks good to me. Passed regressions of riscv-gnu-toolchain, so >>> >> committed with some minor changes and indent fixes. >>> >> >>> >> There are some TODOs, but no rush to do for now, >>> >> 1. The implementation is based on the code from bfd/elfnn-riscv.c. We >>> >> probably can move the code to bfd/elfxx-riscv.c, so that can reduce >>> >> duplicate code, just like what we did for the architecture parser. >>> >> Before that, I renamed functions and variables from *reloc* to *fixup*, to >>> >> distinguish the code from bfd/elfnn-riscv.c, since they are still a little >>> >> bit different. >>> >> 2. Maybe not only pcrel_hi/lo12 relocation with local symbols can be resolved >>> >> at assembler time. Other pc-relative relocation, like branch, may also >>> >> be able to perform related optimizations. >> >> Agree that GNU assembler can resolve more PC-relative instructions to >> a constant without a relocation. >> For example, LLVM integrated assembler resolves the following `j` to constants: >> >> // clang --target=riscv64-linux-gnu -march=rv64i -mno-relax -c >> j .Ltmp1 >> j .Ltmp1 >> .Ltmp1: >> >> (Though LLVM has its own problem that a `.option relax` anywhere in >> the assembly file will lose this optimization.) >> >>> Nelson and I were just talking about this. I'd been leaning towards >>> adding another option along the lines of "-mno-relax-abi", which would >>> explicitly mean that users can depend on no objects being relaxed. That >>> said, I'm not actually sure I can come up with a case where anything >>> breaks. >>> >>> I was specifically worried about things like the compiler doing label >>> subtraction, but IIUC that can only happen within a single translation >>> unit so we're safe to take advantage of on R_RISCV_RELAX relocations. >>> >>> There's also cases like misaligned globals, but we're already broken >>> there so I'm not sure it counts. >>> >>> So maybe this safe? >> >> I lean towards not providing an option. Beside the previous paragraph >> that LLVM integrated assembler omits relocations in more cases, >> architectures not using linker relaxation do optimize out relocations >> in these cases as well. >> It's a missing size optimization for RISC-V in the -mno-relax configuration. >> Users relying on the relocation can switch to `.reloc ., R_RISCV_JAL, xx`. > > Sorry for being confusing: I agree resolving local R_RISCV_CALL > relocations at assembly time (or I guess, not having R_RISCV_CALL at > all) is safe as long as the call does not cross a R_RISCV_RELAX (or any > of the normal-smelling boundaries like sections and such). > > Nelson and I were wondering if many other PC-relative relocations can be > processed at assembly time whenever they don't cross a R_RISCV_RELAX I guess that's a silly statement: of course we can do all the assembler-time processing. I was mixing up compile-time stuff like working around the auipc overflows in there -- I think we can also do that sort of stuff, I just forgot there was anything going on before the assembler. Probably time to get some sleep... > boundary (and meet all the other rules the other ports need to deal > with). I think there's a bunch where we can, and it's possible just > having no relaxations in an object is sufficient to enable any of these > optimizations. > > FWIW, I'd still lean towards providing some sort of option/ELF flag that > just bans relaxation entirely -- we basically don't use it in modern > Linux user binaries (unless I missed some PIE optimizations going in), > so we might as well just properly forbid relaxation.