Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <CAM7-yPTWs8J6sGjcyDrRsXu5APDHm5Kr19G500y=72=FwYCq3g@mail.gmail.com>
 <Y4C94LluYLGcf1Wt@hirez.programming.kicks-ass.net> <CAM7-yPTxgndDR+c1at+y6GngkpKz9h8cFT68cTmdRkcMuGVBQA@mail.gmail.com>
In-Reply-To: <CAM7-yPTxgndDR+c1at+y6GngkpKz9h8cFT68cTmdRkcMuGVBQA@mail.gmail.com>
From:   Yun Levi <ppbuk5246@gmail.com>
Date:   Mon, 5 Dec 2022 18:05:03 +0900
Message-ID: <CAM7-yPR3imeU_Zd5GUzv3mr8yv0SSbU58XxadroXSeidgCR-sg@mail.gmail.com>
Subject: Re: [Question] About UNWIND_HINT_ENTRY on entry_SYSCALL_64.
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        jpoimboe@kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Peter.

When I try to orc dump on vmlinux.o and vmlinux of v6.1-rc8,

I got the below result.

In case of vmlinux.o:
$ readelf -Ws vmlinux.o  | grep entry_SYSCALL_64
    153848: 0000000000000029     0 NOTYPE  GLOBAL DEFAULT   20
entry_SYSCALL_64_safe_stack
    175564: 0000000000000038     0 NOTYPE  GLOBAL DEFAULT   20
entry_SYSCALL_64_after_hwframe
    178264: 00000000000310d0    26 NOTYPE  GLOBAL DEFAULT    4
xen_entry_SYSCALL_64
    182002: 0000000000000000   407 NOTYPE  GLOBAL DEFAULT   20 entry_SYSCALL_64
$ readelf -WS vmlinux.o | grep "\[20\]"
  [20] .entry.text       PROGBITS        0000000000000000 e47d40
001a00 00  AX  0   0 64

$ ./tools/objtool/objtool --dump=orc vmlinux.o
    .entry.text+0: sp:(und) bp:(und) type:call end:1
In case of vmlinux:
$ readelf -Ws vmlinux | grep entry_SYSCALL_64
134594: ffffffff81e00029     0 NOTYPE  GLOBAL DEFAULT    1
entry_SYSCALL_64_safe_stack
156328: ffffffff81e00038     0 NOTYPE  GLOBAL DEFAULT    1
entry_SYSCALL_64_after_hwframe
159033: ffffffff81031b30    26 NOTYPE  GLOBAL DEFAULT    1 xen_entry_SYSCALL_64
162772: ffffffff81e00000   407 NOTYPE  GLOBAL DEFAULT    1 entry_SYSCALL_64

$ readelf -WS vmlinux | grep "\[ 1\]"
  [ 1] .text             PROGBITS        ffffffff81000000 200000
1002288 00  AX  0   0 4096

$ ./tools/objtool/objtool --dump=orc vmlinux
    .text+e00000: sp:sp+8 bp:(und) type:call end:0


My question is "why vmlinux binary's orc information about
entry_SYSCALL_64 is different from vmlinux.o"?
IIUC, the result of .text+e00000 should be the same to vmlinux.o's
result -- sp:(und) bp:(und) type:call end:1

Am I missing?

Thankx.


On Mon, Nov 28, 2022 at 2:31 PM Yun Levi <ppbuk5246@gmail.com> wrote:
>
> Thanks Peter and Sorry for the late answer.
>
> I got the same result on the vmlinux.o file when I compiled the recent version.
>
> But when I try to test on some of distribution version of linux, (ex)
> debian. and When I try to on vmlinux not on vmlinux.o
>
> I got some different results like below.
>
> $ readelf -Ws /usr/lib/debug/boot/vmlinux-5.18.0-0.deb11.4-amd64 |
> grep entry_SYSCALL_64
> 123448:    ffffffff81a00000 404 NOTYPE GLOBAL DEFAULT 1 entry_SYSCALL_64
>
> $ readelf -WS /usr/lib/debug/boot/vmlinux-5.18.0-0.deb11.4-amd64 | grep "\[1\]"
>   [ 1] .text             PROGBITS        ffffffff81000000 200000
> c01988 00  AX  0   0 4096
>
> 123448: ffffffff81a00000   404 NOTYPE  GLOBAL DEFAULT    1 entry_SYSCALL_64
>
>
> 123448: ffffffff81a00000   404 NOTYPE  GLOBAL DEFAULT    1 entry_SYSCALL_64
>
> $ tools/objtool/objtool --dump=orc
> /usr/lib/debug/boot/vmlinux-5.18.0-0.deb11.4-amd64 | grep
> "text+a00000"
> .text+a00000: sp:(und) bp:(und) type:call end:0
>
> Am I wrong?
>
> Thanks!
>
> On Fri, Nov 25, 2022 at 10:06 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Fri, Nov 25, 2022 at 07:41:46PM +0900, Yun Levi wrote:
> > > Hello.
> > >
> > > While I try to see the information related to ORC in vmlinux,
> > > I'm trying to find out ORC information related to entry_SYSCALL_64's address.
> > >
> > > For this, I've tried to take the following step:
> > >     1. booting the kernel with the "nokaslr" option.
> > >     2. Getting ORC information by "objdump orc dump vmlinux"
> > >     3. cat /proc/kallsyms and check the address of "entry_SYSCALL_64"
> > >           - In my kernel, It's address .text + a00000
> > >     4. Find out related ORC entry gotten in step 2.
> > >
> > > But, I couldn't find the reason why entry_SYSCALL_64's orc info isn't
> > > encoded with end =1.
> > > Instead, It was encoded as INVALID ORC entry like:
> > >
> > >   .text+a00000: sp:(und) bp:(und) type:call end:0
> > >
> > > IIUC, Some of the code is started with UNWIND_HINT_ENTRY or UNWIND_HINT_EMPTY,
> > > it should be encoded with end = 1. But it doesn't.
> > >
> > > Am I wrong?
> >
> > $ readelf -Ws defconfig-build/vmlinux.o | grep entry_SYSCALL_64
> > 178466: 0000000000000029     0 NOTYPE  GLOBAL DEFAULT   18 entry_SYSCALL_64_safe_stack
> > 188596: 0000000000000000   422 NOTYPE  GLOBAL DEFAULT   18 entry_SYSCALL_64
> > 210374: 0000000000000038     0 NOTYPE  GLOBAL DEFAULT   18 entry_SYSCALL_64_after_hwframe
> >
> > $ readelf -WS defconfig-build/vmlinux.o | grep "\[18\]"
> > [18] .entry.text       PROGBITS        0000000000000000 e59f00 001838 00  AX  0   0 64
> >
> > $ tools/objtool/objtool --dump=orc defconfig-build/vmlinux.o | grep ".entry.text+0"
> > .entry.text+0: sp:(und) bp:(und) type:call end:1
> >
> >