From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8F1D33986816; Wed, 27 May 2020 13:07:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F1D33986816 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1590584876; bh=7lUa8TYp60gpbiIQk40p19dFDFWD2NZq53JcmtGajWQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ShLpEFWWmpqiR09C85CLXOD3vte5Wo6/O314UokrGrJmC+aeSlTuXP2Fmdj95w/1X xhlcD1QxKN6MGmiSRXO3PIkoNAXs8BP1OQtkpgVj+8ZWrkdxvs+j94Mt1lEOiUJjOI w9demF1auzfFys16GHNgpBWiGiXWw1KuSuPI+OVc= From: "vries at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug debug/95360] inconsistent behaviors at -O0 Date: Wed, 27 May 2020 13:07:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: debug X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 13:07:56 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95360 --- Comment #4 from Tom de Vries --- I compiled the test-case: ... $ gcc-10 -O0 -g small.c ... And did the stepi scenario: ... $ gdb a.out -batch -ex start $(for n in $(seq 1 7); do echo -ex si; done) Temporary breakpoint 1 at 0x400496: file small.c, line 5. Temporary breakpoint 1, main () at small.c:5 5 for (; d<1; d++) 0x00000000004004e4 5 for (; d<1; d++) 0x00000000004004ea 5 for (; d<1; d++) 0x00000000004004ec 5 for (; d<1; d++) 0x00000000004004cb 6 for (; b<1; b++) 0x00000000004004d1 6 for (; b<1; b++) 0x00000000004004d3 6 for (; b<1; b++) 7 c[b][d+1] =3D 0; ... The line table gdb uses is: ... $ gdb a.out -batch -ex start -ex "maint info line-table" Temporary breakpoint 1 at 0x400496: file small.c, line 5. Temporary breakpoint 1, main () at small.c:5 5 for (; d<1; d++) objfile: a.out ((struct objfile *) 0x2f2f520) compunit_symtab: ((struct compunit_symtab *) 0x2f618e0) symtab: small.c ((struct symtab *) 0x2f61960) linetable: ((struct linetable *) 0x2fa3ae0): INDEX LINE ADDRESS IS-STMT=20 0 4 0x0000000000400492 Y=20 1 5 0x0000000000400496 Y=20 2 7 0x0000000000400498 Y=20 3 6 0x00000000004004bc Y=20 4 5 0x00000000004004d5 Y=20 5 9 0x00000000004004ee Y=20 6 10 0x00000000004004f3 Y=20 7 END 0x00000000004004f5 Y=20 ... And indeed, the insn at 0x00000000004004cb is not a "recommended breakpoint location" in this table. However, if we look in the line number program using readelf -wl we see an entry with that address: ... [0x00000145] Special opcode 215: advance Address by 15 to 0x4004cb and L= ine by 0 to 6 ... The whole line number program looks like this: ... Line Number Statements: [0x00000111] Set column to 12 [0x00000113] Extended opcode 2: set Address to 0x400492 [0x0000011e] Special opcode 8: advance Address by 0 to 0x400492 and Line= by 3 to 4 [0x0000011f] Set column to 3 [0x00000121] Special opcode 62: advance Address by 4 to 0x400496 and Lin= e by 1 to 5 [0x00000122] Set column to 11 [0x00000124] Extended opcode 4: set Discriminator to 2 [0x00000128] Special opcode 35: advance Address by 2 to 0x400498 and Lin= e by 2 to 7 [0x00000129] Set column to 13 [0x0000012b] Extended opcode 4: set Discriminator to 2 [0x0000012f] Special opcode 89: advance Address by 6 to 0x40049e and Lin= e by 0 to 7 [0x00000130] Set column to 17 [0x00000132] Extended opcode 4: set Discriminator to 2 [0x00000136] Special opcode 131: advance Address by 9 to 0x4004a7 and Li= ne by 0 to 7 [0x00000137] Set column to 18 [0x00000139] Extended opcode 4: set Discriminator to 2 [0x0000013d] Advance PC by constant 17 to 0x4004b8 [0x0000013e] Special opcode 60: advance Address by 4 to 0x4004bc and Lin= e by -1 to 6 [0x0000013f] Set column to 13 [0x00000141] Extended opcode 4: set Discriminator to 1 [0x00000145] Special opcode 215: advance Address by 15 to 0x4004cb and L= ine by 0 to 6 [0x00000146] Set column to 5 [0x00000148] Extended opcode 4: set Discriminator to 1 [0x0000014c] Special opcode 89: advance Address by 6 to 0x4004d1 and Lin= e by 0 to 6 [0x0000014d] Set column to 16 [0x0000014f] Special opcode 60: advance Address by 4 to 0x4004d5 and Lin= e by -1 to 5 [0x00000150] Set column to 11 [0x00000152] Extended opcode 4: set Discriminator to 1 [0x00000156] Special opcode 215: advance Address by 15 to 0x4004e4 and L= ine by 0 to 5 [0x00000157] Set column to 3 [0x00000159] Extended opcode 4: set Discriminator to 1 [0x0000015d] Special opcode 89: advance Address by 6 to 0x4004ea and Lin= e by 0 to 5 [0x0000015e] Set column to 10 [0x00000160] Special opcode 65: advance Address by 4 to 0x4004ee and Lin= e by 4 to 9 [0x00000161] Set column to 1 [0x00000163] Special opcode 76: advance Address by 5 to 0x4004f3 and Lin= e by 1 to 10 [0x00000164] Advance PC by 2 to 0x4004f5 [0x00000166] Extended opcode 1: End of Sequence ... So, it seems gdb ignores the "recommended breakpoint location" at 0x4004cb, because there's an earlier one on the same line at 0x4004bc. The gdb approach is reasonable, but it could do better. It will be interesting to see how this example is handled by this ( https://sourceware.org/pipermail/gdb-patches/2020-May/168673.html ) gdb pat= ch series.=