All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Sahil Gupta <s.gupta@arista.com>
Cc: linux-trace-kernel@vger.kernel.org,
	Dmitry Safonov <dima@arista.com>,
	Kevin Mitchell <kevmitch@arista.com>,
	stable@vger.kernel.org
Subject: Re: ftrace: sorttable unable to sort ELF64 on 32-bit host
Date: Tue, 6 Jan 2026 12:21:45 -0500	[thread overview]
Message-ID: <20260106122145.42e4ec09@gandalf.local.home> (raw)
In-Reply-To: <CABEuK16m+msavH79AZxTRSqOsS5MQmOnsZZ8tZuKY5WWwz3bFw@mail.gmail.com>

On Thu, 20 Mar 2025 17:02:06 -0500
Sahil Gupta <s.gupta@arista.com> wrote:

> Hi Steven,

Hi,

Sorry for the really late reply. I'm cleaning out my inbox and just noticed
this email.

> 
> On 6.12.0, sorttable is unable to sort 64-bit ELFs on 32-bit hosts
> because of the parsing of the start_mcount_loc and stop_mcount_loc
> values in get_mcount_loc():
> 
>   *_start = strtoul(start_buff, NULL, 16);
> 
> and
> 
>  *_stop = strtoul(stop_buff, NULL, 16);
> 
> This code makes the (often correct) assumption that the host and the
> target have the same architecture, however it runs into issues when
> compiling for a 64-bit target on a 32-bit host, as unsigned long is
> shorter than the pointer width. As a result, I've noticed that both
> start and stop max out at 2^32 - 1.
> 
> It seems that commit 4acda8ed fixes this issue inadvertently by
> directly extracting them from the ELF using the correct width. I'm
> wondering if it is possible to backport this as well as the other
> sorttable refactors to 6.12.0 since they fix this issue.

I think this is a good reason to mark that commit as stable and backport it
to 6.12.

-- Steve

  reply	other threads:[~2026-01-06 17:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-20 22:02 ftrace: sorttable unable to sort ELF64 on 32-bit host Sahil Gupta
2026-01-06 17:21 ` Steven Rostedt [this message]
2026-01-06 17:39   ` Sahil Gupta
     [not found] <CABEuK15=+Bo7xkBn5ufytVowt0j3fVEsdGVsryn1zH8KxfoCyQ@mail.gmail.com>
2025-03-24 17:36 ` Steven Rostedt
2025-03-24 18:39   ` Sahil Gupta
2025-03-24 18:52     ` Greg KH
2025-03-24 19:07       ` Steven Rostedt
2025-03-25 11:58         ` Greg KH
2025-03-25 12:15           ` Steven Rostedt
2025-03-25 17:52             ` Sahil Gupta
2025-03-25 18:02               ` Steven Rostedt
2025-03-25 18:10                 ` Sahil Gupta
2025-03-25 18:19                   ` Steven Rostedt
2025-03-25 18:23                     ` Sahil Gupta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260106122145.42e4ec09@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=dima@arista.com \
    --cc=kevmitch@arista.com \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=s.gupta@arista.com \
    --cc=stable@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.