From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by sourceware.org (Postfix) with ESMTPS id 06E00385BF83 for ; Mon, 6 Apr 2020 17:44:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 06E00385BF83 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew.burgess@embecosm.com Received: by mail-wr1-x443.google.com with SMTP id v5so432896wrp.12 for ; Mon, 06 Apr 2020 10:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nAfWIbeikFTq3Ec6MKb1FSDSDgqWi5bsdMuFK0ZrXgA=; b=VaNkKNmJagJ5nFuCl450RClDOL9JpfEUl1NyqMSQX8kpSPtKAgbYef9sTGEU5kOAt5 zWbbrAxgYtWu6JxBOQTVYB5kD5fUr/8HTXsBsS937c781o2GtCmuKouFP6c8pqqrRmoc mppAz+fuoyI1wQVcFbGtThQHdkY1AtRJrSqKX1E+15YO2HML6ybqKJhoq1pt3jauqVVQ GeBvBEgUeNj5DpSVOhlflBoZbWI6fe4SxipE4FoBGT9qyrqmBh6IGLPtTiEPfyYFUHNU HoXXr9AHjYgMzrsYHPb352tV7cOI8wv+RtnwlT/Gvu4cGBCEjXk60KfBZ+PLUBoa+Ki9 NZ4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nAfWIbeikFTq3Ec6MKb1FSDSDgqWi5bsdMuFK0ZrXgA=; b=OIT8bq+GYc3FdIQIpDjUok3qVI2wmXOXqYlczO9ADxY4MMj1rBUjuJSWok7aNXoMTu 6DJxc5SZb9nfjHo1GQToVvh3wv6yP2Z4PIHwTo0Su+WPdtxYNJDsAKS6Api26wrnJmXB hpu6H50x8fl9DfK8tjWNhhOw89HHzWkfbZu8KHihN13YnnFBLtgKN5XrJY7K05GkJ5fP E923ysslzb/ncxcJ+VVQTsQJzdbZDNlp7+WpqKwR2uA/IwawwCAtwlyRT2SlESnp0/Bn 4EsS0WheAWKYrD+ZSvfjYfDBBzG5cvUyj3bemLcPEPd/kGvZpbeufsE89ZiYOvTblVru QMlQ== X-Gm-Message-State: AGi0PuaHMv+RFHe2lNrFYyzsn3WC/PV8jsibKf2/zKFu2ZWAnrFNWOVW 7hpv/mzuVZGOkd70+84dEqPf74CzQ5s= X-Google-Smtp-Source: APiQypKRDTR1haZGhgTFQSjv9t1JTwZOIEYw/lZxRgoBz65ACwM5DIaZyQHWS5xi3Gz10QtqnDM9zg== X-Received: by 2002:a5d:45cf:: with SMTP id b15mr345453wrs.274.1586195055105; Mon, 06 Apr 2020 10:44:15 -0700 (PDT) Received: from localhost (host81-151-181-184.range81-151.btcentralplus.com. [81.151.181.184]) by smtp.gmail.com with ESMTPSA id k184sm384678wma.13.2020.04.06.10.44.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2020 10:44:14 -0700 (PDT) Date: Mon, 6 Apr 2020 18:44:13 +0100 From: Andrew Burgess To: Bernd Edlinger Cc: "gdb-patches@sourceware.org" Subject: Re: [PATCH v3 2/2] Fix an undefined behavior in record_line Message-ID: <20200406174413.GB2524@embecosm.com> References: <20200404230327.GD3917@embecosm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200404230327.GD3917@embecosm.com> X-Operating-System: Linux/5.5.13-200.fc31.x86_64 (x86_64) X-Uptime: 18:37:39 up 10:05, 1 user, X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-25.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2020 17:44:17 -0000 * Andrew Burgess [2020-04-05 00:03:27 +0100]: > * Bernd Edlinger [2020-03-27 04:50:29 +0100]: > > > Additionally do not completely remove symbols > > at the same PC than the end marker, instead > > make them non-is-stmt breakpoints. > > > > 2020-03-27 Bernd Edlinger > > * buildsym.c (record_line): Fix undefined behavior and preserve > > lines at eof. > > --- > > gdb/buildsym.c | 34 ++++++++++++++++++---------------- > > 1 file changed, 18 insertions(+), 16 deletions(-) > > > > diff --git a/gdb/buildsym.c b/gdb/buildsym.c > > index 2d1e441..46c5bb1 100644 > > --- a/gdb/buildsym.c > > +++ b/gdb/buildsym.c > > @@ -705,27 +705,29 @@ struct blockvector * > > * sizeof (struct linetable_entry)))); > > } > > > > - /* Normally, we treat lines as unsorted. But the end of sequence > > - marker is special. We sort line markers at the same PC by line > > - number, so end of sequence markers (which have line == 0) appear > > - first. This is right if the marker ends the previous function, > > - and there is no padding before the next function. But it is > > - wrong if the previous line was empty and we are now marking a > > - switch to a different subfile. We must leave the end of sequence > > - marker at the end of this group of lines, not sort the empty line > > - to after the marker. The easiest way to accomplish this is to > > - delete any empty lines from our table, if they are followed by > > - end of sequence markers. All we lose is the ability to set > > - breakpoints at some lines which contain no instructions > > - anyway. */ > > + /* The end of sequence marker is special. We need to reset the > > + is_stmt flag on previous lines at the same PC, otherwise these > > + lines may cause problems since they might be at the same address > > + as the following function. For instance suppose a function calls > > + abort there is no reason to emit a ret after that point (no joke). > > + So the label may be at the same address where the following > > + function begins. A similar problem appears if a label is at the > > + same address where an inline function ends we cannot reliably tell > > + if this is considered part of the inline function or the calling > > + program or even the next inline function, so stack traces may > > + give surprising results. Expect gdb.cp/step-and-next-inline.exp > > + to fail if these lines are not modified here. */ > > Out of interest I tried reverting this patch and don't see any > failures in gdb.cp/step-and-next-inline.exp. Could you expand on > which tests specifically you expect to see fail, and maybe which > version of GCC you're using? I'm on 9.3.1. It'll be Monday before I > can try my other machine which has a wider selection of compiler > versions. > > I also don't understand what part of the previous behaviour was > undefined, could you help me to understand please. I reverted this patch and tested with GCC versions: 10.x - from 2020-02-05 - no regressions, 9.3.1 - (from previous) - no regressions, 9.2.0 - no regressions, 8.3.0 - no regressions, 7.4.0 - doesn't compile as the compiler doesn't support '-gstatement-frontiers.'. The 7.4.0 result seems to indicate that the test doesn't apply for compilers before then. So, what exactly does this patch fix? Or what new functionality does it bring to GDB? Or what version of GCC should I use and expect to see a difference in the test results? Thanks, Andrew > > Thanks, > Andrew > > > > > if (line == 0 && subfile->line_vector->nitems > 0) > > { > > - e = subfile->line_vector->item + subfile->line_vector->nitems - 1; > > - while (subfile->line_vector->nitems > 0 && e->pc == pc) > > + e = subfile->line_vector->item + subfile->line_vector->nitems; > > + do > > { > > e--; > > - subfile->line_vector->nitems--; > > + if (e->pc != pc || e->line == 0) > > + break; > > + e->is_stmt = 0; > > } > > + while (e > subfile->line_vector->item); > > } > > > > e = subfile->line_vector->item + subfile->line_vector->nitems++; > > -- > > 1.9.1