proposed solution for my remote 'run' problem

proposed solution for my remote 'run' problem

[Kris Warkentin]

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.

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?

cheers,

Kris

Re: proposed solution for my remote 'run' problem

[Andrew Cagney]

> 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