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


> > 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


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