From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf44.google.com (mail-qv1-xf44.google.com [IPv6:2607:f8b0:4864:20::f44]) by sourceware.org (Postfix) with ESMTPS id E3729385DC00 for ; Fri, 3 Apr 2020 22:54:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E3729385DC00 Received: by mail-qv1-xf44.google.com with SMTP id g4so4445761qvo.12 for ; Fri, 03 Apr 2020 15:54:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=g6oczZf7n+4/vcbGDX3KUH1TLRorphys9z58TGryEbw=; b=spT9X6EPSl9qSWECUt+8PYUGR9+pk+QuuKg738A0O2jKTCQ97tW8u4WrUSJsw7fu1V f5XYpABPTxijicjGdbmsazVTu497ZTTgpKn+48UG1z4zqoapLAXutM1Ne8D7Af7L34EK 1TF9MZ0dmjkGreShm3ZKAPPTER1qnImP/UYfT74p36wYPFz01hk7hE5xfFVm6rshcsak fM9v1PHPXva/4hGRNmusPiUMn5Pp4Wx1zBY1KwcklJ60Dhbr9pRR1y6KwfqLcysCyEoJ XuuEE8oQ5tMNphnmrA/8HlU46w1ZsNZVTQ04B6aL/Yy/sgiA4jiVbGwN/HISifO+H/aK gQeg== X-Gm-Message-State: AGi0PuYXLzmqLd/x6fXsfi72tjG6EYuz1OMY2FJdjFl9EtkZJtjnQsKB yYZbxsf8U3n2qGYfxA5k6jk20KOspfo= X-Google-Smtp-Source: APiQypKpgTcZJ+7wiaTsIBRx2BM99r2+6a1/GBj9O2KKy18kP8RUQXMz8wqIHbk9mf6oOBxngoKoaQ== X-Received: by 2002:a0c:9e45:: with SMTP id z5mr10931180qve.250.1585954443312; Fri, 03 Apr 2020 15:54:03 -0700 (PDT) Received: from [192.168.0.181] ([179.185.146.158]) by smtp.gmail.com with ESMTPSA id f188sm4896367qkd.101.2020.04.03.15.54.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Apr 2020 15:54:02 -0700 (PDT) Subject: Re: [PATCH v3 2/2] Fix an undefined behavior in record_line To: Bernd Edlinger , "gdb-patches@sourceware.org" , Andrew Burgess References: From: Luis Machado Message-ID: Date: Fri, 3 Apr 2020 19:53:59 -0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-26.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: Fri, 03 Apr 2020 22:54:05 -0000 Hi, This seems to have caused a few regressions for aarch64-linux. I'm seeing the following: FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into foo from main FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into bar from foo FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of bar to foo FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into foo_cold from foo FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step into baz from foo_cold FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of baz to foo_cold FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of foo_cold to foo FAIL: gdb.dwarf2/dw2-ranges-func.exp: lo-cold: step-test-3: step out of foo to main FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into foo from main FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into bar from foo FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of bar to foo FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into foo_cold from foo FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step into baz from foo_cold FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of baz to foo_cold FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of foo_cold to foo FAIL: gdb.dwarf2/dw2-ranges-func.exp: hi-cold: step-test-3: step out of foo to main git bisect pointed at this commit: --- commit 64dc2d4bd24ff7119c913fff91184414f09b8042 Author: Bernd Edlinger Date: Thu Mar 12 11:52:34 2020 +0100 Fix an undefined behavior in record_line Additionally do not completely remove symbols at the same PC than the end marker, instead make them non-is-stmt breakpoints. 2020-04-01 Bernd Edlinger * buildsym.c (record_line): Fix undefined behavior and preserve lines at eof. --- What i see in the log is stepping through lines not working as expected. On 3/27/20 12:50 AM, Bernd Edlinger wrote: > 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. */ > 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++; >