proposed solution for my remote 'run' problem
Andrew Cagney
ac131313@redhat.com
Thu Jul 17 19:41:00 GMT 2003
> 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
More information about the Gdb
mailing list