From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 750453857BAA for ; Thu, 7 Mar 2024 08:32:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 750453857BAA Authentication-Results: sourceware.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=google.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 750453857BAA Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::62b ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709800342; cv=none; b=CznP+/PFfcvpvO9sHi+CcubH/OLrM2dEDH1J2wGQaiXK/wuezxidvtvpZSxEGt/pi9fA+QeUVwPjfnWcKzz+lFF88RRK1SocbzddXs/3tEZOH5jNg/uWii2DR/OV/d/Ew1b44sVpOxJ81kEkr8noYY6qJK6TtwEvmZH0Mep5Jto= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1709800342; c=relaxed/simple; bh=k4IVwXRBtX32mStzhkQGFFhwBxCxOiRYntyY0OLEopk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=WQgd10CAOZhXGQZTkwRMS/AIq85AjAe5onyiDjETvl5bSkmVYMme9dSUXimlKmNFok9Ptt/wIw+MiEhWK8ESNfIK6McTtFOdRDuIyHcBZQQefuk42gFc9crQFIgfDem2ap2oV2X83dVOuVCrUMZzYA2IJ9+xq/ekHadxPa7nRVk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pl1-x62b.google.com with SMTP id d9443c01a7336-1dc9f4d1106so129735ad.0 for ; Thu, 07 Mar 2024 00:32:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1709800330; x=1710405130; darn=sourceware.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=h3KhpTwWzFckdahVA8teE6l+9D3i7iQZ07Z8trmWU7w=; b=zKNy4EGswi9lBvcaT6wjMwe9oqN6NsGcsrvRPrMwra+8UlZ3FxytJ6P9CjrVe/7azE SxZpFpoxE03GkE+2uXSwtmlGF4scmw3FXPgrTW1Z51Q2xxNty/7DSXZlQrScN+DLNHS7 VA1c3eCifTymTxwmK1YF1YUIB99C0KrB51nf+QxyRxQXneltSpxD0OxSAZ1MKQr10ZZq JtCouFintMsvNsnAnOGH7P7fpTiH8NlqlnHG4pLIQwNXE+ViwUEHbWvXa84ltj8hbafY RvCCFU6+qvb2ZubZ2phKOsE1i6PdD5Zcd/zZ6Fqb7xcrF/mCMC/pSNE92WYgdubTan/L fKOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709800330; x=1710405130; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h3KhpTwWzFckdahVA8teE6l+9D3i7iQZ07Z8trmWU7w=; b=MHsb8BbNsAtziaE0R9fvKkSxyUuUptox6v0DPeLWr0MkXIWvhila5MCBV89TTNe6mc aiA8nnXYxkzoGb0/E3Xvr2UyFfNddFUxp16033U4a+XQIe5IXg22s7rJ6wWRl/X+4Kbq JB8toaHfkfQY6ta5TfrlOrNtcQSUnWkfwgITTQpnZhYUM2WANmLRbdF99irsCGEXyK2J VNCNLY1+ceuCkR4ywPCyZQ2CSjO5Wj1WXeKGCUko3NkuE+/5h/lXxLO60sAaTdbsNY6s IiIOlgnq9SS7OEzVc5Uise3f3gApUz7O1koktGyM/sWYRZPC3SSE75Rznk8n3hypP00K FACA== X-Forwarded-Encrypted: i=1; AJvYcCXBv68iNiLGgZhypApjiDIF9Kw81YoGAdAyL/wgN2rBMngHGKcx5ElwRU3c/5BbHHWXT4iiSeOOZ33spRDuOWs5wpzWBEb8Ow== X-Gm-Message-State: AOJu0YwoKDswXZKDwcwBr/QsVlW6uwaIMPx1X6vyCiCKLzxJ8rfx1n9O XRr+y6zH4wMyNrmw2gPafNYtoBN2VVj8BRmEKgOS691tpjW494McDPFZ9/Djew== X-Google-Smtp-Source: AGHT+IHYpFBFpQBO7R0IbjVyG11Fotq5hwTsqIdv5JmyC1GRx3gD8uYz7Otyj7Ei6BUfXmWCJ3omKw== X-Received: by 2002:a17:902:d2c2:b0:1dc:d50d:f662 with SMTP id n2-20020a170902d2c200b001dcd50df662mr161807plc.9.1709800330091; Thu, 07 Mar 2024 00:32:10 -0800 (PST) Received: from google.com ([2620:15c:2d3:205:8b43:1717:f7b6:f6a5]) by smtp.gmail.com with ESMTPSA id x19-20020a056a00189300b006e65d4679d2sm642486pfh.153.2024.03.07.00.32.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Mar 2024 00:32:09 -0800 (PST) Date: Thu, 7 Mar 2024 00:32:06 -0800 From: Fangrui Song To: Alexandre Oliva Cc: Alan Modra , Joseph Myers , binutils@sourceware.org, Fangrui Song Subject: Re: [PATCH v2] sh: Make protected symbols local for FDPIC -shared Message-ID: <20240307083206.deeatabdkuxsg4jk@google.com> References: <20240305004339.1353851-1-maskray@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-17.8 required=5.0 tests=BAYES_00,DKIMWL_WL_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,ENV_AND_HDR_SPF_MATCH,KAM_INFOUSMEBIZ,KAM_STOCKGEN,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=no 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 2024-03-06, Alexandre Oliva wrote: >On Mar 4, 2024, Fangrui Song wrote: > >> __attribute__((visibility("protected"))) void protected_fun() {} >> void *get_protected_fun() { return protected_fun; } > >> links fine in the non-FDPIC mode but not in the FDPIC mode: > >> R_SH_GOTOFFFUNCDESC relocation against external symbol "protected_fun" > >This appears to be in line with the comment over SYMBOL_FUNCDESC_LOCAL: > >> /* Decide whether a reference to a symbol can be resolved locally or >> not. If the symbol is protected, we want the local address, but >> its function descriptor must be assigned by the dynamic linker. */ > >If the comment is wrong as your proposed change suggests, it ought to be >fixed along with the patch that changes this behavior. The comment looks correct to me, so I did not update it. However, I may be confused by the meaning of "local address"... See below. >But I'd also consider the possibility that it is wrong for the compiler >to expect a GOTOFF-accessible FD, when the FD is only expected to be >created at run time by the DL. > >A protected symbol is visible by name outside its loadable object, so >other objects may refer to it and get a dynamic linker-created function >descriptor that needs to be the canonical one for that symbol. Which >implies that the relocation to the function descriptor cannot be at a >link-time constant GOT offset. > >OTOH, it might seem to make sense to create a local noncanonical FD for >the locally-bound function, to be used only to call the function rather >than as the function address, like a non-canonical PLT entry, but then, >if it's only for local calls, we don't need a FD for calls, we could >just call the function directly. > > >But the quoted C testcase above makes it clear that what is expected is >indeed the canonical function descriptor, so I think this patch is >papering over a bug in the compiler, that should be generating code to >load the canonical FD address from the GOT rather than assuming the >canonical FD is local to the module just because the symbol binds >locally. > > >Am I making any sense? I have some notes about the protected visibility at https://maskray.me/blog/2021-01-09-copy-relocations-canonical-plt-entries-and-protected#stv_protected There were some old x86 discussions around GCC 5 and GNU ld 2.26. The gist is that people use protected visibility for performance. The use case is typically about -fvisibility=protected that applies to definitions, serving as a superior alternative to -Wl,-Bsymbolic. If taking the address of a protected visibility symbol uses GOT-indirect addressing in -fpic mode (GCC flag_shlib), as slow as the default visibility, then there would be no point to use the protected visibility in the first place. (Therefore, I don't know what purpose `local_protected==0` serves. I think all ports should just use 1.) There have been some debates what to do when copy relocations/canonical PLT entries are used together with protected symbol. gold, lld, and certain BFD ports' interpretation is that copy relocations are simply incompatible with protected visibility. Thankfully, FDPIC codegen just forces PIC and avoids copy relocations. I think __attribute__((visibility("protected"))) is for a definition within a component, not for a cross-DSO API. Let's say a.so defines protected `foo`, which is referenced by b.so using the default visibility symbol. The references within a.so use GOTOFF relocations, which are resolved to the canonical function descriptor. The references from b.so use GOT relocations, which will be resolved by the dynamic loader to a.so's canonical function descriptor. Everything should just work. If b.so tries a protected undefined symbol, it will lead to a linker error. ld.bfd: a.out: protected symbol `foo' isn't defined ld.lld: error: undefined protected symbol: foo