From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60330 invoked by alias); 5 Nov 2018 03:50:59 -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 60319 invoked by uid 89); 5 Nov 2018 03:50:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=opensuse, openSUSE, View, dig X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Nov 2018 03:50:57 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 48CCE1E0A9; Sun, 4 Nov 2018 22:50:55 -0500 (EST) Subject: Re: [PATCH 1/2] Allow function prologues to have multiple repeating lines To: Alan Hayward , "gdb-patches@sourceware.org" Cc: nd References: <20181024090427.22721-1-alan.hayward@arm.com> From: Simon Marchi Message-ID: Date: Mon, 05 Nov 2018 03:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181024090427.22721-1-alan.hayward@arm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2018-11/txt/msg00041.txt.bz2 Hi Alan, A side-note, I wasn't able to apply your patch directly, because the diff contains CRLF line terminators. I took the body of your message, which is base64-encoded (this is not an issue, git-am can deal with this) and decoded it to a file (named patch2 below). As-is, it wouldn't apply, but after passing it in dos2unix it worked fine. $ git apply patch2 error: patch failed: gdb/symtab.c:3925 error: gdb/symtab.c: patch does not apply $ file patch2 patch2: unified diff output, UTF-8 Unicode text, with CRLF line terminators $ dos2unix patch2 dos2unix: converting file patch2 to Unix format... $ file patch2 patch2: unified diff output, UTF-8 Unicode text $ git apply patch2 * works * Since you are working on a mac (according to the tail of the patch), which doesn't usually uses CRLF, I wonder how they got there. Are you able to git-am your patch directly? Anyway, comments on the actual patch: I am able to generate a somewhat similar debug info using this ugly code: int hello(int a) {int b = a + 1; return a; } int main() { return hello(2); } $ readelf --debug-dump=decodedline a.out Contents of the .debug_line section: CU: ./test.c: File name Line number Starting address View test.c 1 0x1119 test.c 1 0x1120 test.c 2 0x1129 test.c 3 0x112c ... The user code starts at 0x1120. How would the debugger know that in this case the prologue shouldn't extend up to 0x1129 (exclusive)? With your patch applied, skip_prologue_using_sal returns 0x1129. However, GDB ends up getting it right (I don't really know how and don't really have time right now to dig more): (gdb) b hello Breakpoint 1 at 0x1120: file test.c, line 1. So I'm just wondering if you see some potential problems with this. On 2018-10-24 5:04 a.m., Alan Hayward wrote: > Compiling gdb.cp/ovldbreak.cc on Ubuntu places two identical line numbers > in the function prologue. > > x86_64 Ubtunu 16.04 with GCC 5.4.0-6ubuntu1~16.04.4 > 000000000040052f
: > Line 48 > 40052f: 55 push %rbp > 400530: 48 89 e5 mov %rsp,%rbp > 400533: 53 push %rbx > 400534: 48 81 ec 88 00 00 00 sub $0x88,%rsp > Line 48 > 40053b: 64 48 8b 04 25 28 00 mov %fs:0x28,%rax > 400542: 00 00 > 400544: 48 89 45 e8 mov %rax,-0x18(%rbp) > 400548: 31 c0 xor %eax,%eax > Line 49 > 40054a: c6 45 85 02 movb $0x2,-0x7b(%rbp) > Line 50 > 40054e: c6 45 86 03 movb $0x3,-0x7a(%rbp) > etc > > Aarch64 Ubuntu 16.04 with GCC 7.2.0-1ubuntu1~16.04 > 0000000000400708
: > Line 48 > 400708: d102c3ff sub sp, sp, #0xb0 > 40070c: a9027bfd stp x29, x30, [sp,#32] > 400710: 910083fd add x29, sp, #0x20 > 400714: f9001bf3 str x19, [sp,#48] > Line 48 > 400718: 90000100 adrp x0, 420000 <_GLOBAL_OFFSET_TABLE_+0x28> > 40071c: 9100e000 add x0, x0, #0x38 > 400720: f9400001 ldr x1, [x0] > 400724: f90047a1 str x1, [x29,#136] > 400728: d2800001 mov x1, #0x0 // #0 > Line 49 > 40072c: 52800040 mov w0, #0x2 // #2 > 400730: 3900b7a0 strb w0, [x29,#45] > Line 50 > 400734: 52800060 mov w0, #0x3 // #3 > 400738: 3900bba0 strb w0, [x29,#46] > etc > > Compare to openSUSE 13.3 AArch64 with GCC 7.2.1 20171020 > > 00000000004005e4
: > Line 48 > 4005e4: d102c3ff sub sp, sp, #0xb0 > 4005e8: a9027bfd stp x29, x30, [sp, #32] > 4005ec: 910083fd add x29, sp, #0x20 > 4005f0: f9001bf3 str x19, [sp, #48] > Line 49 > 4005f4: 52800040 mov w0, #0x2 // #2 > 4005f8: 39023fa0 strb w0, [x29, #143] > Line 50 > 4005fc: 52800060 mov w0, #0x3 // #3 > 400600: 39023ba0 strb w0, [x29, #142] Just curious, did you get this output directly from using a tool, and if so which one? > > skip_prologue_using_sal () does did not allow for the case where there might > be two SALs with the same line number in a function prologue. Allow this. > > Fixes over 50 tests on Aarch64 Ubuntu. > > 2018-10-24 Alan Hayward > > * symtab.c (skip_prologue_using_sal): Don't break for equal line > numbers. > --- > gdb/symtab.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gdb/symtab.c b/gdb/symtab.c > index 2e48d6527e..67ab5d40fa 100644 > --- a/gdb/symtab.c > +++ b/gdb/symtab.c > @@ -3925,9 +3925,9 @@ skip_prologue_using_sal (struct gdbarch *gdbarch, CORE_ADDR func_addr) > sal = find_pc_line (prologue_sal.end, 0); > if (sal.line == 0) > break; > - /* Assume that a consecutive SAL for the same (or larger) > - line mark the prologue -> body transition. */ > - if (sal.line >= prologue_sal.line) > + /* Assume that a SAL to a larger line marks the prologue -> body > + transition. */ > + if (sal.line > prologue_sal.line) > break; > /* Likewise if we are in a different symtab altogether > (e.g. within a file included via #include).  */ > There is a comments just lower: /* The line number is smaller. Check that it's from the same function, not something inlined. If it's inlined, then there is no point comparing the line numbers. */ It would probably need to be updated, smaller -> smaller or equal? Simon