From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27544 invoked by alias); 27 Feb 2003 20:11:19 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 27534 invoked from network); 27 Feb 2003 20:11:18 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by 172.16.49.205 with SMTP; 27 Feb 2003 20:11:18 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3/8.9.3) with ESMTP id OAA18648; Thu, 27 Feb 2003 14:58:56 -0500 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id PAA23053; Thu, 27 Feb 2003 15:11:18 -0500 Message-ID: <02f701c2de9c$65db71e0$0202040a@catdog> From: "Kris Warkentin" To: "Daniel Jacobowitz" Cc: "Andrew Cagney" , References: <020c01c2d3ae$c7cb39b0$0202040a@catdog> <20030213222922.GA15783@nevyn.them.org> <000901c2d3ba$cb19aaf0$2a00a8c0@dash> <20030214000311.GA18154@nevyn.them.org> <003d01c2d3bd$b136bf30$2a00a8c0@dash> <20030214001316.GA18590@nevyn.them.org> <017c01c2d3c1$6196b210$2a00a8c0@dash> <3E4EBCF0.8070003@redhat.com> <20030217154403.GA16683@nevyn.them.org> <059b01c2d69e$0a5fe9f0$0202040a@catdog> <20030227200206.GA11306@nevyn.them.org> Subject: Re: patch to add QNX NTO i386 support Date: Thu, 27 Feb 2003 20:11:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-02/txt/msg00778.txt.bz2 > > Seriously though, I'd love to hear proposals for alternative methods of > > accomplishing this. We need to get symbols from a file on the host and then > > exec this file at an arbitrary path on the target. If you think about it, > > the current solution encapsulates that perfectly. Like I said though, I'd > > love to hear other ideas. > > "set remote exec-path"? Except that's not quite accurate, because the > normal remote protocol doesn't support it. Maybe "set nto exec-path", > since it'd only be used by remote-nto. Or you could just leave it the way it is....if it ain't broke, don't fix it right? (note: I don't know when this was sent - our email server held onto a bunch of my mail for a few days for some reason so my apologies if this reply is really late.) That being said, I'm of the opinion that exec-file should be unconditional. If symbol-file is set to one thing and exec-file to another, should gdb even need to check to see if exec-file exists? I haven't looked to see what info exec-file seems to feel it needs from the binary but I figure the run command will discover that the exec file isn't there and report an error itself. Then, in our case, the run command spawns on the remote and everyone is happy and we don't need a special command. cheers, Kris