Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Andrew Jones <andrew.jones@linux.dev>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: kvm@vger.kernel.org, kvm-riscv@lists.infradead.org,
	 pbonzini@redhat.com, thuth@redhat.com, atishp@rivosinc.com,
	cade.richard@berkeley.edu,  jamestiotio@gmail.com
Subject: Re: [kvm-unit-tests PATCH] lib/stack: Restrengthen base_address
Date: Wed, 11 Sep 2024 10:38:10 +0200	[thread overview]
Message-ID: <20240911-e6d3f3b2e9393c66e126d8e4@orel> (raw)
In-Reply-To: <D431NLP0XYPF.F69YFSU98T2G@gmail.com>

On Wed, Sep 11, 2024 at 10:55:34AM GMT, Nicholas Piggin wrote:
> On Thu Sep 5, 2024 at 12:51 AM AEST, Andrew Jones wrote:
> > commit a1f2b0e1efd5 ("treewide: lib/stack: Make base_address arch
> > specific") made base_address() a weak function in order to allow
> > architectures to override it. Linking for EFI doesn't seem to figure
> > out the right one to use though [anymore?]. It must have worked at
> > one point because the commit calls outs EFI as the motivation.
> > Anyway, just drop the weakness in favor of another HAVE_ define.
> 
> I prefer HAVE_ style than weak so fine by me.
> 
> How is the linker not resolving it properly? Some calls still
> point to weak symbol despite non-weak symbol also existing?

Yeah, I noticed traces stopped working with EFI because it was using the
weak version of the function instead of the riscv non-weak version.
Since I'm 99% sure it used to work, then I need to find time to try and
figure out if it's something that changed in k-u-t that is now confusing
the toolchain or a toolchain regression. (It's on the TODO, but there's
lots of stuff on the TODO...)

> 
> 
> >
> > Signed-off-by: Andrew Jones <andrew.jones@linux.dev>
> > ---
> >  lib/riscv/asm/stack.h |  1 +
> >  lib/riscv/stack.c     |  2 +-
> >  lib/stack.c           | 10 ++++++----
> >  lib/stack.h           |  2 +-
> >  4 files changed, 9 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/riscv/asm/stack.h b/lib/riscv/asm/stack.h
> > index f003ca37c913..708fa4215007 100644
> > --- a/lib/riscv/asm/stack.h
> > +++ b/lib/riscv/asm/stack.h
> > @@ -8,5 +8,6 @@
> >  
> >  #define HAVE_ARCH_BACKTRACE_FRAME
> >  #define HAVE_ARCH_BACKTRACE
> > +#define HAVE_ARCH_BASE_ADDRESS
> >  
> >  #endif
> > diff --git a/lib/riscv/stack.c b/lib/riscv/stack.c
> > index 2cd7f012738b..a143c22a570a 100644
> > --- a/lib/riscv/stack.c
> > +++ b/lib/riscv/stack.c
> > @@ -5,7 +5,7 @@
> >  #ifdef CONFIG_RELOC
> >  extern char ImageBase, _text, _etext;
> >  
> > -bool arch_base_address(const void *rebased_addr, unsigned long *addr)
> > +bool base_address(const void *rebased_addr, unsigned long *addr)
> >  {
> >  	unsigned long ra = (unsigned long)rebased_addr;
> >  	unsigned long base = (unsigned long)&ImageBase;
> > diff --git a/lib/stack.c b/lib/stack.c
> > index 086fec544a81..e1c981085176 100644
> > --- a/lib/stack.c
> > +++ b/lib/stack.c
> > @@ -12,9 +12,10 @@
> >  #define MAX_DEPTH 20
> >  
> >  #ifdef CONFIG_RELOC
> > +#ifndef HAVE_ARCH_BASE_ADDRESS
> >  extern char _text, _etext;
> >  
> > -bool __attribute__((weak)) arch_base_address(const void *rebased_addr, unsigned long *addr)
> > +bool base_address(const void *rebased_addr, unsigned long *addr)
> >  {
> >  	unsigned long ra = (unsigned long)rebased_addr;
> >  	unsigned long start = (unsigned long)&_text;
> > @@ -26,8 +27,9 @@ bool __attribute__((weak)) arch_base_address(const void *rebased_addr, unsigned
> >  	*addr = ra - start;
> >  	return true;
> >  }
> > +#endif
> >  #else
> > -bool __attribute__((weak)) arch_base_address(const void *rebased_addr, unsigned long *addr)
> > +bool base_address(const void *rebased_addr, unsigned long *addr)
> >  {
> >  	*addr = (unsigned long)rebased_addr;
> >  	return true;
> 
> Shouldn't HAVE_ARCH_BASE_ADDRESS also cover this?

Yes, I suppose that would be the cleanest thing to do. And then in
lib/$ARCH/asm/stack.h we should have

#ifdef CONFIG_RELOC
#define HAVE_ARCH_BASE_ADDRESS
#endif

when the arch wants to use the implementation here (which is probably
would).

Thanks,
drew

      reply	other threads:[~2024-09-11  8:38 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-04 14:51 [kvm-unit-tests PATCH] lib/stack: Restrengthen base_address Andrew Jones
2024-09-11  0:55 ` Nicholas Piggin
2024-09-11  8:38   ` Andrew Jones [this message]

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=20240911-e6d3f3b2e9393c66e126d8e4@orel \
    --to=andrew.jones@linux.dev \
    --cc=atishp@rivosinc.com \
    --cc=cade.richard@berkeley.edu \
    --cc=jamestiotio@gmail.com \
    --cc=kvm-riscv@lists.infradead.org \
    --cc=kvm@vger.kernel.org \
    --cc=npiggin@gmail.com \
    --cc=pbonzini@redhat.com \
    --cc=thuth@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox