From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x29.google.com (mail-oa1-x29.google.com [IPv6:2001:4860:4864:20::29]) by sourceware.org (Postfix) with ESMTPS id 3CC253857376 for ; Thu, 20 Oct 2022 03:22:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3CC253857376 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-oa1-x29.google.com with SMTP id 586e51a60fabf-132fb4fd495so23052399fac.12 for ; Wed, 19 Oct 2022 20:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=sQO4KeEUHe8OWTWxldro/8LrmfK4plQSRlwoLXZo6qw=; b=2VOY/ZJdgC84n3wCtnajCTmv5o8f0z13k4dAvAAF3qDsYYiiYDBkz1eiCbJuYaMD4W 3TBeOTQg16G/6PSTFJZb5FfcUjwq6HuLa4PAm54rq1RK5PzRVmtUjS/rvrWyLvs+SB8X njGK8I1CQUT/H4+OH9cil0Ogp6HpSQVDw/APFgUK9JdHxRqpHisDVNOlm5v+zLXPA5iW PH/clVdsEfIIVhuhEEfCzDPmI8zWqZEU7KmnJoSV1oPeOWkS9OnABrYJuOJB5ktGQ0ss MVTifNUcAx6Ii8t2v++e6IbM7679cCiSwVeIPOqmfh+8nVaM6WD3Mrr+Qrqjbk/vxTp0 uW2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=sQO4KeEUHe8OWTWxldro/8LrmfK4plQSRlwoLXZo6qw=; b=P8iYJ4dCOHe3AgV8cBpUzyqibPMe4JB8caKiTnwIAzQdulWNllAvre2TneL6EicgzZ EhcdDLWoVM61pVAR8fe2XjtBjaRktUAf1LJeDa+2UI413x9HOQr0cieIm3XZogWl/s3z 9YwV+ee0t63rvj+xPW3cm9JOPzxZWwnt3KSUPGCbLRgXStrewdMLVxUQl/runQc6sPLD nv+ZiPP0geCdBL9Ki+UkbNoooVcV03M3VKvjZdKKbYQZx5S1oizUIwnxbxYHzI4RPO4i QjYzGh8UY7sdJGtaNvzZ6KYceUNslSgfasNGNPAujuacxa0051+l8ENfranH42GfRcy0 9RAA== X-Gm-Message-State: ACrzQf1f7SU+y6CXixQkzGOlG/a0dR2HfCUyMzqnLh4J0y0bTGVEhA90 L4sOmqW5Q+dxO4+A2msZX4SNGt5MJAngEZKFUM/nkw== X-Google-Smtp-Source: AMsMyM43OBhgujdQEwHpPTtaUQgVZQtI4fK7kImrs1xpjGGqeoOSvQHhZKT9RPNa4P0X6JtDEh6A0Td8WIBqKCXZTUY= X-Received: by 2002:a05:6870:507:b0:130:ae8d:db0e with SMTP id j7-20020a056870050700b00130ae8ddb0emr24422147oao.82.1666236132681; Wed, 19 Oct 2022 20:22:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nelson Chu Date: Thu, 20 Oct 2022 11:22:02 +0800 Message-ID: Subject: Re: RISCV PC to GP-relative relaxations vs section movement To: Dmitry Bushev Cc: binutils@sourceware.org, Jim Wilson , Palmer Dabbelt Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: Hi, Probably caused by, " warning: link_issue_err has a LOAD segment with RWX permissions" + DATA_SEGMENT_ALIGN in the linker script. Your custom linker script just has a LOAD segment containing every rwx section, so it seems no need to have the data segment alignment. Or you probably can define more segments to separate rwx sections though. Or, your custom linker script should re-dfine the gp value, since I think the gp estimation in the default linker script is assuming gp won't cover range cross DATA_SEGMENT_ALIGN. Although the .init_array section is placed after the DATA_SEGMENT_ALIGN, I am not sure if there may be some unexpected behaviors when setting the DATA_SEGMENT_ALIGN in the LOAD segment. Thanks Nelson On Thu, Oct 20, 2022 at 12:21 AM Dmitry Bushev wrote: > > Hi! > > I discovered one serious issue in the gnu ld riscv backend with custom > linker script. It is about pc-to-gp relaxation. In some cases linker > reports error: > > relocation truncated to fit: R_RISCV_GPREL_I against symbol ... > > I attached minimal reproduction (program source, makefile, default and > slightly modified linker scripts). Everything works fine if linked using > default linker script. But with modified one it fails. The only > difference from default script is explicit memory region specification, > which is essential for embedded environments, so I cannot remove it. > > I've done some investigation and root caused the issue: > > 1) On relaxation stage, linker sees, that it can relax pc-relative > relocation to gp-relative, because symbol address is close enough to > global pointer (fits in 12 bits immediate offset). > 2) Later due to code size change during relaxation linker rearranges > sections which causes symbol address shift. Global pointer also shifts. > 3) On ldwrite() relocations are written, but due to symbol address and > global pointer relative shift, the offset happens to not fit into 12 bit > immediate anymore, which causes linker to report the problem. > > I am trying to fix this. Problem is: fix shall be somewhere in > RISCV-specific code, but most of the linker section motion logic is > platform-independent and it is not clear for me how to interfere in this > process in the cleanest possible way. > > Will appreciate any help. > > Best regards, > Dmitry