Re: proposed solution for my remote 'run' problem

[Andrew Cagney <ac131313@redhat.com>]

> If anyone recalls, previously I had discussed a problem with our way of
> running things on the remote QNX machine.
> 
> What we used to do is something like:
> (gdb) target qnx host:8000
> (gdb) sym /path/to/some/host/file
> (gdb) b main
> (gdb) r /some/remote/path with some args
> 
> This was considered ugly because it gave 'run' a context dependent
> definition: if exec_file is set, run just takes arguments, otherwise it
> takes a file and arguments.
> 
> Today I just put in a string that can be set with 'set nto_remote_file'.
> Now if you call 'nto_create' (target_create_inferior), it will use this path
> if it is set, otherwise it will use the path passed in (which could be
> exec_file).  This has the added benefit of letting you run gdb from the
> command line as 'gdb some_file'.  Before, if you did that, exec_file would
> be set and you couldn't run the remote binary if its path was different than
> the host.  So, if the paths are the same, it works normally, otherwise, you
> can set the remote binary but either way, exec_file doesn't affect things.

Use `set nto remote-file', otherwize set <tab> gets badly polluted :-)

> Two problems I've observed with this approach.
> 
> One: for some reason, when I run the program, it always says:
> 
> 'some_program' has changed; re-reading symbols.
> 
> I haven't chased this yet but it's kind of weird.
> 
> Two: the target_create_inferior command doesn't take a 'from_tty' argument.
> It would be really nice if it did because I'd like to have output like so:
> 
> Starting program: /cygdrive/k/test/float.x86
> Remote: /home/kewarken/61/test/float.x86
> 
> Where the 'Remote' part comes from target_create_inferior.  Can anyone
> suggest another place which has a 'from_tty' that I could put that message?
> If not, would anyone object to me changing all the target_create_inferiors
> to take a from_tty?

Well there is a small chance that between 6.0/6.1 or 6.1/6.2 that the 
target vector will get a overhaul:

- it needs to be parameterized with the target vector
- the open, create, close sequence (which you're looking at) needs a rethink

beyond that, I don't know.

Andrew