From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61388 invoked by alias); 2 Sep 2017 06:28:46 -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 61378 invoked by uid 89); 2 Sep 2017 06:28:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=itd X-HELO: mail-lf0-f47.google.com Received: from mail-lf0-f47.google.com (HELO mail-lf0-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 02 Sep 2017 06:28:40 +0000 Received: by mail-lf0-f47.google.com with SMTP id g18so6775909lfl.2 for ; Fri, 01 Sep 2017 23:28:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sSsPbLDN2VFH9XVGtpw5iCg7iNk1ETCEUE4RRzrxWq0=; b=BLlys7mnUqc4IKG4c29Eysh3wuFjMkIKTLzLcMRP9JOIikkzWiza4RGApmrCD2BCC8 /cefkCVU5hd/8Wc1TdoD06zoNH9luyTITQ0LNqWYR7quo1EJRjkmArYZltL7RpK0raxS HZ9+AYq9BiHyqRXGz8o+xl+j9QkT6ZBZJwZNiONRE6IaQPOsL+JYpi5ntUPN2AZ7dNYR obl4nV6DNZ0NC/8fjdi7LkV6o3MneALJwkopIkqNUnlwLHAB/jyplSpwihBdczvp7oaP fHPKlvweQbtzI6vFcHl78r1NP+voRpeAn390WvgIm4iQrrBJYqUYcPPXmNHZ+3NpePth SwQg== X-Gm-Message-State: AHPjjUj8ZL3RtMhN512NXSMw8JLIOA3dQhFevYQHm7A9yHsZlwBlYmhq Eqxhjy/Xt7FrN+3TeYSVrH3ChSxbRQ== X-Google-Smtp-Source: ADKCNb6MjkwegIykbGf7ogHY8iZbbmfxoagS+YBTjEKZDS5gOhItNoppAsboDuIKbYsQDB1UTVKvynem319hgyjuj7I= X-Received: by 10.25.147.147 with SMTP id w19mr1417747lfk.171.1504333717778; Fri, 01 Sep 2017 23:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.20.77 with HTTP; Fri, 1 Sep 2017 23:28:37 -0700 (PDT) In-Reply-To: <2289243.bE5E4p8koA@ralph.baldwin.cx> References: <20170829225457.66096-1-jhb@FreeBSD.org> <645c49bd-86fb-88c8-e22c-3613a72f2be7@redhat.com> <2289243.bE5E4p8koA@ralph.baldwin.cx> From: Ruslan Kabatsayev Date: Sat, 02 Sep 2017 06:28:00 -0000 Message-ID: Subject: Re: [PATCH] Add a 'starti' command. To: John Baldwin Cc: Pedro Alves , gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00012.txt.bz2 Hello John, On 2 September 2017 at 00:42, John Baldwin wrote: > 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. > Dunno if this helps, but you might want to check what happens inside GDB when you start an inferior as gdb -ex 'b *0' -ex run /path/to/program In this case GDB fails to set the breakpoint (due to invalid access to address 0x0), and the `run` command stops exactly at the first instruction. If we get `starti` to work using a similar mechanism, I think it'd be just enough on the implementation side, no need for any "normal" breakpoints. >> 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 Regards, Ruslan