From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x441.google.com (mail-wr1-x441.google.com [IPv6:2a00:1450:4864:20::441]) by sourceware.org (Postfix) with ESMTPS id 37FA8385DC0A for ; Sat, 4 Apr 2020 23:03:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 37FA8385DC0A 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-x441.google.com with SMTP id p10so12981421wrt.6 for ; Sat, 04 Apr 2020 16:03:29 -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=ahFMj72KSE4dh5tQCVSmOQOJVMdUr4QxkyEutzLuVAA=; b=Pjr1IoTOAZa9u6BQQvk4wAmw5WR9SThjLNevXcX94ThZ/KiOEw9m9OUvB7E4fRVqjV OjiJ0K1xqbdkspRBxK7Yd/bxQgKiMM7OnDSyj1qDcFjKqVFtyBsmgHFhJNKOyKs8ENtM UDqA5YmkdifdkSJxjaeG0XSbhHOvX59GpC2L6DNFA/ng3251MgkVYa5fY8pTy4ebbmUS RKfYw+cTRVpJQB02AJ5JdMEwjUWvOrj9WewN6uoIfIBWCK1vpxxJFb2mjo3VW5+ID8Hy kNwUvrWa0bsL2Joj1ONIrXcF8+5NXjbxEzu38EDn1YKQ0HIo4DDpbcldL+mPexn5tbJd T7jg== 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=ahFMj72KSE4dh5tQCVSmOQOJVMdUr4QxkyEutzLuVAA=; b=lbY5UVohqzssneoiWMr3rsbhGvUXGTkA2ArDsTdcPPEdM76fciSoYRF6tpe/MWDVoA JQSdlzxIuJS+ymmDc9V0C0fRnMiymXHosYxndSrNt/elab+jXs06my513wI/PRxGPJKI hXpmdgGeDAMc7TrDZ0r1wkvpBASLfBDxoind6uJuBxXKQDGN4liwpJvA186rXZsT3WeQ dewoobnHCBTIQYWp/DoKKPP/hFGYxMrcATIqnEn1MoAt9uVm7b/bgGuIZgKdDlNjiURj gZLjO+Ae/4QAHaFyAN0ElVitIQfheoqj2SJpirn1L4c0C0/+Il+oS0wzZEv151pc7qfQ dlnw== X-Gm-Message-State: AGi0PuaQRG5hF4FChUMlGh2HO9J911T2uh9FzOObyvbQjzixpw7yx6mr okvJs3yc26ksfJzKyrRLgC6HAw== X-Google-Smtp-Source: APiQypJrAM8ghJ4ZIjvFJv0AgMaInOwln+B8qauwc0CpIYTgTpzGigLguPZRbIvaQWvUwzOla722tw== X-Received: by 2002:a5d:5510:: with SMTP id b16mr14223092wrv.355.1586041408301; Sat, 04 Apr 2020 16:03:28 -0700 (PDT) Received: from localhost (host86-186-80-207.range86-186.btcentralplus.com. [86.186.80.207]) by smtp.gmail.com with ESMTPSA id o129sm9576931wma.20.2020.04.04.16.03.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Apr 2020 16:03:27 -0700 (PDT) Date: Sun, 5 Apr 2020 00:03:27 +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: <20200404230327.GD3917@embecosm.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux/5.5.13-200.fc31.x86_64 (x86_64) X-Uptime: 00:00:53 up 7:04, 1 X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] X-Spam-Status: No, score=-25.7 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: Sat, 04 Apr 2020 23:03:31 -0000 * 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. 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