From nobody Thu Apr 11 13:42:47 2024 X-Original-To: freebsd-questions@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VFgqx3jMJz5HRYP for ; Thu, 11 Apr 2024 13:42:53 +0000 (UTC) (envelope-from alas.20073@gmail.com) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VFgqw5XQLz3x9r for ; Thu, 11 Apr 2024 13:42:52 +0000 (UTC) (envelope-from alas.20073@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20230601 header.b=nF7IaQaU; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of alas.20073@gmail.com designates 2a00:1450:4864:20::129 as permitted sender) smtp.mailfrom=alas.20073@gmail.com Received: by mail-lf1-x129.google.com with SMTP id 2adb3069b0e04-516d6c1e238so6984001e87.2 for ; Thu, 11 Apr 2024 06:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712842971; x=1713447771; darn=freebsd.org; h=content-transfer-encoding:in-reply-to:content-language:references :to:from:subject:user-agent:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=QPbn+ye2JX334HKHOMaZFE8/ARa/CMdFalcDopbHnXI=; b=nF7IaQaUh7Uq8+T9+84dhjhhPmIcGUAlRvM2LPkdnp2JFOKn3IDUfZeLKFPbyWISOw pHbyYJeu6UBPCVv9z//+cqC51qxPNOMVXj6TI0bZFUtqppXpMZGMAzo9rvfu4DAdHGaH csD790TTf094MgSBxnHci+lVAq0bVVGPf0OyiNxqpp//oMivvAp9Zqu1TcMlryZZafgq MaRTieYTAn/zwGEaVdmNbyozbRJ+QHheDc+QoswyVIVkqffyMFwbY1aoXjm0TKfDd/lw 8BWuMDvcwp0yCTjhAh1WAPv0RkVUUlLajqbhEnRqb8E7tZ+0kQfenGJbgxavdhbgj3OL XIag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712842971; x=1713447771; h=content-transfer-encoding:in-reply-to:content-language:references :to:from:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=QPbn+ye2JX334HKHOMaZFE8/ARa/CMdFalcDopbHnXI=; b=Rm5/N2UzhylegDfojIeFKxCGo7AyudHDIYSNoXtlvChFNvscsa8QM7PNF5mhHU+8VD RWIUe+jRZTyIrhnGAswuzg+SbxPLa0IPqPeQFkWKxjnnQzNpotR9NDaoKhbB7Ij4Gd7o Wwk6jYdG71IgkbjonqSyoqGHmcquRC3ZbqoarXKMgnlWMuDWVkIAUfCMSq7sI9QUZXx0 jEniBPaBIP81+Fp/ufpss1d4m04I1XQDWZgedQSNR4suhfb+Hn49gEzgvc+R45FY1RrY YrJ4mBEXmACJzHXcaHxwVeBArUN2vZ9Si5DWGM6VgOm1oI+oymsN62xGG8LPRpms7eFZ eRCA== X-Gm-Message-State: AOJu0Yw70nCnYPXqz5QhaC892eoL5a8DNtrSPDP1Uur+NM2qcchH0qFg mASlcab1Md7baLD8pD/9AXM0rkwmlfHneGDIE5niY7LZWUY3OY6yqkKIxA== X-Google-Smtp-Source: AGHT+IG7zwrA8mUVw23/6RaizX1KeokEXZY+BKmu3B8l0xyPxrSBg8w6XINsycpEMVc1CCGs2WiTXA== X-Received: by 2002:a19:ca05:0:b0:516:c5b1:1b21 with SMTP id a5-20020a19ca05000000b00516c5b11b21mr3402777lfg.45.1712842970426; Thu, 11 Apr 2024 06:42:50 -0700 (PDT) Received: from [10.40.251.181] (pc207-181.public.smd.kcl.ac.uk. [193.61.207.181]) by smtp.gmail.com with ESMTPSA id t17-20020ac243b1000000b00515bf6ba7bdsm210397lfl.285.2024.04.11.06.42.49 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Apr 2024 06:42:50 -0700 (PDT) Message-ID: <755e1ea7-6102-450a-bf64-bc717129e4ba@gmail.com> Date: Thu, 11 Apr 2024 14:42:47 +0100 List-Id: User questions List-Archive: https://lists.freebsd.org/archives/freebsd-questions List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Questions about a symbol in `libc.so` From: Andrei Lascu To: freebsd-questions@freebsd.org References: Content-Language: en-GB In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.97 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.977]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20230601]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_DN_NONE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-questions@freebsd.org]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::129:from] X-Rspamd-Queue-Id: 4VFgqw5XQLz3x9r Hello again. Just to update my previous question, I did manage to eventually figure out where the relocation was hidden. I was aware of a number of relocation that seemed odd, and I put them on the side, thinking I might either have to figure them later, or they might just be some artifact. Well, the relocation I needed was hidden among them: Relocation section '.rela.dyn' at offset 0x2abf8 contains 2605 entries:   Offset          Info           Type           Sym. Value    Sym. Name + Addend 0000001d6888  000000000403 R_AARCH64_RELATIV 13416c 0000001d6890  000000000403 R_AARCH64_RELATIV 8b268 0000001d6898  000000000403 R_AARCH64_RELATIV 178108 0000001d68a0  000000000403 R_AARCH64_RELATIV 8b240 0000001d68a8  000000000403 R_AARCH64_RELATIV 15ac9c 0000001d68b0  000000000403 R_AARCH64_RELATIV 49b29 0000001d68c0  000000000403 R_AARCH64_RELATIV 45bfe The reason I thought them odd was because they had no symbol attached to them, just raw addressed. However, one of these offsets actually did match what the system loader was relocating against my mystery `__sdidinit`. So the solution was rather simple, ensure I relocate the addend into the offset, as there is no symbol value here, and I am on my way. There are still some odd issues here, like why are these relocations not referencing a symbol, when seemingly they should, and why it seems these resolve via `R_AARCH64_GLOB_DAT` at runtime, rather than via `R_AARCH64_RELATIVE` in `/libexec/rtld-elf/aarch64/reloc.c`, but I think as long as I am making progress, I'll let these questions get answered another time. Regards, Andrei. On 09/04/2024 12:15, Andrei Lascu wrote: > Hello. Due to certain circumstances, I am currently working on a > loader-like application for shared object files to be ran on a system > running an OS derived from FreeBSD. I've got most of the stuff working > to the level I need, but I've found something in `libc.so.7` that's > got me stumped. > > The goal is to run a test file that, among others, calls `fdopen` from > `libc.so`. Everything runs well, until line 124 in `findfp.c` is hit > (as per the source for `libc.so` in FreeBSD 14 Stable), where > `__sdidinit` is accessed. In my loader, there is no memory allocated > for this variable, because there is no relocation entry for it. Here > is where my confusion starts. > > Looking at the symbol table for `libc.so`, `__sdidinit` is a `LOCAL > DEFAULT` [1] symbol. The only way I can think of to replicate that > behaviour is to declare a variable static. However, the variable is > declared as `int __sdidinit` in `findfp.c` (and also as `extern int > __sdidinit` in `stdio/local.h`, which again, looks odd), which to me > should mean it's a `GLOBAL` symbol (unless there is some weird linking > stuff I didn't manage to hunt down during compilation). Furthermore, > running the program through the system runtime loader (and also > looking at the compiled assembly), accessing the variable seems to be > done to what I 90% believe is a GOT lookup. However, with no > relocation entry, I'm completely unsure how this is the case. > > My questions are as follows: > 1) Is it possible to access a variable via a GOT lookup when a > relocation entry does not exist? > 2) Is there some explanation as to how this variable gets `LOCAL` > binding? > 3) Is perhaps the system loader doing some special thing because it > considers `libc.so` especially, and it brings some relocation entries > from somewhere else, or has some default ones? > 4) A side question: while the symbol exists in `libc.so.7.full`, after > doing a `make buildworld`, it seems to be stripped out of `libc.so.7` > itself - I'm wondering if this is some optimization at work. > > Thanks in advance for your help, and apologies if this was the wrong > mailing list to ask. > > Regards, > Andrei. > > [1] I should mention I had a look at OpenBSD's `libc.so`, which was > the other `libc.so` that I found with this symbol. In there, the main > difference is that `__sdidinit` is `LOCAL HIDDEN`, which, if some > similar mechanism might be employed in FreeBSD, might explain 2) and > 4) above, but I'm still unsure where to look. > >