From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f172.google.com (mail-pf1-f172.google.com [209.85.210.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8EC6C27FB03 for ; Wed, 17 Sep 2025 23:55:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758153323; cv=none; b=LZhL9CaoBVVzxJ/J4G3bM56t5D8r0OOjh2br2nLrRm79XvbGA8OwDLz6CQeFoRhjswu5aU2b2uMlYpF5mwZvFgiGG4osmak03KoFJ1aYv9PZbJIZ/0Yd3Gwxa3rFHFPQ4Q/aeU50dULRBFAm9FtuxU+z//JSZDUCDTr98Oa4Tnc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1758153323; c=relaxed/simple; bh=XMtT0AUEk4GbQdmZKgDHa2RmPl3wQWU77NSwGQKekHs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=PNY4tHBUW+BAi3VNr9Xh6au7J9HvcTjfu3kZx+uavwbp0gYwygMQIyAPXLNkJ3dszuvFV3nArvldqcTZDhz2TmeHn1JSgt1NRwhtF79yuu1Hz8NFyareLcQUI1xbNj4pFtp6PEhXFP8LSEoFvT/LChEUEiAoJuTGXu1bQuT0Y6Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=FyzGqzzF; arc=none smtp.client-ip=209.85.210.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="FyzGqzzF" Received: by mail-pf1-f172.google.com with SMTP id d2e1a72fcca58-77b91ed5546so372763b3a.2 for ; Wed, 17 Sep 2025 16:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758153321; x=1758758121; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=rMRjen9l/ZkuhmaroAGddCXrr34S08Oql2cHwjos3ag=; b=FyzGqzzFzFncXAnT/dZ/ehtrFhpE1CqtqGq0GhYBYw9Zz01UGCOjzWG5jpDeuHzS+b 9WHnGPi3jjNyMLasAGqpLqlg6c3fxBLRIbRb0RDqH4biUZgK7PJU2CHKNYmpLkKzLDh9 Alk74hIr5q60KZX3H7QP9kekmHTkvM1HFp7oy8u9u9KM1nWeSp+nEanjunGsmAiMccXt 2XSTuZUijHP2qHfrIj6E/fNNFQNTo1pApoZ40q6ibZc+HatUXA+BZhH8EN9/9P9DQJuX MsBBKUZ2LXZyChOAg1Qfpvv4JoQpdgC1dmK23YXirU0w+Kf+tYKRBKvRBkdsviY8oiAJ u2ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758153321; x=1758758121; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=rMRjen9l/ZkuhmaroAGddCXrr34S08Oql2cHwjos3ag=; b=jvMSJrsiVfMgWT+cP4//EMFdUHGXQ5Cs2nJWAsMxvUUha+xvc5/rvW84cXhMN6bCCW iQJHPWnH9j4RC/HNLz4Yg42iB/rmjitHtAloePIuuGifsqp7YpkWx5YU4xhvvlvPjpB0 4TyCZVqtOM3SQBfFXPPVpGisEPlQGnBz/XR763CV4GWHJcjjXVTL+2iM0smxxKlNp8qC se1sPdvAEpEJYgAJNl1gC7bva87BdcVSUWzFg4zT0X7TP57rBqw3WkuFsjMQvDqCFDLm mWhGEGq1vWcDzcDAbHj9aXymxLfPGWLzqzy4r3V8cn0CFn+4rnr/iMIgaZo5AniN1WJ1 AgiA== X-Forwarded-Encrypted: i=1; AJvYcCWlJjeGfyk4rJMR/ZTmXFTb+Xy4HHb57flfI7DWRTY5UI3qGkaXEvqNFIA++SnBs85I0SFiI65J5g+haQ+jHCfS@vger.kernel.org X-Gm-Message-State: AOJu0YzdVwdFoWaUq+OOPgcUxGfXv3qeqWS30N+PSf/D8cIUColMQzqR iXYjaNY0zrP0BfYwrHMl+McsmKOejPbCIRSbLZHwSUXqCam5N/bHaUP9 X-Gm-Gg: ASbGnctxd4WTihGS/hOfSmAchEjpbrRG6sBfZKWGSbwI9EZyjYH7hIPE11MeSJOCnwW 8N/OD/NAvdcNkhcg8oAXlZrBgMgp7KwoJrlY/DjZQvDdRRXcDl0MGkdcd/a5L46T+pJcBBpXUTN T9l+k8dOCvXIixBiUJdrfdkSNi5ZAe6Ke2L8msOgOacXkTijPUGALP4BT8jIPAzolX+r6liVmJa C6ksmwyQIqYGDqJSkXY+y3O0a8+TSXf1NtK21Xv+yuXlz312Zkaz4ODRxTFcghZh3HV4+ZjnyP/ NjjODh3F8YsNhpopLfPxwnVVctKQ82dZsmc1gu89z4naWyM2IgCg0XXZsAXhMrU0x7lvQot53Pa 9QSCCcoMkTJ4rYBR7yK8dpbRl/m6HSjoqmTVyig1cfjsNz/zIom0IfQ== X-Google-Smtp-Source: AGHT+IH+uWOYX33Fd5TDb3SpMgBJSq9JOLCwhhCmlw8qJGCZjkrC8VvasR9bJ1osvoDauxQj7VTH6g== X-Received: by 2002:a05:6a00:92a9:b0:776:8d44:7697 with SMTP id d2e1a72fcca58-77bf9562467mr4456667b3a.29.1758153320736; Wed, 17 Sep 2025 16:55:20 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:5000:67a4:d067:98d4]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-77cfec3c32fsm496200b3a.71.2025.09.17.16.55.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Sep 2025 16:55:20 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id AF8821140BDB; Thu, 18 Sep 2025 09:25:17 +0930 (ACST) Date: Thu, 18 Sep 2025 09:25:17 +0930 From: Alan Modra To: Steven Rostedt Cc: Fangrui Song , 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: 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> <20250917171251.0b421aba@gandalf.local.home> 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-Disposition: inline In-Reply-To: <20250917171251.0b421aba@gandalf.local.home> On Wed, Sep 17, 2025 at 05:12:51PM -0400, Steven Rostedt wrote: > 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. Quoting the ELF gABI: Byte e_ident[EI_DATA] specifies the encoding of both the data structures used by object file container and data contained in object file sections. > > 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. I agree. -- Alan Modra