From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) by sourceware.org (Postfix) with ESMTPS id B00AF3858D3C for ; Mon, 27 Dec 2021 03:05:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B00AF3858D3C Received: by mail-lj1-x236.google.com with SMTP id h21so11770947ljh.3 for ; Sun, 26 Dec 2021 19:05:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pqcOQ7iO+lMbBXGMFxXSnPNzX67LMgL5X1ZMF4okBZs=; b=uEuezkCQV1yx4EGDAkW1ITBX82lV728qRNSzU5aYxxvV237keF6IKqSeFXzWBTr1nv JGuNalq6LD8dV8JPFuFR3ktR2IjG8mgNrIMwQCgFGfpT6zAv3/FR1EaXkXFI6d8zNgBN Z0XsfXKu/DXZVaoR/if4CWEbO6vNUZKw6wyz7/GvoBopjaisebMvkDYETrJMcqz+fEBo 9SqFpmNWJca4mAI0MgOT9C7uXDtTDe+DjJvQpMY5O8IycfeVJra9I3kUZOzLnh1G+tfR X3jndECPrqfvdfaN/Ow3I3SH2VF5y2VoJjILlmZ2H9jPOMIGOc/TSZvIdSVdme4aRzek F1PA== X-Gm-Message-State: AOAM5301V2aggLvjM8YQYPPjUkveQ7e41lGscAz82+3Q/u+RKoueqePq LvrogvSGH2yadHtXbUNemsojbN87SgssiRM922Z+bOHle9nI4g== X-Google-Smtp-Source: ABdhPJwWVQjlUYZajSpA5Rn+jEl0S0qAuD3z+xVTaIxnnamUD68PBbY688af3V+kXPLEv8iYnubXhoik6UBQw1TWlHw= X-Received: by 2002:a2e:4e09:: with SMTP id c9mr13553001ljb.372.1640574357417; Sun, 26 Dec 2021 19:05:57 -0800 (PST) MIME-Version: 1.0 References: <87wnjrjrjp.fsf@mid.deneb.enyo.de> In-Reply-To: <87wnjrjrjp.fsf@mid.deneb.enyo.de> From: Fengkai Sun Date: Mon, 27 Dec 2021 11:05:46 +0800 Message-ID: Subject: Re: CHECK_STATIC_TLS in R_X86_64_TPOFF64 type relocation To: Florian Weimer Cc: libc-help@sourceware.org X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Dec 2021 03:06:00 -0000 Hi Florian, Thanks for your reply! I figure out that dlopened DSOs could use the initial-exec model: as long as they can have access to static TLS, they are the same as DSOs introduced by the main executable. However, I am confused why (and when) the link editor emits initial-exec for DSOs, because this model is not guaranteed to work. If the TLS segment in a dlopened DSO is too large to fit in static space, it will fail the main program and the user does not have a way to fix it. In contrast, the two dynamic models always work. Sorry if this sounds deviated and like a linker-related question. --- Thanks, Fengkai On Sun, Dec 26, 2021 at 11:48 PM Florian Weimer wrote: > * Fengkai Sun via Libc-help: > > >> We are trying to perform a static TLS relocation in MAP, but it was > > dynamically loaded. > > > > To the best of my knowledge, I found that R_X86_64_TPOFF64 is for > > Initial-exec TLS model, which only appears in executables. > > No, initial-exec in shared objects is fine (as long as static TLS > space is available). > > Local-exec TLS in executables does not need relocations, and the link > editor typically relaxes initial-exec TLS reference in main programs > to local-exec TLS, leaving no of them trace (except for the PT_TLS > segment). >