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 A3CC3386186A for ; Fri, 28 Aug 2020 16:15:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A3CC3386186A 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.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2206DB700; Fri, 28 Aug 2020 16:16:22 +0000 (UTC) Subject: Re: [PATCH][gdb/breakpoint] Handle setting breakpoint on label without address To: Pedro Alves , gdb-patches@sourceware.org References: <20200827115217.GA17450@delia.home> <23b43acc-9846-a03c-5207-3ae80efc1d6f@palves.net> <29930a75-5de9-43ed-6a24-2909eb70ec66@suse.de> <7efc1cdf-5e48-9d46-0182-6bc2318d914b@palves.net> 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: Date: Fri, 28 Aug 2020 18:15:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, 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: Fri, 28 Aug 2020 16:15:52 -0000 On 8/28/20 5:14 PM, Pedro Alves wrote: > On 8/28/20 2:53 PM, Tom de Vries wrote: > >> I see what you mean, but let's try this counter-example: >> ... >> cat -n test.c >> 1 int >> 2 main (void) >> 3 { >> 4 goto L2; >> 5 >> 6 L3: >> 7 return 0; >> 8 >> 9 L1: >> 10 (void)0; >> 11 return 1; >> 12 >> 13 L2: >> 14 goto L3; >> 15 } >> 16 >> ... >> compiled like this: >> ... >> $ gcc test.c -g >> ... >> >> With the patch, we're not able to set a breakpoint at L1, and setting >> the breakpoint at the corresponding line, line 9: >> ... >> $ gdb a.out >> Reading symbols from a.out... >> (gdb) b main:L1 >> Location main:L1 not available >> (gdb) b 9 >> Breakpoint 1 at 0x40049c: file test.c, line 14. >> (gdb) >> ... >> yields a breakpoint at line 14, a piece of code that's not reachable >> from L1. >> >> To me, label L1 and line 14 are unrelated enough to convince me to not >> do this automatically. > > Well, OK. All the code after line 7 is unreacheable. > Um, not sure what you mean here, line 13/14 is reachable. > Then using that rationale, why don't we reject a breakpoint at line 9 too? Well, I did wonder if we can somehow deduce something 'irregular' from the line table in this case and reject the breakpoint at line 9, while having the regular and helpful: ... 3 int main (void) { 4 5 i = 3; (gdb) b 4 ... still work and set a breakpoint in line 5, but I didn't manage to come up with something. So I think this is something we have to live with because the generic case is useful. > Line 14 is not reacheable from line 9 either. Can you justify the > difference in a small sentence/paragraph? > Let me try. My argument is basically is that the behaviour "this line doesn't work, let me try a different line" is simple enough for the user to follow (although arguably, we could be more verbose about it). The behaviour "this label doesn't work, let me try the corresponding line, hey the line doesn't work, let me try a different line" is too elaborate IMO. The behaviour "this label doesn't work, let me try the corresponding line, if the line works" sounds still ok to me, but I don't think it will ever be triggered. In this situation, I expect the compiler to be able to generate a label with address itself. > It would be perhaps nice if "break" accepted an option to prevent the > move-to-following-insn -- for all kinds of breakpoints -- like lldb's > "break set -m" option: > > -m ( --move-to-nearest-code ) > Move breakpoints to nearest code. If not set the target.move-to-nearest-codesetting is used. > Oh, that's interesting. In general I'm in favor of putting things which may help the user in certain situations but can backfire in others under user control. > BTW, I noticed that, setting the breakpoint at the label _after_ running > to main "works": > > Reading symbols from testsuite/outputs/gdb.base/label-without-address/label-without-address... > (gdb) b main:L1 > Location main:L1 not available > (gdb) start > Temporary breakpoint 1 at 0x1131: file testsuite/gdb.base/label-without-address.c, line 21. > Starting program: testsuite/outputs/gdb.base/label-without-address/label-without-address > > Temporary breakpoint 1, main () at testsuite/gdb.base/label-without-address.c:21 > 21 return 0; > (gdb) b main:L1 > Breakpoint 2 at 0x555555554000: file testsuite/gdb.base/label-without-address.c, line 22. > (gdb) info breakpoints > Num Type Disp Enb Address What > 2 breakpoint keep y 0x0000555555554000 main:L1 > > I see the same with your more complicated example. What's going on here? > This is what you get when you're generate a PIE. It looks like it works, but it doesn't, that breakpoint address is incorrect, you're running into PR26546, for which I submitted a patch. Thanks, - Tom