From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id D87633858406 for ; Fri, 12 Nov 2021 07:47:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D87633858406 Received: by mail-pj1-x1032.google.com with SMTP id j6-20020a17090a588600b001a78a5ce46aso6606405pji.0 for ; Thu, 11 Nov 2021 23:47:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition; bh=0wXAFsw5Ttklf2G77wxTjlyoeljQ78OO5YEqkDwVl3M=; b=ZuAssm/W+tw1x3zojXovq06qrxDw9Kgi3wzM9dROrqFoBTUA1pyf+UgqX/z3fJ76zn zRfpXSeCD+vf5kyjrjYbP98bFhxbdOhhd40VGwWPWByI26cnIQc9Oxc0QU4mweu/vVeB 9aRc2/619+X8g60JcUq5WFCDIr8hRBt+giOq1NbPJqNVXUBJyincRngfV5jpzqpaJyXn GiDhprsdCM7AgN0JxPSBFTI3zn8kQQjc9W59SsqN3WMlvFeUHoyePRJdaP/YiNlhu172 W3Ovb9SYH2kkfQDx3YnNtIanWlblX+0AstmB4QpNSspXpKvXC0mCgXOeHU1DIpM1zgDu JA9g== X-Gm-Message-State: AOAM530tVr/gJoZR1oGrty2Q/vCweZaM8/YifDZizBT3855DFQWTT3Px NXMLyMs6JaV8J68+nEiPiccmbtuM43YVRg== X-Google-Smtp-Source: ABdhPJw//Hrx3kdVcNivXIjeDqBcW4S4lp9H1zdL22qY+j6HWgdByMGoyHjrvOQcefdx3VY8DPllCg== X-Received: by 2002:a17:902:bcc4:b0:141:bfc4:ada with SMTP id o4-20020a170902bcc400b00141bfc40adamr5973905pls.20.1636703247769; Thu, 11 Nov 2021 23:47:27 -0800 (PST) Received: from google.com ([2620:15c:2ce:200:7937:5220:60e:cdfa]) by smtp.gmail.com with ESMTPSA id ms15sm4321996pjb.26.2021.11.11.23.47.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 11 Nov 2021 23:47:27 -0800 (PST) Date: Thu, 11 Nov 2021 23:47:23 -0800 From: Fangrui Song To: Adhemerval Zanella , Carlos O'Donell , "H.J. Lu" Cc: libc-alpha@sourceware.org Subject: Can DT_RELR catch up glibc 2.35? Message-ID: <20211112074723.uvmlvihlutnib6ik@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline X-Spam-Status: No, score=-19.4 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, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no 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: Fri, 12 Nov 2021 07:47:31 -0000 I am glad that https://sourceware.org/pipermail/libc-alpha/2021-October/132029.html ("[PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924]") gets some traction and many folks acknowledge the size benefit. (On my Arch Linux, I measured 8% decrease for my /usr/bin.) There are two potential issues. 1. Lack of "Time travel compatibility" detector 2. Some folks feel that unable to test with scripts/build-many-glibcs.py is a problem. (ld.lld --pack-dyn-relocs=relr (since July 2018) is the only linker implementation and scripts/build-many-glibcs.py doesn't have an lld configuration) Let me address them for you. --- 1. "Time travel compatibility" means running a new object on an old system. A new object using DT_RELR doesn't have the R_*_RELATIVE part in .rel.dyn/.rela.dyn and is destined to crash. If the GNU ld implementation (which may take a while) adopts an undefined versioned .dynsym symbol (e.g. _dl_have_relr https://sourceware.org/pipermail/binutils/2021-October/118347.html), we can guarantee old ld.so will report an error. The undefined symbol needs to be versioned because ld -shared (default to --allow-shlib-undefined) does not error on unversioned symbols. Say GNU ld adopts something like _dl_have_relr@GLIBC_2.40 . Now it is funny as GNU ld needs to know the glibc version "GLIBC_2.40", not just the stem glibc-flavored symbol name "_dl_have_relr". There are non-Linux OSes which don't like a "_dl_have_relr" symbol name. GNU ld would have to provide options in two flavors, one with _dl_have_relr@GLIBC_2.40, one without. Among glibc systems, there are plenty of distros there which don't rigidly require a friendly diagnostic for "time traverl compatibility", e.g. I pretty sure many Gentoo Linux folks doing aggressive optimizations know that their executables don't run on old systems. An alternative to _dl_have_relr is EI_ABIVERSION. That is probably even less appealing because bumping the version locks out many ELF consumers. https://maskray.me/blog/2021-10-31-relative-relocations-and-relr#ei_abiversion In addition, I noticed that Debian ld.so 2.32 just seems to ignore EI_ABIVERSION. % r2 -wqc 'wx 22 @ 8' a; readelf -Wh a | grep ABI; ./a OS/ABI: UNIX - GNU ABI Version: 34 hello --- 2. Fetching a prebuilt llvm-project 13.0.0 which supports many Linux distros is difficult. The accessibility of ld.lld 13.0.0 is certainly nice but I wish that you don't consider it a blocker as llvm-project 13.0.0 has arrived on many distros and will arrive on others soon. Moreover, I want to emphasize that the core logic is below 30 lines. It is isolated enough and uses sufficiently few interfaces so as NOT to cause maintenance burden to other (tricky) parts of ld.so. --- I installed Gentoo Linux last weekend for fun and chatted with some Gentoo Linux folks who use -fuse-ld=lld. I am sending this message because I think I should make the feature benefit them earlier. I know some Arch/Debian Linux users are interested in the feature as well but they may have to wait longer for GNU ld (their system linker) support. I sincerely hope that the patch can catch up glibc 2.35. By making the functionality available in an older consumer, we just avoid more "time travelling compatibility" problems. Landing the consumer and the producer at about the same time is actually the bane of many compatibility problems.