From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) by sourceware.org (Postfix) with ESMTPS id 22430384CB97 for ; Thu, 16 May 2024 07:30:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 22430384CB97 Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 22430384CB97 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::631 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715844627; cv=none; b=JrMooKUJbckKCuDVBrXc10vjrE604SVHEHGEYZKLKm4ndY28pjfhEL2uffyuFcabBXTdzLrfdiOrmq3VtjkkPZlRfxrdPZT4Hr6rTf1gEiTUJDhoMbuFlbfqqfht6FUV00vmLifxX25ieoPYxtEDwcB3lKKPtCHahsrx2bfDC1U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715844627; c=relaxed/simple; bh=9l9KCct1QzXFDRot7+wf5ltFS6DLwNLGcmY0ENvD5RY=; h=DKIM-Signature:From:Message-Id:Mime-Version:Subject:Date:To; b=VafHF8Ww77aFV/NZT3LpYLdgV0aj0QM59jmlsEgrGtrR7rqNkYMzBmdtUVGBf9+Zj+HZHbpcxx9JHreeuioPdh68YKH/Sw6FzzpzlxIdNgkyKyO6oeiti2X81AUkFPv4uHpE32UBBN6DSohrrpZAN4e25b4d0x0KQ0Wp9cDZmvg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-1eb0e08bfd2so48556145ad.1 for ; Thu, 16 May 2024 00:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; t=1715844624; x=1716449424; darn=sourceware.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=6C/tF52MFs8OHIbzDyKh5aqAN0Ctb28LY3jekEU0+6E=; b=a35QsR9Cy7Uyl4Zl94zAF/tePw7uousQ2avPSxqbH157YfY9ZiYQzrDLoJjcDbjrgF dEubakHEYxPQ13hWJZXEf5DPU2Y7Qpxuu/a/vHlRAgZ4DYhd46gJ7v/bsPKpD+QZmKX8 DjQEtN6RDREoq6AGkf+bYoBSe2+5GNSasqB+01kJXTlSq8KFXjyEpiOTGqtlJbkTydg9 b7WOxfTj10auDNmMTPz++Rme6nHk4tcQN0CVn9Voyu9MZjiE5FSBDS0qk1MbHaPYRYtS zAzzg+ojoJQnDaEs9U5B0uEKjdayGqNyjcVTdOM9XEXyzxWoX/rHBNCBfXog/JQeLSjm V+Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715844624; x=1716449424; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=6C/tF52MFs8OHIbzDyKh5aqAN0Ctb28LY3jekEU0+6E=; b=ZPL5jAgTuhpJ9DZym4K2ECAriIsVPsQpNtzlVEnr+4VokL1aa4oiCCHyb3CHwnvUbP K6OqLl4r62plQSOAVH7R0dslYJ7nplF1+5wQVbi6kiCAmP2j4A9tGr0ilX/Ycy4AFGt1 jVICkPFHgUPSY+gwbSq0qBRMYgzmhbalHLhYibESPIpj0JwD3ZWGf/h3EJMTPMmbdypg F1Yy2KsnsFMKh5CQE9147rKN0c1CRipClQZ1lwXFUEKxgrnIJ9cDwoXeDfX7wCP7Kgfw dxyFIHDm1CKq3AxuqavV/SVyWd+K3WwVAxuzYeH2L9pdBLSeDBbxQukb/JJMRMOEDVd8 kZmw== X-Gm-Message-State: AOJu0YzdP5hFbB3ZNM+CIdZ7MwajvUAsWltc2bpOgbcong+u4uUNLWYg rEywALNLrByVusVQrRgpTLz/E+PItFSTiDcS+3KeM2BTBCTgHJe316SmcB2Qj14= X-Google-Smtp-Source: AGHT+IF6NEcFVHx+TyYCfnBlSQ8Lv6yW+s20DvjREiXkavqncanMdZpMz6SROBdkvGWC9K7JO9i4EQ== X-Received: by 2002:a17:902:744a:b0:1e5:3c5:55a5 with SMTP id d9443c01a7336-1ef43c0ceb1mr166083595ad.8.1715844623762; Thu, 16 May 2024 00:30:23 -0700 (PDT) Received: from smtpclient.apple ([136.226.240.206]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-1ef0b9d4613sm134146435ad.44.2024.05.16.00.30.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 May 2024 00:30:23 -0700 (PDT) From: Hau Hsu Message-Id: <6B8C7B37-CAB2-40E0-9C3F-CA8F8B37D367@sifive.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_D7AD8BD2-BC50-4658-AE0B-03D0CA3AF14E" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Subject: Re: [PATCH 2/2] riscv: Fix R_RISCV_IRELATIVE overwrite and order issues Date: Thu, 16 May 2024 15:30:10 +0800 In-Reply-To: Cc: Binutils , Kito Cheng To: Nelson Chu References: <20240506044520.2780464-1-hau.hsu@sifive.com> <20240506044520.2780464-2-hau.hsu@sifive.com> <89C7C17E-5E9D-4E00-A3AE-FF1F014C0939@sifive.com> X-Mailer: Apple Mail (2.3774.400.31) X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,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: --Apple-Mail=_D7AD8BD2-BC50-4658-AE0B-03D0CA3AF14E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 16, 2024, at 3:07=E2=80=AFPM, Nelson Chu wro= te: >=20 > On Thu, May 16, 2024 at 2:16=E2=80=AFPM Hau Hsu > wrote: >> Hi Nelson, >>=20 >> Sorry for the late reply. >>=20 >>> On May 8, 2024, at 9:00=E2=80=AFAM, Nelson Chu > wrote: >>>=20 >>> Can you provide the testcase to show the case which I mentioned in the = pr13302? Which is that an ifunc with a dynamic jump slot calls another ifu= nc, and are not in the rel.dyn.=20 >> I am not quite sure what's the issue you mentioned in PR13302. >> You mean the order issue of cause by one ifunc (generates JUMP_SLOT[32|6= 4]) calls another JUMP_SLOT[32|64] ifunc? >>=20 >>> Since according to the testcase below, it seems no requirement to apply= this fix though. >> The new test case uses two methods to call ifuncs: >> 1. Through a normal function call: PLT + GOT >> 2. Through a global function pointer: GOT only >>=20 >> Without the fix, the relocation of the first method overwrites the secon= d's. >> The relocation section of my test case would be: >>=20 >> Relocation section '.rela.plt' at offset 0x94 contains 2 entries: >> Offset Info Type Sym. Value Symbol's Name + Adde= nd >> 000110dc 0000003a R_RISCV_IRELATIVE 100c0 >> 00000000 00000000 R_RISCV_NONE 0 >>=20 >>=20 >> With the fix, it becomes >>=20 >> Relocation section '.rela.plt' at offset 0x94 contains 2 entries: >> Offset Info Type Sym. Value Symbol's Name + Adde= nd >> 000110e0 0000003a R_RISCV_IRELATIVE 100c0 >> 000110dc 0000003a R_RISCV_IRELATIVE 100c0 >>=20 >=20 > So it seems like the overwrite problem, not the order problem we were dis= cussing in the pr13302... Yes. Sorry that I didn't explain the whole story well. This PR is originally to fix the overwrite problem, as my commit message sa= ys:=20 > This commit resolved two issues:=20 > 1. When an ifunc is referenced by a pointer, the relocation of > the pointer in .rela.plt would be overwritten by normal ifunc call. We found the issue when building glibc testbench statically. To fix this issue, I sent a PR (https://sourceware.org/pipermail/binutils/2= 023-July/128485.html) about a year ago.=20 The PR use the method smilier to your previous commit, i.e. https://sourceware.org/git/?p=3Dbinutils-gdb.git;a=3Dcommit;h=3D51a8a7c2e3c= c0730831963651a55d23d1fae624d Then you suggested to check whether the relocation order is correct. After that I checked the X86 implementation, I sent this PR. >=20=20 >>>> --- /dev/null >>>> +++ b/ld/testsuite/ld-riscv-elf/ifunc-macro.s >>>> @@ -0,0 +1,19 @@ >>>> +/* Define macros to handle similar behaviors for rv32/rv64. >>>> + Assumes macro "__64_bit__" defined for rv64. >>>> + The macro is specifically defined for ifunc tests in ld-riscv-elf.= exp. */ >>>> + >>>> +.macro PTR_DATA name >>>> +.ifdef __64_bit__ >>>> + .quad \name >>>> +.else >>>> + .long \name >>>> +.endif >>>> +.endm >>>> + >>>> +.macro LOAD rd, rs, offset >>>> +.ifdef __64_bit__ >>>> + ld \rd, \offset (\rs) >>>> +.else >>>> + lw \rd, \offset (\rs) >>>> +.endif >>>> +.endm >=20 > Btw, can we not use these macroes? No problem. I just want to avoid similar codes in the ifunc tests. >=20 > Nelson --Apple-Mail=_D7AD8BD2-BC50-4658-AE0B-03D0CA3AF14E--