From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17922 invoked by alias); 10 Nov 2005 14:03:43 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 17856 invoked by uid 22791); 10 Nov 2005 14:03:36 -0000 Received: from zigzag.lvk.cs.msu.su (HELO zigzag.lvk.cs.msu.su) (158.250.17.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 10 Nov 2005 14:03:36 +0000 Received: from Debian-exim by zigzag.lvk.cs.msu.su with spam-scanned (Exim 4.50) id 1EaD1Z-0003zw-6o for gdb@sources.redhat.com; Thu, 10 Nov 2005 17:03:34 +0300 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by zigzag.lvk.cs.msu.su with esmtp (Exim 4.50) id 1EaD1I-0003vQ-OD; Thu, 10 Nov 2005 17:03:16 +0300 From: Vladimir Prus To: Daniel Jacobowitz Subject: Re: convenience variables in "target remote" Date: Thu, 10 Nov 2005 14:03:00 -0000 User-Agent: KMail/1.7.2 Cc: gdb@sources.redhat.com References: <20051110134340.GA21648@nevyn.them.org> In-Reply-To: <20051110134340.GA21648@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511101703.15903.ghost@cs.msu.su> X-SW-Source: 2005-11/txt/msg00218.txt.bz2 On Thursday 10 November 2005 16:43, Daniel Jacobowitz wrote: > On Thu, Nov 10, 2005 at 01:29:46PM +0300, Vladimir Prus wrote: > > Hi, > > it looks like "target remote" command does not handle convenience > > variables properly: > > > > (gdb) set $var=1234 > > (gdb) target remote :$var > > > > :$var: Connection refused. > > > > (gdb) target remote :1234 > > Remote debugging using :1234 > > > > When $var is used, it's not expanded, at gdb tries to connect to the > > wrong port? > > > > Is this by design, or a bug? > > Convenience variables are expanded in roughly the same places that the > (C) expression evaluator is used to parse expressions. That's pretty vague, I think. Does documentation say where exactly that "(C)" expression evaluator is used? If not, then guesswork is the only way to find out. > Most places > that take a number do not support them; that's by design, the full > range of expressions are not supported for ports. In fact, it seems like only literals are supported for ports. This, just like requirements that "x" command accept only literal as the number of bugs, seems like arbitrary restriction for me. Specifically, in KDevelop for remote debugging, user should provide a shell script to run program remotely, and a gdb script to connect to a program. The gdb script can just containg "target remote somehost:1234". But I don't think it's unreasonable for two people to remotely debug program on the same box. So, port should not be hardcoded. I though about using convenience variables to pass port number from "run program" script to "connect to target" gdb script, but due to above limitation, this is not possible. So, I should have shell script that will be given port number and will produce the set of gdb commands to connect to the target. Another level of scripting just to overcome arbitrary restriction in gdb. Or is there some indirect way to use variable in "target remote" command? - Volodya