All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	<linux-kernel@vger.kernel.org>, <linuxppc-dev@lists.ozlabs.org>,
	llvm@lists.linux.dev
Subject: Re: [PATCH 2/2] recordmcount: Handle sections with no non-weak symbols
Date: Wed, 27 Apr 2022 09:54:15 -0400	[thread overview]
Message-ID: <20220427095415.594e5120@gandalf.local.home> (raw)
In-Reply-To: <1b9566f0e7185fb8fd8ef2535add7a081501ccc8.1651047542.git.naveen.n.rao@linux.vnet.ibm.com>

On Wed, 27 Apr 2022 15:01:22 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:

> If one or both of these weak functions are overridden in future, in the
> final vmlinux mcount table, references to these will change over to the
> non-weak variant which has its own mcount location entry. As such, there
> will now be two entries for these functions, both pointing to the same
> non-weak location.

But is that really true in all cases? x86 uses fentry these days, and other
archs do things differently too. But the original mcount (-pg) call
happened *after* the frame setup. That means the offset of the mcount call
would be at different offsets wrt the start of the function. If you have
one of these architectures that still use mcount, and the weak function
doesn't have the same size frame setup as the overriding function, then the
addresses will not be the same.

-- Steve


> We don't need the non-weak locations since they will
> never be executed. Ftrace skips the duplicate entries due to a previous
> commit.


WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <rostedt@goodmis.org>
To: "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>
Cc: llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>,
	linux-kernel@vger.kernel.org,
	Nathan Chancellor <nathan@kernel.org>,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/2] recordmcount: Handle sections with no non-weak symbols
Date: Wed, 27 Apr 2022 09:54:15 -0400	[thread overview]
Message-ID: <20220427095415.594e5120@gandalf.local.home> (raw)
In-Reply-To: <1b9566f0e7185fb8fd8ef2535add7a081501ccc8.1651047542.git.naveen.n.rao@linux.vnet.ibm.com>

On Wed, 27 Apr 2022 15:01:22 +0530
"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com> wrote:

> If one or both of these weak functions are overridden in future, in the
> final vmlinux mcount table, references to these will change over to the
> non-weak variant which has its own mcount location entry. As such, there
> will now be two entries for these functions, both pointing to the same
> non-weak location.

But is that really true in all cases? x86 uses fentry these days, and other
archs do things differently too. But the original mcount (-pg) call
happened *after* the frame setup. That means the offset of the mcount call
would be at different offsets wrt the start of the function. If you have
one of these architectures that still use mcount, and the weak function
doesn't have the same size frame setup as the overriding function, then the
addresses will not be the same.

-- Steve


> We don't need the non-weak locations since they will
> never be executed. Ftrace skips the duplicate entries due to a previous
> commit.


  reply	other threads:[~2022-04-27 13:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-27  9:31 [PATCH 0/2] ftrace/recordmcount: Handle object files without section symbols Naveen N. Rao
2022-04-27  9:31 ` Naveen N. Rao
2022-04-27  9:31 ` [PATCH 1/2] ftrace: Drop duplicate mcount locations Naveen N. Rao
2022-04-27  9:31   ` Naveen N. Rao
2022-04-27 13:46   ` Steven Rostedt
2022-04-27 13:46     ` Steven Rostedt
2022-04-27  9:31 ` [PATCH 2/2] recordmcount: Handle sections with no non-weak symbols Naveen N. Rao
2022-04-27  9:31   ` Naveen N. Rao
2022-04-27 13:54   ` Steven Rostedt [this message]
2022-04-27 13:54     ` Steven Rostedt
2022-04-28  7:45     ` Naveen N. Rao
2022-04-28  7:45       ` Naveen N. Rao
2022-04-28 14:06       ` Steven Rostedt
2022-04-28 14:06         ` Steven Rostedt
2022-04-28 17:24         ` Naveen N. Rao
2022-04-28 17:24           ` Naveen N. Rao
2022-04-28 17:31         ` Naveen N. Rao
2022-04-28 17:31           ` Naveen N. Rao
2022-05-02 14:44         ` Christophe Leroy
2022-05-02 14:44           ` Christophe Leroy
2022-05-02 23:52           ` Steven Rostedt
2022-05-02 23:52             ` Steven Rostedt
2022-05-03 11:20             ` Christophe Leroy
2022-05-03 11:20               ` Christophe Leroy
2022-05-03 16:25               ` Steven Rostedt
2022-05-03 16:25                 ` Steven Rostedt
2022-05-04 16:50                 ` Christophe Leroy
2022-05-04 16:50                   ` Christophe Leroy
2022-05-04 17:06                   ` Steven Rostedt
2022-05-04 17:06                     ` Steven Rostedt
2022-05-04 17:10                     ` Christophe Leroy
2022-05-04 17:10                       ` Christophe Leroy
2022-08-16 14:04 ` [PATCH 0/2] ftrace/recordmcount: Handle object files without section symbols Steven Rostedt
2022-08-16 14:04   ` Steven Rostedt
2022-08-16 17:05   ` Naveen N. Rao
2022-08-16 17:05     ` Naveen N. Rao

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=20220427095415.594e5120@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=llvm@lists.linux.dev \
    --cc=mpe@ellerman.id.au \
    --cc=nathan@kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=ndesaulniers@google.com \
    /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.