From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31802 invoked by alias); 11 Oct 2011 22:38:16 -0000 Received: (qmail 31521 invoked by uid 22791); 11 Oct 2011 22:38:13 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.44.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 11 Oct 2011 22:37:58 +0000 Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p9BMbudc024736 for ; Tue, 11 Oct 2011 15:37:57 -0700 Received: from qabg27 (qabg27.prod.google.com [10.224.20.219]) by hpaq14.eem.corp.google.com with ESMTP id p9BMXjGY024609 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 11 Oct 2011 15:37:56 -0700 Received: by qabg27 with SMTP id g27so217414qab.3 for ; Tue, 11 Oct 2011 15:37:55 -0700 (PDT) Received: by 10.224.194.130 with SMTP id dy2mr16270550qab.42.1318372675941; Tue, 11 Oct 2011 15:37:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.194.130 with SMTP id dy2mr16270494qab.42.1318372674352; Tue, 11 Oct 2011 15:37:54 -0700 (PDT) Received: by 10.224.80.149 with HTTP; Tue, 11 Oct 2011 15:37:54 -0700 (PDT) In-Reply-To: <201110111956.04002.pedro@codesourcery.com> References: <201110111820.06906.pedro@codesourcery.com> <201110111956.04002.pedro@codesourcery.com> Date: Tue, 11 Oct 2011 22:38:00 -0000 Message-ID: Subject: Re: attach u/i oddity From: Doug Evans To: Pedro Alves Cc: gdb@sourceware.org, Joel Brobecker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00064.txt.bz2 On Tue, Oct 11, 2011 at 11:56 AM, Pedro Alves wrot= e: > On Tuesday 11 October 2011 19:11:21, Doug Evans wrote: >> On Tue, Oct 11, 2011 at 10:20 AM, Pedro Alves w= rote: >> >> 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. =A0It's close. =A0The "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. =A0This is quite old behavior. =A0We >> > should not break things unless there's very good reason. >> >> No disagreement here. >> I'm curious what motivated inferring I was taking it lightly. > > Well, all the extra talk about deprecating and deleting commands. One should be free to talk about such things without having the listener insert things between the lines. It's a BIG step to go from simply talking about deprecating and deleting commands (*1) to taking them lightly. (*1): I actually said "ultimately deleting broken command behaviour", and by that I meant no longer supporting whatever it is that was deprecated. >> >> > 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. >> >> Yep. >> OTOH, I claim the current behaviour is already confusing. :-) >> >> > Sometimes we can't >> > avoid it, but stateless things are easier to grok. >> >> Yadayada ...? =A01/2 :-) > > ;-) > >> >> 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? >> >> Eh? =A0I don't understand. > > I don't understand what is "this" in "make this completely work" > was then. "this" can be ambiguous. :-) > I don't understand what file not having an effect on > reloading of thread_db has to do with the case we're discussing. I was pointing out that file;attach is not (currently) equivalent to attach;file. i.e. it's not enough to do attach,detach,attach, find out that the second attach didn't work as expected, and then try to fix things up by then doing "file". If "file" is a legit thing to do after an attach, then ISTM we've still got work to do. E.g., ref: http://sourceware.org/ml/gdb-patches/2011-10/msg00182.html (gdb) file wrong_executable (gdb) attach PID or core-file core.1234 whooops! (gdb) file right_executable >> >> 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. =A0But 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. =A0Also, >> >> > 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. >> >> I can't imagine not wanting the simple case of attach,detach,attach to >> Just Work. > > Your definition of "Just Work" conflicts with other use cases where > it Just Works... =A0We need to compromise while avoiding breaking > things. =A0"attach -f" (or whatever the spelling) was one way. =A0A bit > more verbosity was another. =A0Enhancing the documentation is yet another. > And none of these is mutually exclusive. > >> "But seriously ..." >> There was some cleverness that was wanted, was "tricky to get right >> right for remote targets. Also not all targets can fetch the running >> executable on attach", and yet was added anyway. =A0Awesome. > > In addition to the misunderstanding I pointed out in the other email, Like I said, "this" can be ambiguous ... > there's tons of things that some targets can't do, yet that shouldn't > block implementing the features in targets that can. Yep. > It would also be > reasonable to print something like "warning: no exec loaded, and can't > infer exec from target" for targets where we can't get it from the > target. "works for me"