Message ID | 20181024090427.22721-1-alan.hayward@arm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 81245 invoked by alias); 24 Oct 2018 09:04:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 81166 invoked by uid 89); 24 Oct 2018 09:04:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.0 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, MIME_BASE64_BLANKS, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 spammy=7.2.1, 2171 X-HELO: EUR03-AM5-obe.outbound.protection.outlook.com Received: from mail-eopbgr30084.outbound.protection.outlook.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (40.107.3.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 Oct 2018 09:04:46 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I+vJJ7K/WjunmerMuVqLYaW41NpxQBNNweQM09d04EY=; b=bvyi9YSGon7PW7iyHLKwNK+aokw8DaNMw9eBAKbKpvQC2Q7LVfKOqmcAy7nI9PXrzCwkhhZzl0QCTQb/5f4vmJi0dRToipPOGo7FHOOpUmbhtx5YEoz9dPNcPCTDcOgx243YYUdAWfpLOrEbOjPXYRbKaXhrsfKpCQbX/2Bop2Y= Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com (10.172.226.148) by DB6PR0802MB2183.eurprd08.prod.outlook.com (10.172.227.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1250.30; Wed, 24 Oct 2018 09:04:38 +0000 Received: from DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::748a:5f72:2321:bc11]) by DB6PR0802MB2133.eurprd08.prod.outlook.com ([fe80::748a:5f72:2321:bc11%7]) with mapi id 15.20.1250.028; Wed, 24 Oct 2018 09:04:38 +0000 From: Alan Hayward <Alan.Hayward@arm.com> To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org> CC: nd <nd@arm.com>, Alan Hayward <Alan.Hayward@arm.com> Subject: [PATCH 1/2] Allow function prologues to have multiple repeating lines Date: Wed, 24 Oct 2018 09:04:38 +0000 Message-ID: <20181024090427.22721-1-alan.hayward@arm.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=Alan.Hayward@arm.com; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <03831AD98FA60B4FA7B3AE8FE20B86BF@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-IsSubscribed: yes |
Commit Message
Alan Hayward
Oct. 24, 2018, 9:04 a.m. UTC
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 <main>: 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 <main>: 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 <main>: 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] 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 <alan.hayward@arm.com> * symtab.c (skip_prologue_using_sal): Don't break for equal line numbers. --- gdb/symtab.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 2.17.1 (Apple Git-112)
Comments
Ping for this and part two. There was no 0/2. Thinking about it now, I probably should have said: [0/2] Fix start line for function breakpoints on Ubuntu These two patches came out of the change I made to ovldbreak.exp due to the breakpoint at main starting on the { instead of the first line. This happens only on Ubuntu. Part one is a generic fix. Part two is an addition to the fix specifically for i386/amd64. Part two also reverts the line number part of ovldbreak.exp. Fixes roughly 50 test cases for Ubuntu. Alan. > On 24 Oct 2018, at 10:04, Alan Hayward <Alan.Hayward@arm.com> 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 <main>: > 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 <main>: > 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 <main>: > 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] > > 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 <alan.hayward@arm.com> > > * 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). */ > -- > 2.17.1 (Apple Git-112) >
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 <main>: > 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 <main>: > 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 <main>: > 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 <alan.hayward@arm.com> > > * 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
> On 5 Nov 2018, at 03:50, Simon Marchi <simark@simark.ca> wrote: > > 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? Before sending, git send-email gave me a conversion warning. Normally this doesn’t happen. It gave me two options, and I let it do the default option. Looks like that wasn’t the right one. Using git send-email has fixed all the issues I used to get with odd characters. I’ll look into it if it pops up again before sending. > > 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. Yes, this does cause issues. Your test case needs updating so that it uses global vars and some stack usage (causing the 2 prologues). But when that happens, with my patch, gdb will (incorrectly) stop at the “return a” line. Looking a little more into it. This issue goes away if I use my hand built GCC on Ubuntu. It might be something to do with PIC/PIE being enabled by default on Ubuntu (although I’ve yet to re-create the issue on my hand build compiler, or found a way of removing it on the ubuntu compiler. Needs something more than -fno-pic ). I’m now in the position where I think that, with the information we are using, it is not possible to tell apart the difference between a two part prologue and the case where function name and code are on the same line. (It’s a bit clearer in the examples below). The existing GDB code is making a fairly dodgy assumption to detect the first line. But... it might be the best we can do. I’ll continue looking see if I can find a way around this or a way to cover up the issue in the testsuite. > > 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 <main>: >> 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 <main>: >> 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 <main>: >> 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? In the testsuite dir: objdump -dl outputs/gdb.cp/ovldbreak/ovldbreak Then some minor editing to replace the full paths with “Line”. And added in the missing lines - objdump skips printing the duplicated lines. (I need to double check there isn’t anything else going on here). Alternatively, I should have shown the output from gdb. I’ve added my own annotations. Ubuntu: (gdb) maint info line-table objfile: /work/alahay01/gdb-HEAD/build-aarch64/gdb/testsuite/ovldbreak ((struct objfile *) 0x3b43c1c0) compunit_symtab: ((struct compunit_symtab *) 0x3b430bc0) symtab: /work/alahay01/gdb-HEAD/src/binutils-gdb/gdb/testsuite/gdb.cp/ovldbreak.cc ((struct symtab *) 0x3b430c40) linetable: ((struct linetable *) 0x3b4b2780): INDEX LINE ADDRESS 0 45 0x0000000000400680 1 45 0x0000000000400680 2 48 0x0000000000400688 - main prologue (stack) 3 48 0x0000000000400698 - main prologue (GOT) 4 49 0x00000000004006ac - main first line 5 50 0x00000000004006b4 ... Redhat: (gdb) maint info line-table objfile: /work/alahay01/gdb-HEAD/build-aarch64/gdb/testsuite/outputs/gdb.cp/ovldbreak/ovldbreak ((struct objfile *) 0x18209660) compunit_symtab: ((struct compunit_symtab *) 0x1816cd00) symtab: /work/alahay01/gdb-HEAD/src/binutils-gdb/gdb/testsuite/gdb.cp/ovldbreak.cc ((struct symtab *) 0x1816cd80) linetable: ((struct linetable *) 0x1826e020): INDEX LINE ADDRESS 0 45 0x0000000000400670 1 45 0x0000000000400670 2 48 0x0000000000400674 - main prologue (stack) 3 49 0x0000000000400684 - main first line 4 50 0x000000000040068c ... Line 45 is another (empty) function. Line 48 is the start of main. I’ve now edited ovldbreak so that the code is: int main () { char arg2 = 2; signed char arg3 =3; So, the first line of code is now line 47. Ubuntu: (gdb) maint info line-table objfile: /work/alahay01/gdb-HEAD/build-aarch64/gdb/testsuite/outputs/gdb.cp/ovldbreak/ovldbreak ((struct objfile *) 0x2772f1c0) compunit_symtab: ((struct compunit_symtab *) 0x277328a0) symtab: /work/alahay01/gdb-HEAD/src/binutils-gdb/gdb/testsuite/gdb.cp/ovldbreak.cc ((struct symtab *) 0x27732920) linetable: ((struct linetable *) 0x277a5780): INDEX LINE ADDRESS 0 45 0x0000000000400680 1 45 0x0000000000400680 2 47 0x0000000000400688 - main prologue (stack) 3 47 0x0000000000400698 - main prologue (GOT) - No entry for first line! 4 48 0x00000000004006b4 5 49 0x00000000004006bc ... Redhat: (gdb) maint info line-table objfile: /work/alahay01/gdb-HEAD/build-aarch64/gdb/testsuite/outputs/gdb.cp/ovldbreak/ovldbreak ((struct objfile *) 0x27779660) compunit_symtab: ((struct compunit_symtab *) 0x276dcd00) symtab: /work/alahay01/gdb-HEAD/src/binutils-gdb/gdb/testsuite/gdb.cp/ovldbreak.cc ((struct symtab *) 0x276dcd80) linetable: ((struct linetable *) 0x277de020): INDEX LINE ADDRESS 0 45 0x0000000000400670 1 45 0x0000000000400670 2 47 0x0000000000400674 - main prologue (stack) 3 47 0x0000000000400684 - main first line 4 48 0x000000000040068c 5 49 0x0000000000400694 ... So, I don’t think it’s possible to tell apart the first example with the final example. > >> >> 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 <alan.hayward@arm.com> >> >> * 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
>>>>> "Alan" == Alan Hayward <Alan.Hayward@arm.com> writes:
[...]
Alan> So, I don’t think it’s possible to tell apart the first example with the final
Alan> example.
What does the DWARF look like?
Ideally I think gdb would just rely on the DWARF to mark the end of the
prologue. However, of course that can't always be done -- but I would
much rather have a blacklist of bad compilers than the current approach
of a whitelist of good ones; and I'm wondering if that is achievable at
all. Maybe doing this well would mean exposing a bit more info from the
DWARF to gdb's line table -- but that seems totally fine.
Maybe I'm really not understanding the problem, feel free to say so :)
But I'd like to understand better; my own forays into this area haven't
turned out so well.
thanks,
Tom
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). */