From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101205 invoked by alias); 29 Jan 2018 17:01:44 -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 101196 invoked by uid 89); 29 Jan 2018 17:01:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Jan 2018 17:01:41 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w0TH1Z0u005452 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 29 Jan 2018 12:01:40 -0500 Received: by simark.ca (Postfix, from userid 112) id 57C4D1E5BA; Mon, 29 Jan 2018 12:01:35 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 2214B1E093; Mon, 29 Jan 2018 12:01:34 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 29 Jan 2018 17:01:00 -0000 From: Simon Marchi To: Joel Brobecker Cc: Simon Marchi , gdb-patches@sourceware.org, Keith Seitz , Xavier Roirand Subject: Re: [RFA/linespec] wrong line number in breakpoint location In-Reply-To: <20180129044505.mtvh2ps464imwp2t@adacore.com> References: <1513565091-118926-1-git-send-email-brobecker@adacore.com> <20171219092405.n2dql5ji52qhjilj@adacore.com> <206d75d6b1f14e55b6a0dff523d8c722@polymtl.ca> <20171221113127.ijqv6dnzjfifwfnb@adacore.com> <20171221113214.hezwvaatnbd4yzfq@adacore.com> <5bc2ff63-7341-4000-8ec4-d56c87779c3d@ericsson.com> <20180129044505.mtvh2ps464imwp2t@adacore.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.2 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 29 Jan 2018 17:01:35 +0000 X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00604.txt.bz2 On 2018-01-28 23:45, Joel Brobecker wrote: > Hi Simon, > >> I started seeing a failure with this patch: >> >> FAIL: gdb.base/break.exp: verify that they were cleared >> >> Here is the test code: >> >> 40 int >> 41 main (int argc, char **argv, char **envp) >> 42 { >> 43 if (argc == 12345) { /* an unlikely value < 2^16, in case >> uninited */ /* set breakpoint 6 here */ >> 44 fprintf (stderr, "usage: factorial \n"); >> 45 return 1; >> 46 } >> 47 printf ("%d\n", factorial (atoi ("6"))); /* set breakpoint 1 >> here */ >> 48 /* set breakpoint 12 here */ >> 49 marker1 (); /* set breakpoint 11 here */ >> 50 marker2 (43); /* set breakpoint 20 here */ >> >> What happens is that we build a binary with optimization, set a >> breakpoint on line 47, and expect "info break" to show it at line 47. >> In reality, everything about line 47 has been inlined and there's no >> address associated to line 47. The following location in that file >> that has generated code associated to it is line 49, so that's where >> the breakpoint is placed in reality. With this patch, "info break" >> therefore now shows line 49. > > Looking at the assembly code between the two versions, the difference > is that in the GCC 5.x case, the printf called gets inlined (!), > whereas it does not when usin GCC 7.x, even on the same system. > So, in the first case, the code generated for line 47 gets > line numbers referencing either another file, or another function, > which explains why we end up breaking on the next line of code, > which is line 49. > > With the more recent version of GCC, the call to printf is no longer > inlined, and so we have some instructions "attached" to line 47, > thanks to the call to "printf". > >> This particular test isn't really about testing with optimized code, >> it's about checking if we can clear breakpoint commands. So we should >> probably test that against a non-optimized binary. > > That's true that it doesn't seem necessary to perform that check > against the optimized version. On the other hand, we could keep > the testcase as is, by simply extracting from the output of the > "break" command which line we actually broke on, and then use that > in the expected output. > > WDYT? > > gdb/testsuite/ChangeLog: > > * gdb.base/break.exp: Save the location where the breakpoint > on break.c:47 was actually inserted when debugging the version > compiled at -O2 and use it in the expected output of the "info > break" test performed soon after. > > tested on x86_64-linux, with two configurations: > - Ubuntu 16.04 with the system compiler (breakpoint lands on line 49) > - Ubuntu 16.04 with GCC 7.3.1 (breakpoint lands on line 47) Hi Joel, Thanks, this is fine with me. Just a really small nit, I would suggest initializing the line_actual variable to 0 or -1 (an invalid line number) prior to calling gdb_test_multiple. This way, if that test fails, line_actual will still be defined, and the expression that refers to it will generate a FAIL instead of an unreadable tcl backtrace. Simon