From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) (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 7C53D18D656 for ; Wed, 17 Sep 2025 21:11:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=216.40.44.14 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758143519; cv=none; b=rU6427wkS/uyDaOsieryaSV20P6BH/BqKTCwYkA3MW/zWRmP2nf6Rc0aEu/guZ61Sw1xb3A9t3Jmd4/GBltq0WOKWfNE5kVOUvmqfDnNIZwa90L2zH158629cF7YksigD+CB1Nn00eTkMeXCAvO/VAakS0VudKPk3jTmaPSjnTM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758143519; c=relaxed/simple; bh=NL/LqGO+mwSovXRwUISy0s2llvlK8z6bSoHgLQmAus4=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=MIuFJkx1N0avNbs4W4jFHlyqFsoA3GjRxVPZvNLq29k89381PdOh4v1SYZCaFWo2PxU8Olapnar5ptqNlP6+PlK05s0gQ9BlBbn1YKpyII062aj/687EV11RG2cZyYxx2yBhklZN7fhgoqOmfcApTfl7+WfO2rcBXJ18z0VfobE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org; spf=pass smtp.mailfrom=goodmis.org; arc=none smtp.client-ip=216.40.44.14 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=goodmis.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=goodmis.org Received: from omf19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D6BC85A4AE; Wed, 17 Sep 2025 21:11:47 +0000 (UTC) Received: from [HIDDEN] (Authenticated sender: rostedt@goodmis.org) by omf19.hostedemail.com (Postfix) with ESMTPA id 7A3C720025; Wed, 17 Sep 2025 21:11:45 +0000 (UTC) Date: Wed, 17 Sep 2025 17:12:51 -0400 From: Steven Rostedt To: Fangrui Song Cc: Indu Bhagat , Jan Beulich , Rainer Orth , "linux-toolchains@vger.kernel.org" , Jens Remus , Sterling Augustine , Pavel Labath , Andrii Nakryiko , Josh Poimboeuf , Serhei Makarov , Binutils Subject: Re: Unaligned access trade-offs for SFrame FRE layout Message-ID: <20250917171251.0b421aba@gandalf.local.home> In-Reply-To: References: <9d104c46-855c-4b36-8226-1f59b59e455c@suse.com> <26895e7a-5d54-4c89-aeb4-bcd094ba081d@suse.com> <1308e9fa-90c8-4c52-b53d-afd24542b4c8@suse.com> <76b8c89e-5d80-48da-aff1-580d539d1b87@oracle.com> <20250915120742.7ff2f781@gandalf.local.home> X-Mailer: Claws Mail 3.20.0git84 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7A3C720025 X-Stat-Signature: 9q94nputtftrxseewbu9fzqobd8irc1s X-Rspamd-Server: rspamout06 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Session-ID: U2FsdGVkX1+Q/fzP17po1LxTbAqQkQ7Oi5p4E4Kx4Ks= X-HE-Tag: 1758143505-803632 X-HE-Meta: U2FsdGVkX1+yN9ewxEXezuMHsfSGofXeqX7/YhcUU53xybX8v54s1PHm7n7qfe2uZLTthHx/LiacjVfUg/F4AILhOf2+p5uAOFeBVoZDKpq237+xveIJHUXvCB1SGoh0C1+tsuGyx6EGco3nDTmVC/RLzKaU78Oz7I15ZHcIZKRwALjQVwQ+ZiVhXnRpDvD4AHw1RB2WyFMyTidVxcmg3COOO3LfuOGbFwE7M2OsQuCaM4uGJNcEDElDYYfMNgRuHC5svwi1nHpZ8EhtPe9XEzGWTkvgymhGFzEu9JiFcx/R3g+HaQ2KEYu203UPNJT640izsC4eofMVNVkbRgzgTJ4wKsMDYQIYJbFvxwGFhrv93rCfBEi0i1JHxLmueI8V On Mon, 15 Sep 2025 23:05:09 -0700 Fangrui Song wrote: > From a linker and binary utilities perspective, I'd even suggest > adopting a universal little-endian format regardless of the target > system's native endianness. > This would eliminate the need for endianness templates in the C++ code > and simplify toolchain implementation across platforms. Thinking about this more, I have some concerns with having the SFrame section being always in little endian format. 1. Is there precedent for an ELF section to be in a different endian than what the ELF file is designated as? If not, I don't think we should be adding one. 2. This moves the computation from build /link time to run time. As a kernel developer, whenever possible, if we can have longer build times for quicker runtime we go ahead and do that. 3. It makes the kernel code a bit more complicated. Basically, if we decide to have SFrames in little endian, then all big endian machines will be taking a hit at *every* stack trace! If you are doing one stack trace a millisecond, that means this hit happens 1000s of times a second. And that's for reading every item in the SFrame section. We want the stack traces to be fast as possible as they will be slowing down the application that is being profiled. Doing byte swaps will likely have a noticeable impact. I would strongly suggest keeping the SFrame values in the endian of the machine it will be running on. -- Steve