From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22091 invoked by alias); 20 Jun 2014 14:42:42 -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 21972 invoked by uid 89); 20 Jun 2014 14:42:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 20 Jun 2014 14:42:38 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s5KEgZNI004898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 20 Jun 2014 10:42:36 -0400 Received: from barimba (ovpn-113-103.phx2.redhat.com [10.3.113.103]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s5KEgY9Z020769 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 20 Jun 2014 10:42:35 -0400 From: Tom Tromey To: Phil Muldoon Cc: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: (Doc ping [for news and manual]) -- [PATCH 14/14] the "compile" command References: <1400253995-12333-1-git-send-email-tromey@redhat.com> <1400253995-12333-15-git-send-email-tromey@redhat.com> <539EBEF2.5010703@redhat.com> <83ha3kvpv5.fsf@gnu.org> <53A3FC20.4030408@redhat.com> <837g4bsys6.fsf@gnu.org> <53A40662.60708@redhat.com> Date: Fri, 20 Jun 2014 14:42:00 -0000 In-Reply-To: <53A40662.60708@redhat.com> (Phil Muldoon's message of "Fri, 20 Jun 2014 11:01:06 +0100") Message-ID: <871tujabhh.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2014-06/txt/msg00751.txt.bz2 Eli> That's not what I meant. Suppose I have 2 compilers installed, one Eli> called 'gcc', the other 'gcc472'. (They could also be in different Eli> directories, even not on PATH.) The program I'm debugging was Eli> compiled with gcc472. How will GDB know to invoke that executable? Eli> Also, how would it know the command-line arguments required to produce Eli> a code that will work well with the rest of the program being debugged Eli> (the code I compile can call functions in the program, right?)? Phil> Tom could maybe answer this better. There was recent work on the GCC Phil> triplet and PATH searching over on GCC for the plugin. Yes, the new version searches the path for something matching the correct GNU configury triplet. See the gcc patch series for details. Eli> But GDB knows how to access registers regardless of the language. Why Eli> cannot the compiled code use those facilities? It sounds like a Eli> limitation, especially when the program being debugged was compiled Eli> with optimizations. It's a limitation. We didn't add any gdb C parser extensions to gcc. We've discussed it but haven't decided on whether to pursue it yet. Tom