Re: Remote debugging

[Russell Shaw <rjshaw@netspace.net.au>]

On 08/03/15 01:09, Ofir Cohen wrote:
> Hi Russel,
> I hope this is what you're looking for.
>
> I see two approaches:
> 1) File system sharing/copying utility
>      Similar to what you suggested, NFS, scp, etc.
>
>      I do remote debugging all the time with gdb and gdbserver, and I have this
>      batch file (both my host and target are Windows OSes) that copies
> my binaries
>      over SMB share.
>
>      If you build your sources frequently, and you're paranoid about
> typing the same commands
>      over and over again, how about adding a post-build command to call
> this script to deploy the files?
>
>
> 2) Transferring files via remote protocol
>       Once you're connected from gdb to gdbserver, you can use the
> following command [1]:
>       remote put <host file> <target file>
>
>       However, this might be an overkill as it will require gdbserver
> [2] to be attached to
>       some dummy process, and will most likely require you to start new
> gdb and gdbserver
>       processes in order to debug the new binary.
>
> I personally consider option #1 as a valid and normal way of
> host2target remote debugging workflow.

Hi,

I put in /home/russell/myprogdir/.gdbinit:

target extended-remote main:1234

cd /home/russell/myprogdir

file myprog
remote put myprog myprog2

break main

run

define hook-run
kill
file myprog
remote put myprog myprog2
end


I was going to do on the laptop (the above test is all in the same directory on 
the same pc):

gdbserver main:1234 myprog2


When testing with gdbserver invoked on the same pc (main) in the same directory 
(/home/russell/myprogdir), "myprog" is truncated to 0 bytes by "remote put 
myprog myprog", so i had to use myprog2 for the copy. I filed a bug for that.

"remote put" should first copy myprog to /tmp/, open the remote myprog for 
writing (which truncates it), then copy from /tmp/. Another way is to note the 
source and dest are the same, and skip the copying.