From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23828 invoked by alias); 11 Oct 2011 16:46:58 -0000 Received: (qmail 23805 invoked by uid 22791); 11 Oct 2011 16:46:55 -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 16:46:39 +0000 Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p9BGkcD3031068 for ; Tue, 11 Oct 2011 09:46:38 -0700 Received: from qap1 (qap1.prod.google.com [10.224.4.1]) by hpaq13.eem.corp.google.com with ESMTP id p9BGhnfr028247 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 11 Oct 2011 09:46:36 -0700 Received: by qap1 with SMTP id 1so13866104qap.8 for ; Tue, 11 Oct 2011 09:46:36 -0700 (PDT) Received: by 10.224.181.146 with SMTP id by18mr9700818qab.3.1318351596728; Tue, 11 Oct 2011 09:46:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.181.146 with SMTP id by18mr9700794qab.3.1318351596511; Tue, 11 Oct 2011 09:46:36 -0700 (PDT) Received: by 10.224.80.149 with HTTP; Tue, 11 Oct 2011 09:46:36 -0700 (PDT) In-Reply-To: <201110111217.21689.pedro@codesourcery.com> References: <20111011061636.GR3802@adacore.com> <201110111217.21689.pedro@codesourcery.com> Date: Tue, 11 Oct 2011 16:46: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/msg00059.txt.bz2 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. =A0However, 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. =A0Users 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). Even if that case required several commands, as long as it was robustly scriptable that would be fine. We should be optimizing for the common case. > 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. > Maybe what we need a `warning' so that the surprise is gone: > > =A0"warning: assuming process is running the loaded executable `FOO' > =A0which is different from the executable the target reports the process " > =A0is running. =A0Unload it with the `file' command to make gdb find and = load > =A0the target reported executable automatically." A warning is needed, but it doesn't correct the broken default behaviour (IMO, YMMV). It's too bad we don't have a formal mechanism for deprecating and ultimately deleting broken command behaviour, API elements, etc. [I wonder how much pushback there would be to introducing one. I don't know if I'd ultimately want to incompatibly change GDB in this particular case, but I do know there are changes I've wanted to make that break compatibility.] 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). We could add an option to attach (attach -f PID, or whatever) that explicitly set the file, overriding what's currently in effect. > ( 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. :-)