From: Guo Ren <guoren@kernel.org>
To: yang li <yang.li85200@gmail.com>
Cc: linux-csky@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] csky: fix csky_cmpxchg_fixup not working
Date: Mon, 28 Oct 2024 10:54:05 +0800 [thread overview]
Message-ID: <CAJF2gTS0bm_PSSJrXrzaL98zeJt-nguj85Dzg6zNG6Qy_JD+Vg@mail.gmail.com> (raw)
In-Reply-To: <CA+N+=zvG62nrmz=f1n1hCztu8k=KBg24_ZZKCWbn2Bhzd7cUdQ@mail.gmail.com>
Hi yang,
On Mon, Oct 21, 2024 at 3:51 PM yang li <yang.li85200@gmail.com> wrote:
>
> Hi Guo Ren:
> In C language, your conclusion is correct, but in assembly language,
> global_symbol != &global_symbol
> I did the following experiment:
>
> liyang@liyang-virtual-machine:~/Desktop/test$ ls
> main.c test.s
> liyang@liyang-virtual-machine:~/Desktop/test$ cat test.s
>
> .globl test_symbol
> test_symbol:
> nop
> liyang@liyang-virtual-machine:~/Desktop/test$ cat main.c
> #include <stdio.h>
>
> extern unsigned long test_symbol;
> int main(void)
> {
> printf("test_symbol = 0x%lx\n",(unsigned long)test_symbol);
> printf("&test_symbol = 0x%lx\n",(unsigned long)&test_symbol);
>
> printf("main = 0x%lx\n",(unsigned long)main);
> printf("&main = 0x%lx\n",(unsigned long)&main);
> }
> liyang@liyang-virtual-machine:~/Desktop/test$ gcc main.c test.s --static -o test
> liyang@liyang-virtual-machine:~/Desktop/test$ ls
> main.c test test.s
> liyang@liyang-virtual-machine:~/Desktop/test$ readelf test -s | grep test_symbol
> 884: 000000000040170c 0 NOTYPE GLOBAL DEFAULT 7 test_symbol
> liyang@liyang-virtual-machine:~/Desktop/test$ readelf test -s | grep main -w
> 1605: 0000000000401685 135 FUNC GLOBAL DEFAULT 7 main
> liyang@liyang-virtual-machine:~/Desktop/test$ ./test
> test_symbol = 0x4b853001f0f90
> &test_symbol = 0x40170c
> main = 0x401685
> &main = 0x401685
>
> The above test can lead to the conclusion that:
> Both c_symbol and &c_symbol represent the address of a symbol, but
> &ASM_symbol represents the address of a symbol while ASM_symbol
> represents the opcode stored at that address.
>
> On Thu, Oct 17, 2024 at 2:05 PM Guo Ren <guoren@kernel.org> wrote:
> >
> > On Wed, Oct 16, 2024 at 5:56 PM Yang Li <yang.li85200@gmail.com> wrote:
> > >
> > > In the csky_cmpxchg_fixup function, it is incorrect to use the global
> > > variable csky_cmpxchg_stw to determine the address where the exception
> > > occurred.The global variable csky_cmpxchg_stw stores the opcode at the
> > > time of the exception, while &csky_cmpxchg_stw shows the address where
> > > the exception occurred.
> > >
> > > Signed-off-by: Yang Li <yang.li85200@gmail.com>
You convinced me. Applied to csky/linux-next, thanks!
> > > ---
> > > V1 -> V2:Eliminate compilation warnings
> > >
> > > arch/csky/mm/fault.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/csky/mm/fault.c b/arch/csky/mm/fault.c
> > > index a885518ce1dd..5226bc08c336 100644
> > > --- a/arch/csky/mm/fault.c
> > > +++ b/arch/csky/mm/fault.c
> > > @@ -45,8 +45,8 @@ static inline void csky_cmpxchg_fixup(struct pt_regs *regs)
> > > if (trap_no(regs) != VEC_TLBMODIFIED)
> > > return;
> > >
> > > - if (instruction_pointer(regs) == csky_cmpxchg_stw)
> > > - instruction_pointer_set(regs, csky_cmpxchg_ldw);
> > > + if (instruction_pointer(regs) == (unsigned long)&csky_cmpxchg_stw)
> > > + instruction_pointer_set(regs, (unsigned long)&csky_cmpxchg_ldw);
> > csky_cmpxchg_ldw(stw) is a label symbol, not a variable.
> >
> > arch/csky/kernel/atomic.S:
> > GLOBAL(csky_cmpxchg_ldw)
> > GLOBAL(csky_cmpxchg_stw)
> >
> > Your modification does not affect the ASM output.
> >
> > (gdb) p main
> > $1 = {void (void)} 0x5fa <main>
> > (gdb) p &main
> > $2 = (void (*)(void)) 0x5fa <main>
> >
> > > return;
> > > }
> > > #endif
> > > --
> > > 2.34.1
> > >
> >
> >
> > --
> > Best Regards
> > Guo Ren
--
Best Regards
Guo Ren
prev parent reply other threads:[~2024-10-28 2:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-08 5:46 [PATCH] csky: fix csky_cmpxchg_fixup not working Yang Li
2024-10-16 2:10 ` kernel test robot
2024-10-16 9:56 ` [PATCH v2] " Yang Li
2024-10-17 6:04 ` Guo Ren
[not found] ` <CA+N+=zu0=scmv9w7iZE2ZebxBVpvVb1eeoJ-qi=vhac-JhLthg@mail.gmail.com>
2024-10-18 8:46 ` yang li
2024-10-21 7:51 ` yang li
2024-10-28 2:54 ` Guo Ren [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=CAJF2gTS0bm_PSSJrXrzaL98zeJt-nguj85Dzg6zNG6Qy_JD+Vg@mail.gmail.com \
--to=guoren@kernel.org \
--cc=linux-csky@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=yang.li85200@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).