From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta1.migadu.com (out-182.mta1.migadu.com [95.215.58.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5365B2F12DD for ; Thu, 4 Dec 2025 19:05:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764875136; cv=none; b=AlA+MdhM+D6pHjenL2Bvd4Y1I2s5Fk4Mtwsj2jLcLLskfJHMgignCnja8OBcvJ77nZGsjqnOTMfXJgSG08X5P6iYmMJ6AcalnNOaPNZBBQrO/mT+MMDI3A7DgcX3pKHzcH8WforEK7+qJaxc6QEE8us0VryInEa+Ozy3xG9zUzY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764875136; c=relaxed/simple; bh=vrRZhWSLEMc/WMLnekKX0VoTY806Bb8zLAWdWzKD1TE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kMAgXAmFu+q2Z+15EPOeyxkUmvAyc0NY0Xl2G0uVd482djGMpynk8iJ1g+RwtXcmtcX+17cdh4I8Li2YADwKOAHH8z5Iz1rsuHhRup0I5eFAXNMaCqLz+BFB0jxoXUAY851Rvzpgh01hd1rY9zuvcjzLI9JIj5enoBsYg9NONGQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=UcxlHrcg; arc=none smtp.client-ip=95.215.58.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="UcxlHrcg" Message-ID: <131b4190-9c49-4f79-a99d-c00fac97fa44@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1764875121; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Fd7z8hCbWgtDKmMPY2PrW8eDGrbySIVxu9EPmfBj/CU=; b=UcxlHrcg4l3JH/oQ5nd6CFdsy4iUXAQXOm17a65nE5VyclI0xOLUR2eEaPEDHSnxjcb8Pe /5BrEezM2yJhtcC+5SOSKA3QeFMzreRtCwuLytfQoWp/KGRtcBVYDKBZXmHYfz0doIdi7/ kkCVb1ClhCwToYF28NVw2HeiXrrtsDE= Date: Thu, 4 Dec 2025 11:04:45 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH bpf-next v2 4/4] resolve_btfids: change in-place update with raw binary output To: Eduard Zingerman , Alexei Starovoitov , Daniel Borkmann , Andrii Nakryiko , Martin KaFai Lau , Song Liu , Yonghong Song , John Fastabend , KP Singh , Stanislav Fomichev , Hao Luo , Jiri Olsa , Nathan Chancellor , Nicolas Schier , Nick Desaulniers , Bill Wendling , Justin Stitt , Alan Maguire , Donglin Peng Cc: bpf@vger.kernel.org, dwarves@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org References: <20251127185242.3954132-1-ihor.solodrai@linux.dev> <20251127185242.3954132-5-ihor.solodrai@linux.dev> <763200e4f55197da44789b97fd5379ae8bf32c08.camel@gmail.com> <79031f38-d131-4b78-982c-7ca6ab9de71e@linux.dev> <707080716569c7de7c3cb5869b67d62b55a96b68.camel@gmail.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ihor Solodrai In-Reply-To: <707080716569c7de7c3cb5869b67d62b55a96b68.camel@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 12/4/25 10:06 AM, Eduard Zingerman wrote: > On Thu, 2025-12-04 at 09:29 -0800, Ihor Solodrai wrote: > > [...] > >> Ok, it seems you're conflating two separate issues. >> >> There is a requirement to *link* .BTF section into vmlinux, because it >> must have a SHF_ALLOC flag, which makes objcopying the section data >> insufficient: linker has to do some magic under the hood. >> >> The patch doesn't change this behavior, and this was (and is) covered >> in the script comments. >> >> A separate issue is what resolve_btfids does: updates ELF in-place >> (before the patch) or outputs detached section data (after patch). >> >> The paragraph in the commit message attempted to explain the decision >> to output raw section data. And apparently I did a bad job of >> that. I'll rewrite this part it in the next revision. >> >> And I feel I should clarify that I didn't claim that libelf is buggy. >> I meant that using it is complicated, which makes resolve_btfids buggy. > > So, pahole does the following: > - elf_begin(fildes: fd, cmd: ELF_C_RDWR, ref: NULL); > - selects a section to modify and modifies it > - elf_flagdata(data: btf_data, cmd: ELF_C_SET, flags: ELF_F_DIRTY); > - elf_update(elf, cmd: ELF_C_WRITE) > - elf_end(elf) > > What exactly is complicated about that? Take a look at the resolve_btfids code that is removed in this patch, as a consequence of switching to read-only ELF. Also consider that before these changes resolve_btfids had a simple job: update data buffer of a single section, importantly, without changing its size. Now let's say we keep "update in-place" approach (which I tried to do, btw). In addition to previous .BTF_ids data update, resolve_btfids may need to either add or update .BTF section changing its size (triggering reorg of sections in ELF, depending on the flags) and add .BTF.base section. There is also a question of how to do it: do we elf_update() multiple times or try to "batch" the updates? All of this is possible, but the alternative is much simpler: ${OBJCOPY} --add-section .BTF=${ELF_FILE}.btf ${ELF_FILE} Why re-implement our own incomplete version of objcopy if we can just use it to deal with the details of the ELF update? Note also that even in pahole "add .BTF section" is implemented via llvm-objcopy call. My guess is: to avoid the headache of figuring out correct libelf usage. > > [...]