From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id C0877388A825 for ; Tue, 2 Jun 2020 09:08:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C0877388A825 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2F47CAC7F; Tue, 2 Jun 2020 09:08:31 +0000 (UTC) Subject: Re: [RFC][PATCH 0/6] Step program considering the source column information To: Hannes Domani , Gdb-patches References: <20200516172632.4803-1-ssbssa.ref@yahoo.de> <20200516172632.4803-1-ssbssa@yahoo.de> <56760df2-b642-c112-2a16-89320a2fba0e@suse.de> <1062200567.878277.1590595459490@mail.yahoo.com> From: Tom de Vries Autocrypt: addr=tdevries@suse.de; keydata= xsBNBF0ltCcBCADDhsUnMMdEXiHFfqJdXeRvgqSEUxLCy/pHek88ALuFnPTICTwkf4g7uSR7 HvOFUoUyu8oP5mNb4VZHy3Xy8KRZGaQuaOHNhZAT1xaVo6kxjswUi3vYgGJhFMiLuIHdApoc u5f7UbV+egYVxmkvVLSqsVD4pUgHeSoAcIlm3blZ1sDKviJCwaHxDQkVmSsGXImaAU+ViJ5l CwkvyiiIifWD2SoOuFexZyZ7RUddLosgsO0npVUYbl6dEMq2a5ijGF6/rBs1m3nAoIgpXk6P TCKlSWVW6OCneTaKM5C387972qREtiArTakRQIpvDJuiR2soGfdeJ6igGA1FZjU+IsM5ABEB AAHNH1RvbSBkZSBWcmllcyA8dGRldnJpZXNAc3VzZS5kZT7CwKsEEwEIAD4WIQSsnSe5hKbL MK1mGmjuhV2rbOJEoAUCXSW0JwIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAh CRDuhV2rbOJEoBYhBKydJ7mEpsswrWYaaO6FXats4kSgc48H/Ra2lq5p3dHsrlQLqM7N68Fo eRDf3PMevXyMlrCYDGLVncQwMw3O/AkousktXKQ42DPJh65zoXB22yUt8m0g12xkLax98KFJ 5NyUloa6HflLl+wQL/uZjIdNUQaHQLw3HKwRMVi4l0/Jh/TygYG1Dtm8I4o708JS4y8GQxoQ UL0z1OM9hyM3gI2WVTTyprsBHy2EjMOu/2Xpod95pF8f90zBLajy6qXEnxlcsqreMaqmkzKn 3KTZpWRxNAS/IH3FbGQ+3RpWkNGSJpwfEMVCeyK5a1n7yt1podd1ajY5mA1jcaUmGppqx827 8TqyteNe1B/pbiUt2L/WhnTgW1NC1QDOwE0EXSW0JwEIAM99H34Bu4MKM7HDJVt864MXbx7B 1M93wVlpJ7Uq+XDFD0A0hIal028j+h6jA6bhzWto4RUfDl/9mn1StngNVFovvwtfzbamp6+W pKHZm9X5YvlIwCx131kTxCNDcF+/adRW4n8CU3pZWYmNVqhMUiPLxElA6QhXTtVBh1RkjCZQ Kmbd1szvcOfaD8s+tJABJzNZsmO2hVuFwkDrRN8Jgrh92a+yHQPd9+RybW2l7sJv26nkUH5Z 5s84P6894ebgimcprJdAkjJTgprl1nhgvptU5M9Uv85Pferoh2groQEAtRPlCGrZ2/2qVNe9 XJfSYbiyedvApWcJs5DOByTaKkcAEQEAAcLAkwQYAQgAJhYhBKydJ7mEpsswrWYaaO6FXats 4kSgBQJdJbQnAhsMBQkDwmcAACEJEO6FXats4kSgFiEErJ0nuYSmyzCtZhpo7oVdq2ziRKD3 twf7BAQBZ8TqR812zKAD7biOnWIJ0McV72PFBxmLIHp24UVe0ZogtYMxSWKLg3csh0yLVwc7 H3vldzJ9AoK3Qxp0Q6K/rDOeUy3HMqewQGcqrsRRh0NXDIQk5CgSrZslPe47qIbe3O7ik/MC q31FNIAQJPmKXX25B115MMzkSKlv4udfx7KdyxHrTSkwWZArLQiEZj5KG4cCKhIoMygPTA3U yGaIvI/BGOtHZ7bEBVUCFDFfOWJ26IOCoPnSVUvKPEOH9dv+sNy7jyBsP5QxeTqwxC/1ZtNS DUCSFQjqA6bEGwM22dP8OUY6SC94x1G81A9/xbtm9LQxKm0EiDH8KBMLfQ== Message-ID: <874427bb-b86d-a4d1-4971-b5b40d91741b@suse.de> Date: Tue, 2 Jun 2020 11:08:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <1062200567.878277.1590595459490@mail.yahoo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.4 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_SHORT, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Tue, 02 Jun 2020 09:08:31 -0000 On 27-05-2020 18:04, Hannes Domani via Gdb-patches wrote: > Am Mittwoch, 27. Mai 2020, 17:33:37 MESZ hat Tom de Vries Folgendes geschrieben: > >> On 16-05-2020 19:26, Hannes Domani via Gdb-patches wrote: >>> Basically, this implements the new commands nextc (nc) and stepc (sc), >>> which allow to step through the program until an instruction is reached, >>> that belongs to another source column (according to the debug information). >>> >>> The current column location is visualized in the frame info, and in the TUI. >>> >>> Also, the column information is added to 'maint info line-table' and the >>> python line table interface. >>> >>> Since the frame info output is different, this certainly breaks the >>> testsuite, so this column indicator needs a parameter to disable, but I >>> wasn't concerned about this yet. >>> >>> With the example code from PR25913, it looks like this: >>> >>> (gdb) start >>> Temporary breakpoint 2 at 0x40162d: file gdb-25911.c, line 4. >>> Starting program: C:\src\tests\gdb-25911.exe >>> >>> Temporary breakpoint 2, main () at gdb-25911.c:4 >>> 4        int a = 4; >>>               ^ >>> (gdb) nc >>> 6        a = 5; a = 6; a = 7; >>>             ^ >>> (gdb) nc >>> 6        a = 5; a = 6; a = 7; >>>                     ^ >>> (gdb) nc >>> 6        a = 5; a = 6; a = 7; >>>                           ^ >>> (gdb) nc >>> 8        return 0; >>> >>> >>> What do you think of this so far? >>> >> >> Very nice :) >> >> As I've just learned by looking at this ( >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95360 ) PR, interesting >> code in relation to this patch series is dwarf_record_line_p. >> >> The function implements filtering of line-table elements, and has as >> related test-case gdb.dwarf2/dw2-single-line-discriminators.exp. >> >> If we disable the filtering (by returning 1 at the end instead of 0), we >> get for test-case gdb.dwarf2/dw2-single-line-discriminators.exp: >> ... >> Temporary breakpoint 2, main () at >> gdb.dwarf2/dw2-single-line-discriminators.c:26 >> 26        x = 0; >> (gdb) n >> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */ >> (gdb) si >> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */ >> ... >> >> That is: no progress is visible after the stepi.  If we re-enable the >> filtering, we have: >> ... >> Temporary breakpoint 1, main () at >> gdb.dwarf2/dw2-single-line-discriminators.c:26 >> 26        x = 0; >> (gdb) n >> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */ >> (gdb) si >> 0x00000000004004cd      28        for (i = 0; i < 10; ++i) continue; /* >> stepi line */ >> ... >> >> So, progress is visible. >> >> If we now use your patch series, and with the filtering enabled, we have: >> ... >> Temporary breakpoint 1, main () at >> gdb.dwarf2/dw2-single-line-discriminators.c:26 >> 26        x = 0; >>            ^ >> (gdb) n >> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */ >>                ^ >> (gdb) si >> 0x00000000004004cd      28        for (i = 0; i < 10; ++i) continue; /* >> stepi line */ >>                                        ^ >> (gdb) >> 0x00000000004004d1      28        for (i = 0; i < 10; ++i) continue; /* >> stepi line */ >>                                        ^ >> (gdb) >> 0x00000000004004d3      28        for (i = 0; i < 10; ++i) continue; /* >> stepi line */ >>                                        ^ >> (gdb) >> 0x00000000004004d5      28        for (i = 0; i < 10; ++i) continue; /* >> stepi line */ >>                                        ^ >> ... >> >> So, we see progress in the insn addresses, but the column does not progress. >> >> OTOH, if we disable filtering: >> ... >> Temporary breakpoint 1, main () at >> gdb.dwarf2/dw2-single-line-discriminators.c:26 >> 26        x = 0; >>            ^ >> (gdb) n >> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */ >>                ^ >> (gdb) si >> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */ >>                ^ >> (gdb) si >> 0x00000000004004d1      28        for (i = 0; i < 10; ++i) continue; /* >> stepi line */ >>                                        ^ >> (gdb) si >> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */ >>                                    ^ >> (gdb) si >> 28        for (i = 0; i < 10; ++i) continue; /* stepi line */ >>                                ^ >> (gdb) si >> 0x00000000004004d8      28        for (i = 0; i < 10; ++i) continue; /* >> stepi line */ >>                                                        ^ >> ... >> we don't see progress after the first stepi, but eventually we do see >> progress in the column. >> >> Looking at the line-info: >> ... >>    [0x00000147]  Set column to 8 >>    [0x00000149]  Special opcode 161: advance Address by 11 to 0x4004c6 >> and Line by 2 to 28 >>    [0x0000014a]  Extended opcode 4: set Discriminator to 4 >>    [0x0000014e]  Special opcode 103: advance Address by 7 to 0x4004cd and >> Line by 0 to 28 >> ... >> perhaps we we should collapse entries that have the same column, so >> something like this in dwarf_record_line_p: >> ... >>    if (line != last_line) >>      return 1; >>    if (colum != last_column) >>      return 1; >> >>    return 0; >> >> ... > Sorry for the late reply, I didn't notice this earlier (not on To/CC list for some reason). > Interesting. > I'm just wondering, if dwarf_record_line_p merges all entries of the same line, > why does my column-based stepping even work at all? > > Is it because of line_has_non_zero_discriminator? Yes. ( See also https://sourceware.org/bugzilla/show_bug.cgi?id=17276 ). > If yes, what is the discriminator? DWARF 4 standard, 6.2.2 State Machine Registers : ... An unsigned integer identifying the block to which the current instruction belongs. Discriminator values are assigned arbitrarily by the DWARF producer and serve to distinguish among multiple blocks that may all be associated with the same source file, line, and column. Where only one lock exists for a given source position, the discriminator value should be zero. ... Thanks, - Tom