This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch to add QNX NTO i386 support


On Thu, Feb 13, 2003 at 06:51:13PM -0500, Kris Warkentin wrote:
> > > > Silly question - why not say "file blah" here?  That'll set exec_bfd,
> > > > and you'll be just fine.
> > >
> > >
> > > Not silly.  If you say 'file' you have tied yourself to the host and
> target
> > > file being the same.  I need to be able to get syms from
> /home/kewarken/foo
> > > and run /tmp/foo.
> >
> > Wait, but from your earlier sequence, isn't /home/kewarken/foo on the
> > host and uploaded to /tmp/foo on the target?
> >
> > I don't follow why GDB needs to know anything about the target
> > filename.  I can see that this remote protocol is very different from
> > the normal one, if you're ssending full paths.
> 
> Yeah.  The remote system is an Unix OS with filesystem, etc. just like the
> host.  I suppose an interesting thing to do might be to have the remote
> server remember what was uploaded but that would actually limit you.  We can
> upload shared objects, set remote LD_LIBRARY_PATH, etc. or not upload at all
> but just run an arbitrary binary on the remote (which could be nfs or samba
> mounted) or even attach to a running pid on the remote.  Flexible.

These are all things I'd want gdbserver to do, at some point.  Need to
do it with extensions to the existing remote protocol (or kick the
bucket and create a new one).

That said, I still think you should be using "file" above.  File
specifies the main program, and that's what it is.  Then you can give
whatever path you want to the stub.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]