From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8409 invoked by alias); 11 Oct 2011 17:20:29 -0000 Received: (qmail 8387 invoked by uid 22791); 11 Oct 2011 17:20:25 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Oct 2011 17:20:11 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=EU1-MAIL.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1RDfzu-0003WK-6q from pedro_alves@mentor.com ; Tue, 11 Oct 2011 10:20:10 -0700 Received: from scottsdale.localnet ([172.16.63.104]) by EU1-MAIL.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Oct 2011 18:20:08 +0100 From: Pedro Alves To: Doug Evans Subject: Re: attach u/i oddity Date: Tue, 11 Oct 2011 17:20:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-11-generic; KDE/4.7.1; x86_64; ; ) Cc: gdb@sourceware.org, Joel Brobecker References: <201110111217.21689.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110111820.06906.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00060.txt.bz2 On Tuesday 11 October 2011 17:46:36, Doug Evans wrote: > On Tue, Oct 11, 2011 at 4:17 AM, Pedro Alves wrote: > > On Tuesday 11 October 2011 07:16:36, Joel Brobecker wrote: > >> > The user never specified forever.x32 as the program to debug, gdb was > >> > being clever. However, if it's going to be clever the first time, > >> > it's a bug (from the user's perspective) to not be clever the second > >> > time too (IMO). > >> > >> I agree. I was surprised by the reported behavior. > > > > I can't see how to change that while both keeping it simple, and > > avoiding breaking valid use cases. Users need to be able to specify a > > different executable/file than what the OS reports the process is running, > > We don't need to make this case simple though. > I'd be surprised if it was the more frequent case (or even close). Err. It's close. The "different executable" is usually the one with debug info, while the one deployed in the target/system is the one without debug info. > Even if that case required several commands, as long as it was > robustly scriptable that would be fine. I don't take it so lightly. This is quite old behavior. We should not break things unless there's very good reason. > We should be optimizing for the common case. Yadayada... :-) > > and "file FOO; attach PID" is the idiom GDB uses since forever for that. > > In this case the user explicitly specified the file. > One way to go (though I'm not entirely happy with it) would be to > continue to be clever as long as we didn't override what the user > explicitly specified. What I don't like about that, is that is adds state, that is likely to confuse users one way or another anyway. Sometimes we can't avoid it, but stateless things are easier to grok. Maybe GDB could print a note when it loaded the executable automatically? "Note: Hello, hello! This is GDB speaking. How are you? I've detected the file the process you're attaching to is running is /path/to/FOO, and that you hadn't told me which executable goes with that process. So I've hopefully helpfully asked the target backend which it was, and loaded it automatically for you. How cool is that, huh?!? Beware that I won't do this again until you unload the executable. Happy debugging! Yours, -- G.D.B." Might need copy editing too. :-) > The "file" command needs to do more to make this completely work btw. > E.g., it needs to effect a reloading of thread_db (which would fix > "gdb -c core, file foo" for the dynamic case). It's a bit unrelated, wouldn't you say? > We could add an option to attach (attach -f PID, or whatever) that > explicitly set the file, overriding what's currently in effect. That would work for me. But then again, if you know to do this, you can also do "file; attach" (or define myattach...). > > ( certainly needs copy/editing :-) ) > > > > Note this would be tricky to get right for remote targets. Also, > > not all targets can fetch the running executable on attach. > > Sure, but that didn't stop making attach be clever in the first place. :-) I can't imagine _not_ wanting it to be clever when I don't have a file loaded yet. -- Pedro Alves