From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 0044C3858D39 for ; Sun, 26 Dec 2021 13:29:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0044C3858D39 Received: by mail-lj1-x22a.google.com with SMTP id s4so3474390ljd.5 for ; Sun, 26 Dec 2021 05:29:25 -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:from:date:message-id:subject:to; bh=ybVcNsWr7TL56Iocvo//qK8qZ4T97JKt5VkCz5GD/sE=; b=xp1qvjz2EQ+LKaHY+8HsZ5gAqI3ncPUmvuK0XHguBaZjCmmqsIcux/ICwlk3LJIQuK Ce0ufmLvU/EZsheMQIb90AJyJ/yDZPDPvSD9ly0b4FsMCUw2kbWcbiMEnA4JF9sauIjF PmyGIWGTOyaFtO7TJRqY8AluDNQea4npzo4pRbavlc+FRHPMCjDS6h+d+K2WgArk2MC/ MUf38/66OLEeT1vDsz5Vh7ub9vWPin2i/BhV1P8ekNaW3NKgLaWRhHV2yeW9iSn1kV7n ycbEqWfcO7PHGP3dRNjJsY+2O3xBseR7mEZq19gXiPSW71zui2YzL/5tDQ/fG0KkbIVF irug== X-Gm-Message-State: AOAM532IZsR/0tuV2gl63gk6XHI9VWOwz4tAUoN/t5zs90pw6U8nPQaQ plc3Qo5x0uRq15BYTjB77OPTJ6C8DUq1Hpey8YH9IoIkMeV07Q== X-Google-Smtp-Source: ABdhPJxUzlzPea70UqtfgMUJGjk6l0UcfWgZswfxPMvd84L1bq8RX6ujyWOc0D+ywuvgr1tnHc6fuJjGd5bl8nIl8ao= X-Received: by 2002:a2e:8045:: with SMTP id p5mr4872455ljg.127.1640525364337; Sun, 26 Dec 2021 05:29:24 -0800 (PST) MIME-Version: 1.0 From: Fengkai Sun Date: Sun, 26 Dec 2021 21:29:13 +0800 Message-ID: Subject: CHECK_STATIC_TLS in R_X86_64_TPOFF64 type relocation To: libc-help@sourceware.org X-Spam-Status: No, score=-0.1 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: Sun, 26 Dec 2021 13:29:27 -0000 Hi list, I noticed that when resolving R_X86_64_TPOFF64 type relocations, the runtime dynamic linker would call the macro CHECK_STATIC_TLS, which can be expanded into a call to _dl_try_allocate_static_tls. (in sysdeps/x86_64/dl-machine.h) The comments of _dl_try_allocate_static_tls says: > 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. Since glibc has refused to dlopen PIEs since 2.29, why does it not see it as an error, but still try to allocate static TLS for PIEs? --- Thanks, Fengkai