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 870163858D37 for ; Thu, 20 Jan 2022 02:43:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 870163858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dabbelt.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dabbelt.com Received: by mail-pg1-x52a.google.com with SMTP id 188so4414410pgf.1 for ; Wed, 19 Jan 2022 18:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20210112.gappssmtp.com; s=20210112; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=nep5TWPAa0YMiEA5vK7w1I6yESWG609hcLfrTISlzGs=; b=euKk34JQKf2AfMdzHTNj/Md0seZo1IDE9O7WdWwna01R5oacEH+v3ZmyRHwSoAINUO /DgHI1N3N6ovdB0wZAtz/P4RfZLJ3iP8/Is15EbOTAcgobAfit8tUWRq06+eujy4Yjj7 tnywDMKQVVhg6lnlQ4jCIjygWZxL7uGlB4GKXkwouaFW8qU0NvfZfZhVBNXIkqTeE8+w C77Dwp2UK9Cp4jV4gvMi8kZbNNfdnXilwjeExgmJlcl11Lp6+6OmKxwDTvXWHKxAFHPP SWcEovXW61CAZgXQsi8AJOgF4hVu2Q1vJJgpJHdEQ86/dN/TZdxEGfMAMiPVy8buzRzh JbFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=nep5TWPAa0YMiEA5vK7w1I6yESWG609hcLfrTISlzGs=; b=Q0mblhG827zJza3wPcabK6qM1RaroYWc23fJhiFnJ4NiUo/xWlF2kpaiYzOOOHLb+Q tVt1YGuCZ0qJzFMc3Iz9Mrl23JlAvOOESdQvFcwmekZePcAniw34u10BRYRDpkfR2+eU zeyuH6Vh990OJYIyfKDuu5SkV2FdoGu6tZ+q8mzbtacpuq7hMgLD1luHvGaSdfwSpOV1 JKAVsc1/7UwKq+xXnS1UZAB3zlU1V0D5hNI+aabC8CnwKflfveqUsfywmGrgEonKsBwI Tg4pbB1c1fkU/LjzoU07SCN/O2fJ+NsPMY8h/y4qAdmBfy1Z+vTwuadY9gnFKYo2/k3Z PeWA== X-Gm-Message-State: AOAM532qCzvBPwvgrVZgLRrfTx0XKkWekO2+ZmbMizXETt8ogzw6GIJ+ y1b32+cJXN497O0fMejjUW1j1Q== X-Google-Smtp-Source: ABdhPJxX+hNuD31NW4xpMoNQXb5ECtZ504z7ptxxhvaBiGlfU+ExYzK7U+APtU2B/Mu5FXUDi7HDQg== X-Received: by 2002:a63:8648:: with SMTP id x69mr6713844pgd.434.1642646613590; Wed, 19 Jan 2022 18:43:33 -0800 (PST) Received: from localhost ([12.3.194.138]) by smtp.gmail.com with ESMTPSA id u8sm939128pfk.88.2022.01.19.18.43.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 Jan 2022 18:43:33 -0800 (PST) Date: Wed, 19 Jan 2022 18:43:33 -0800 (PST) X-Google-Original-Date: Wed, 19 Jan 2022 18:43:06 PST (-0800) Subject: Re: [PATCH v2 2/2] riscv: Resolve symbols directly for symbols with STO_RISCV_VARIANT_CC. In-Reply-To: CC: vincent.chen@sifive.com, libc-alpha@sourceware.org, Andrew Waterman , kai.wang@sifive.com, greentime.hu@sifive.com, kito.cheng@sifive.com From: Palmer Dabbelt To: H.J. Lu 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=-5.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.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, 20 Jan 2022 02:43:36 -0000 On Wed, 19 Jan 2022 18:38:35 PST (-0800), H.J. Lu wrote: > On Wed, Jan 19, 2022 at 6:22 PM Palmer Dabbelt wrote: [snip] >> Given the complexity around this psABI spec deviation and how close we >> are to release I'd prefer to wait and see if we can come up with a >> better solution, though -- for example, I'd been kicking around some >> ideas related to ELF object attributes saying "this follows the >> psABI-1.0" vs "this follows the legacy GNU psABI extensions". That way >> we could at least tag binaries that explicitly rely on this new behavior >> as such, which would give us a shot at eventually getting rid of them. > > If you want to go this route, I suggest you use GNU property for this. > ld.so supports GNU property. Makes sense. I'd been thinking of essentially just defining one bit for each of these incompatibilites, with an absence of them meaning the legacy behavior and then a true/false meaning that users have explicitly opted into to the spec'd or legacy behavior. I hadn't gotten as far as actually figuring out where to put those bits -- I got hung up on the pc-relative vs position-independent one, and that's clearly for after this round of releases so I kind of just put it on the backburner. Given that pretty much all of these are going to need to drive runtime behavior, though, it sounds like a GNU property is a reasonable way to go. There's going to be a lot of edge cases here, though, so happy to hear if anyone has ideas ;) Thanks!