From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id 7FAF9381DCDF for ; Tue, 17 Mar 2020 22:21:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7FAF9381DCDF 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-wm1-x332.google.com with SMTP id n8so1064792wmc.4 for ; Tue, 17 Mar 2020 15:21:21 -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:user-agent; bh=y8qqchBRXn+CjLPAHMV2mrR9e1Jt60/qwY4OPsZ5Hs0=; b=GTeFov7EQBz3hyOP/kCH6qzy8BeUs/DWkra5kb27VqI2mkrYXWQIyC7mKStiJnEv7w Q2/dFykD5lGv8s7h49L8S5wbNT8vjCyb2wPyOHMpMkV7v00eS3sdGW0pYCQUvW66RjME kjraeJFvvvLJquynBCHX2JngFuewYTZJRRgiKxxqscm5HwMyADU+xcRTk62fRMVaTgqv EwNRyNd23jEfPBF6CMrGcxYuNRCKsL3yEHAejmPCmQIbf194kIsLInRNxJfyNQM5FKOI 1sMm/KjT0KHzm2lrvN7bYKwUOCWG3RqG5AktKmeGsLZoyWyBbpjcHir2y5nfoF19OF+e WX1g== 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:user-agent; bh=y8qqchBRXn+CjLPAHMV2mrR9e1Jt60/qwY4OPsZ5Hs0=; b=ZzNwaBkO2PRlZ8iYfIUY5kHmwGr0Z1XYEzf5Qya+DUlwxzl72ygph4TMaaF9PR9k0G qJpy21Ee7jyYe0VQynfVJxEpoG8WkboPogRe7I3QXah7yRZRRSu/6yayxsR6dQ1nooPC HIzKVPHco+/wFyJ+w4qjgHXUS8ZC6yu1aI6dP+rTyQij7FpYJj/PQDS365i2Jl4U1JNJ u3oY04Qn0Y/oJbRUjHz3JFqQEu1ZrBZSm+e0Wa7gZeodxIdJ/TcBrXd21kvSRAHJ86/i RXvZn5RKYEyAkBZNtsbvrHFeZ78cPDp8ebMIftgSYn/zZaQ8RWdwzt/elWOeQQLwx6XQ Mj2Q== X-Gm-Message-State: ANhLgQ2B5NNR9Hnzk10Y+eZKII6q36x1IBHtGMlaOvEBC4ll3KrU4KKo MUvHqrr1rtQI3r/A9sqZETe3xQ== X-Google-Smtp-Source: ADFU+vtj5ncc7A9JezXA/s38SS8pqplhmemi3PVWiQsMIeU5cjaeo4D3FUkMGY/farpvxjci5sQhwg== X-Received: by 2002:a1c:23ca:: with SMTP id j193mr1162037wmj.111.1584483680528; Tue, 17 Mar 2020 15:21:20 -0700 (PDT) Received: from localhost (host86-180-62-221.range86-180.btcentralplus.com. [86.180.62.221]) by smtp.gmail.com with ESMTPSA id v10sm906850wml.44.2020.03.17.15.21.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 17 Mar 2020 15:21:19 -0700 (PDT) Date: Tue, 17 Mar 2020 22:21:17 +0000 From: Andrew Burgess To: Tom Tromey Cc: Bernd Edlinger , gdb-patches@sourceware.org Subject: Re: [PATCHv2 2/2] gdb: Add support for tracking the DWARF line table is-stmt field Message-ID: <20200317222117.GM3317@embecosm.com> References: <87d09c3tmu.fsf@tromey.com> <875zf34086.fsf@tromey.com> <875zf2zvpm.fsf@tromey.com> <20200317185640.GL3317@embecosm.com> <878sjyybto.fsf@tromey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878sjyybto.fsf@tromey.com> X-Operating-System: Linux/4.18.19-100.fc27.x86_64 (x86_64) X-Uptime: 21:13:15 up 32 days, 8:41, X-Fortune: I *like* the chicken X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS 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: Tue, 17 Mar 2020 22:21:22 -0000 * Tom Tromey [2020-03-17 14:18:43 -0600]: > >>>>> "Andrew" == Andrew Burgess writes: > > Andrew> + /* If the previous entry is for the same line, at the same pc, and > Andrew> + is marked as a statement, while we are trying to add a > Andrew> + non-statement, then lets just drop this new non-statement. */ > > I didn't try it yet, but I suspect it won't work, because the readelf > output up-thread showed that the 2nd r.h line was not a statement: > > File name Line number Starting address View Stmt > [...] > r.h 6 0x80000042 2 x > r.h 6 0x80000042 3 OK, but prior to the is-stmt patches GDB didn't track any non-statement line table entries, so my thinking was that previously we were spotting two sequential entries that were marked as statements. This led me to think that deleting duplicate non-statement entries would be fine. With current HEAD of GDB the line table looks like this: (gdb) maintenance info line-table objfile: /home/andrew/tmp/r.x ((struct objfile *) 0x2ac3b90) compunit_symtab: ((struct compunit_symtab *) 0x2aec530) symtab: /home/andrew/tmp/r.c ((struct symtab *) 0x2aec5b0) linetable: ((struct linetable *) 0x2b861d0): INDEX LINE ADDRESS IS-STMT 0 END 0x0000000000010150 Y 1 8 0x0000000000010154 2 END 0x0000000000010158 Y objfile: /home/andrew/tmp/r.x ((struct objfile *) 0x2ac3b90) compunit_symtab: ((struct compunit_symtab *) 0x2aec530) symtab: /home/andrew/tmp/r.h ((struct symtab *) 0x2aec5e0) linetable: ((struct linetable *) 0x2b86190): INDEX LINE ADDRESS IS-STMT 0 6 0x0000000000010150 Y 1 END 0x0000000000010154 Y If we completely remove the hunk that you identified then the line table becomes: (gdb) maintenance info line-table objfile: /home/andrew/tmp/r.x ((struct objfile *) 0x3040bd0) compunit_symtab: ((struct compunit_symtab *) 0x306d2e0) symtab: /home/andrew/tmp/r.c ((struct symtab *) 0x306d360) linetable: ((struct linetable *) 0x31012c0): INDEX LINE ADDRESS IS-STMT 0 END 0x0000000000010150 Y 1 8 0x0000000000010154 2 END 0x0000000000010158 Y objfile: /home/andrew/tmp/r.x ((struct objfile *) 0x3040bd0) compunit_symtab: ((struct compunit_symtab *) 0x306d2e0) symtab: /home/andrew/tmp/r.h ((struct symtab *) 0x306d390) linetable: ((struct linetable *) 0x3101270): INDEX LINE ADDRESS IS-STMT 0 6 0x0000000000010150 Y 1 6 0x0000000000010150 2 END 0x0000000000010154 Y Interestingly, without any of the is-stmt patches the GDB's line table looks like this: (gdb) maintenance info line-table objfile: /home/andrew/tmp/r.x ((struct objfile *) 0x15da130) compunit_symtab: ((struct compunit_symtab *) 0x15ca5c0) symtab: /home/andrew/tmp/r.c ((struct symtab *) 0x15ca640) linetable: ((struct linetable *) 0x1675df0): INDEX LINE ADDRESS 0 0 0x0000000000010150 objfile: /home/andrew/tmp/r.x ((struct objfile *) 0x15da130) compunit_symtab: ((struct compunit_symtab *) 0x15ca5c0) symtab: /home/andrew/tmp/r.h ((struct symtab *) 0x15ca680) linetable: ((struct linetable *) 0x1675dc0): INDEX LINE ADDRESS 0 6 0x0000000000010150 So what happens is we run into this bit of code in skip_prologue_using_sal: /* If there is only one sal that covers the entire function, then it is probably a single line function, like "foo(){}". */ if (prologue_sal.end >= end_pc) return 0; So, it looks like we have two different parts of the is-stmt change playing off against each other, the extra END marker is what changes the function from a single entry line table to a multi-entry one, this is what breaks thinks. Then when you remove the hunk you identified this causes the prologue skipping to spot the dual entry case and we do the right thing again. It feels like this is more luck than design. I need to revisit the code that added the extra END marker and convince myself again that this is the right thing to do I think. Hopefully I'll have an update tomorrow. Thanks, Andrew