From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8F2993858C54; Thu, 16 Nov 2023 11:36:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F2993858C54 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1700134580; bh=3+EGx+KngMaAgHLBPMCAMtko8eLAkvPCaYtF6DO/ALI=; h=From:To:Subject:Date:In-Reply-To:References:From; b=SknXJoDv2WXIjD9ngZOg90VwhGMuTqgFXYxnqB0OAOMGi8J4BS1sqv+YGFz6OfImu KWj4kdNpGNiDgg8WWlzZ9VU3GgSyUJtRKorA0LAHfJR1OgFaV5mWzzllTizDBTKfMP zPfn3DqptzXzfUhX1eLX5FckRTkMTv4muzs3yEdY= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug gdb/31070] Abnormal Jump in Execution for builtin function using 'stepi' Command in GDB Date: Thu, 16 Nov 2023 11:36:19 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: gdb X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: NOTABUG X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D31070 Tom de Vries changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|UNCONFIRMED |RESOLVED --- Comment #4 from Tom de Vries --- I can reproduce this: ... Temporary breakpoint 1, main () at small.c:10 10 __builtin_prefetch (glob_int_arr, 0, 0); (gdb) si 0x0000000000401044 in simple_global () at small.c:11 11 __builtin_prefetch (glob_ptr_int, 0, 0); (gdb) si 0x000000000040104b in main () at small.c:19 19 exit (0); (gdb) si 0x000000000040104d in simple_global () at small.c:10 10 __builtin_prefetch (glob_int_arr, 0, 0); (gdb) si 11 __builtin_prefetch (glob_ptr_int, 0, 0); ... When decoding the line numbers I see: ... small.c 11 0x401044=20=20= =20=20=20=20=20=20 small.c 19 0x40104b=20=20= =20=20=20=20=20=20 small.c 10 0x40104d=20=20= =20=20=20=20=20=20 small.c 11 0x401054=20=20= =20=20=20=20=20=20=20=20=20 ... which perfectly matches the progression we see. So gdb doesn't do anything wrong, it accurately show the line info as gener= ated by gcc. So why does the insn at 0x40104b have line number 19? The disassembly is: ... 0000000000401040
: 401040: 48 83 ec 08 sub $0x8,%rsp 401044: 48 8b 05 cd 2f 00 00 mov 0x2fcd(%rip),%rax # 404018 40104b: 31 ff xor %edi,%edi 40104d: 0f 18 05 ec 2f 00 00 prefetchnta 0x2fec(%rip) # 404040 401054: 0f 18 00 prefetchnta (%rax) 401057: e8 d4 ff ff ff call 401030 40105c: 0f 1f 40 00 nopl 0x0(%rax) ... and the call to exit is represented by these two insns: ... 40104b: 31 ff xor %edi,%edi 401057: e8 d4 ff ff ff call 401030 ... Optimization separated the two insns and that causes the "jumping" through = the lines. AFAICT, this falls in the range of expected behaviour when debugging optimi= zed code. --=20 You are receiving this mail because: You are on the CC list for the bug.=