On Wed, Aug 24, 2022 at 3:54 PM <crash-utility-request@redhat.com> wrote:
Date: Wed, 24 Aug 2022 12:10:35 +0800
From: Tao Liu <ltao@redhat.com>
To: crash-utility@redhat.com
Subject: [Crash-utility] [PATCH 2/2] x86_64: Correct the identifier
        when locating the call instruction
Message-ID: <20220824041033.40559-2-ltao@redhat.com>
Content-Type: text/plain; charset="US-ASCII"; x-default=true

The previous implementation to locate the call instruction is
to strstr "call", then check whether the previous char is ' '
or '\t'. The implementation is problematic. For example it
cannot resolve the following disassembly string:

"0xffffffffc06e6399 <nfs_callback_up+118>:\tcall   0xffffffff9ac8792f <printk>"

strstr will locate the "_call" and char check fails,
as a result, extract_hex fail to get the calling address.


This looks like a potential corner bug. Did you see if it can be reproduced without the [PATCH 1/2]? 
 
Thanks.
Lianbo

This patch fix the issue by strstr "\tcall" and " call", to
locate the correct call instruction.

Signed-off-by: Tao Liu <ltao@redhat.com>
---
 x86_64.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/x86_64.c b/x86_64.c
index dfada48..74bd1bb 100644
--- a/x86_64.c
+++ b/x86_64.c
@@ -4432,8 +4432,7 @@ x86_64_function_called_by(ulong rip)
        if (gdb_pass_through(buf, pc->tmpfile2, GNU_RETURN_ON_ERROR)) {
                rewind(pc->tmpfile2);
                while (fgets(buf, BUFSIZE, pc->tmpfile2)) {
-                       if ((p1 = strstr(buf, "call")) &&
-                           whitespace(*(p1-1))) {
+                       if ((p1 = strstr(buf, " call")) || (p1 = strstr(buf, "\tcall"))) {
                                if (extract_hex(p1, &value, NULLCHAR, TRUE))
                                        break;
                        }
--
2.33.1