From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23452 invoked by alias); 11 Oct 2011 18:11:57 -0000 Received: (qmail 23431 invoked by uid 22791); 11 Oct 2011 18:11:51 -0000 X-SWARE-Spam-Status: No, hits=-2.1 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 18:11:28 +0000 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p9BIBMqG001390 for ; Tue, 11 Oct 2011 11:11:22 -0700 Received: from qadb15 (qadb15.prod.google.com [10.224.32.79]) by wpaz5.hot.corp.google.com with ESMTP id p9BI9DMi013822 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 11 Oct 2011 11:11:21 -0700 Received: by qadb15 with SMTP id b15so13459554qad.1 for ; Tue, 11 Oct 2011 11:11:21 -0700 (PDT) Received: by 10.224.194.5 with SMTP id dw5mr15593547qab.16.1318356681552; Tue, 11 Oct 2011 11:11:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.194.5 with SMTP id dw5mr15593526qab.16.1318356681385; Tue, 11 Oct 2011 11:11:21 -0700 (PDT) Received: by 10.224.80.149 with HTTP; Tue, 11 Oct 2011 11:11:21 -0700 (PDT) In-Reply-To: <201110111820.06906.pedro@codesourcery.com> References: <201110111217.21689.pedro@codesourcery.com> <201110111820.06906.pedro@codesourcery.com> Date: Tue, 11 Oct 2011 18:11: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-System-Of-Record: true 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/msg00061.txt.bz2 On Tue, Oct 11, 2011 at 10:20 AM, Pedro Alves wrot= e: >> 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. [I hate needing to be verbose just to avoid such things, it implies a community in need of some, umm, love. :-) But maybe better word choices would help.] >> We should be optimizing for the common case. > > Yadayada... =A0:-) > >> > and "file FOO; attach PID" is the idiom GDB uses since forever for tha= t. >> >> 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. :-) >=A0Sometimes we can't > avoid it, but stateless things are easier to grok. Yadayada ...? 1/2 :-) > Maybe GDB could > print a note when it loaded the executable automatically? > > "Note: Hello, hello! =A0This is GDB speaking. =A0How 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. =A0So I've hopefully helpfully asked the target > backend which it was, and loaded it automatically for you. =A0How > cool is that, huh?!? =A0Beware that I won't do this again until > you unload the executable. =A0Happy debugging! > > Yours, > -- > G.D.B." > > Might need copy editing too. =A0:-) > >> 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? I don't understand. >> 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. "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. Awesome.