From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68323 invoked by alias); 20 Jun 2019 01:11:50 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 68313 invoked by uid 89); 20 Jun 2019 01:11:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=Stops, kevin, UD:symtab.c, symtabc X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Jun 2019 01:11:49 +0000 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DDD7F308427C; Thu, 20 Jun 2019 01:11:47 +0000 (UTC) Received: from f29-4.lan (ovpn-117-224.phx2.redhat.com [10.3.117.224]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B5F3D19C5B; Thu, 20 Jun 2019 01:11:47 +0000 (UTC) Date: Thu, 20 Jun 2019 01:11:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Andrew Burgess Subject: Re: [PATCH] gdb: Don't skip prologue for explicit line breakpoints in assembler Message-ID: <20190619181147.69974f43@f29-4.lan> In-Reply-To: <20190612123403.14348-1-andrew.burgess@embecosm.com> References: <20190612123403.14348-1-andrew.burgess@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00397.txt.bz2 On Wed, 12 Jun 2019 13:34:03 +0100 Andrew Burgess wrote: > It was observed that in some cases, placing a breakpoint in an > assembler file using filename:line-number syntax would result in the > breakpoint being placed at a different line within the file. > > For example, consider this x86-64 assembler: > > test: > push %rbp /* Break here. */ > mov %rsp, %rbp > nop /* Stops here. */ > > The user places the breakpoint using file:line notation targeting the > line marked 'Break here', GDB actually stops at the line marked 'Stops > here'. > > The reason is that the label 'test' is identified as the likely start > of a function, and the call to symtab.c:skip_prologue_sal causes GDB > to skip forward over the instructions that GDB believes to be part of > the prologue. > > I believe however, that when debugging assembler code, where the user > has instruction-by-instruction visibility, if they ask for a specific > line, GDB should (as far as possible) stop on that line, and not > perform any prologue skipping. I don't believe that the behaviour of > higher level languages should change, in these cases skipping the > prologue seems like the correct thing to do. I agree with all of this. > In order to implement this change I needed to extend our current > tracking of when the user has requested an explicit line number. We > already tracked this in some cases, but not in others (see the changes > in linespec.c). However, once I did this I started to see some > additional failures (in tests gdb.base/break-include.exp > gdb.base/ending-run.exp gdb.mi/mi-break.exp gdb.mi/mi-reverse.exp > gdb.mi/mi-simplerun.exp) where we currently expected a breakpoint > placed at one file and line number to be updated to reference a > different line number, this was fixed by removing some code in > symtab.c:skip_prologue_sal. My concern here is that removing this > check didn't cause anything else to fail. Did you investigate the reason for the failures with this hunk left in place?... > @@ -3812,12 +3821,6 @@ skip_prologue_sal (struct symtab_and_line *sal) > > sal->pc = pc; > sal->section = section; > - > - /* Unless the explicit_line flag was set, update the SAL line > - and symtab to correspond to the modified PC location. */ > - if (sal->explicit_line) > - return; > - > sal->symt> FAIL: gdb.base/break-include.exp: break break-include.c:53 ab = start_sal.symtab; > sal->line = start_sal.line; > sal->end = start_sal.end; The rest of the patch looks fine to me. Deleting those lines might be okay also, but I'd like to understand why adding additional explicit line number tracking caused these failures: FAIL: gdb.base/break-include.exp: break break-include.c:53 FAIL: gdb.base/ending-run.exp: Cleared 2 by line FAIL: gdb.base/ending-run.exp: clear 2 by default Kevin