From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80103 invoked by alias); 1 Sep 2017 21:42:38 -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 80093 invoked by uid 89); 1 Sep 2017 21:42:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=HX-Greylist:AUTH, HX-Greylist:succeeded, HX-Greylist:SMTP, H*M:ralph X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Sep 2017 21:42:31 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id D353110AF07; Fri, 1 Sep 2017 17:42:29 -0400 (EDT) From: John Baldwin To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Add a 'starti' command. Date: Fri, 01 Sep 2017 21:42:00 -0000 Message-ID: <2289243.bE5E4p8koA@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <645c49bd-86fb-88c8-e22c-3613a72f2be7@redhat.com> References: <20170829225457.66096-1-jhb@FreeBSD.org> <645c49bd-86fb-88c8-e22c-3613a72f2be7@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00010.txt.bz2 On Thursday, August 31, 2017 11:51:33 PM Pedro Alves wrote: > Hi John, > > On 08/30/2017 12:54 AM, John Baldwin wrote: > > This works like 'start' but it stops at the first instruction rather than > > the first line in main(). This is useful if one wants to single step > > through runtime linker startup. > > I like the idea. I actually once wrote a patch quite similar to this. > I had called the command "create", inspired by "target_create_inferior". > Is there a reason to actually set a breakpoint at the first instruction and > run to it, actually? My old prototype just created the inferior and > didn't resume it all, see: > > https://github.com/palves/gdb/commits/create_command > > though maybe going through normal_stop may be a good idea. I tried this today and ended up with gdb hung in poll() but not printing a prompt or accepting commands still, so I've left it as a breakpoint. > I agree with Keith - this should really have some tests. > > For example: > > - write a global constructor that sets a flag, and then check > that the flag is still clear when we're still at the entry point. > This can be either a C++ test or a C test using > __attribute__ ((constructor))- > > - After creating the inferior, check that you can manually set > a break on main, and continue to it. I've created a test which does these two (will send a v2 in a minute). > - Try backtrace, and check that only one frame comes > out. That may expose buggy unwinders that don't stop > unwinding at the entry point currently, but then that > should be fixed anyway, since users will run into that > too. This one didn't work out for me on either FreeBSD or a CentOS 7 VM. I know for the FreeBSD case the initial entry point in the runtime linker doesn't have any CFI directives that would aid in unwinding, and that might be true for ld.so on Linux as well. FreeBSD: (gdb) starti Starting program: /bin/ls Temporary breakpoint 1 at 0x800609650: file /usr/src/libexec/rtld-elf/amd64/rtld_start.S, line 33. Temporary breakpoint 1, .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:33 33 xorq %rbp,%rbp # Clear frame pointer for good form (gdb) where #0 .rtld_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:33 #1 0x0000000000000001 in ?? () #2 0x00007fffffffe648 in ?? () #3 0x0000000000000000 in ?? () CentOS 7: (gdb) starti Starting program: /usr/bin/ls Temporary breakpoint 1 at 0x7ffff7ddd170 Temporary breakpoint 1, 0x00007ffff7ddd170 in _start () from /lib64/ld-linux-x86-64.so.2 (gdb) where #0 0x00007ffff7ddd170 in _start () from /lib64/ld-linux-x86-64.so.2 #1 0x0000000000000001 in ?? () #2 0x00007fffffffe6ac in ?? () #3 0x0000000000000000 in ?? () -- John Baldwin