Author Topic: Run bash script before remote debugging  (Read 24052 times)

Offline bigwcharly

  • Single posting newcomer
  • *
  • Posts: 5
Run bash script before remote debugging
« on: May 16, 2014, 02:14:47 pm »
Hi all

How does the "Additional shell commands" tab work?
Debugging my application works, but I don't manage to get my commands to run before connecting to the remote gdbserver.
What I want to achieve in the end is that before debugging
1.) my binaries are copied to the remote device and
2.) the gdbserver is started on the remote device

I've found a similar - unanswered - question on sourceforge from 2009.

I'm using the latest version of C::B on Ubuntu 12.04.

Many thanks!

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Run bash script before remote debugging
« Reply #1 on: May 16, 2014, 10:45:23 pm »
Can you post the full log from the debugger? And make sure that you're using C::B >=12.11.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Run bash script before remote debugging
« Reply #2 on: May 17, 2014, 06:58:52 am »
1.) my binaries are copied to the remote device and
Just insert your command line to copy the files.

2.) the gdbserver is started on the remote device
I always thought 'additional shell commands' feature was the perfect way to start the gdbserver before debugging but unfortunately that's not possible. The problem is gdb waits for the executed program to end before continuing and in that case gdbserver waits for gdb to make a connection and gdb waits for gdbserver to terminate to resume debugging (to make the connection). Quite ironic. It's been way too long since I quit trying to make this work so I don't know if there is a new trick though.

Offline bigwcharly

  • Single posting newcomer
  • *
  • Posts: 5
Re: Run bash script before remote debugging
« Reply #3 on: May 17, 2014, 04:53:56 pm »
Hi

These are the commands I entered before connetion:

Code
scp ../../../Binaries/debug/Tests pi@192.168.2.100:/home/pi/Development/Test
ssh pi@192.168.2.100 "gdbserver :5000 /home/pi/Development/Test/Tests"

This is the debug log:

Code
Building to ensure sources are up-to-date
Selecting target:
debug
Adding source dir: /home/developer/Development/svn/Source/Projects/Tests/
Adding source dir: /home/developer/Development/svn/Source/Projects/Tests/
Adding file: /home/developer/Development/svn/Binaries/debug/Tests
Changing directory to: /home/developer/Development/svn/Source/Projects/Tests/.
Set variable: LD_LIBRARY_PATH=.:/home/developer/Development/svn/Libraries/debug:/home/developer/Development/svn/Source/Thirdparty/jsoncpp/lib:/home/developer/Development/svn/Source/Thirdparty/sqlite/lib:
Starting debugger: /home/developer/Development/svn/Tools/crosstools-ng/bin/bin/arm-unknown-linux-gnueabi-gdb -nx -fullname  -quiet  -args /home/developer/Development/svn/Binaries/debug/Tests
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Connecting to remote target
Setting breakpoints
Debugger name and version: GNU gdb (crosstool-NG 1.18.0) 7.4.1
Connected
In process_dl_audit () (/home/developer/Development/svn/Tools/crosstools-ng/bin/arm-unknown-linux-gnueabi/sysroot/lib/ld-linux.so.3)
[Inferior 1 (Remote target) exited normally]
No stack.
Debugger finished with status 0

My version of C::B is "svn build rev 9639 (2014-02-08 09:33:14) gcc 4.6.3 Linux/unicode - 64 bit". This should be version 13.12.
As I'm on Ubuntu 12.04 I've installed this version from https://launchpad.net/~pasgui/+archive/ppa/

Still, the problem is that my commands don't get executed. Even if I try just a "cp ./SomeFile ./here/" this doesn't happen...
Maybe something's wrong with my commands. Could someone point me to my error or give an example?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Run bash script before remote debugging
« Reply #4 on: May 17, 2014, 05:35:49 pm »
This is not the full log, you have to enable it in the settings.

@scraphin: Have you tried to execute a shell script that starts gdbserver as a background job and exits (probably using nohup)?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Run bash script before remote debugging
« Reply #5 on: May 17, 2014, 07:38:03 pm »
@scraphin: Have you tried to execute a shell script that starts gdbserver as a background job and exits (probably using nohup)?
No, I haven't and I can't. I'm on Windows, sorry for missing information.

Fortunately I found a way to resolve this. Instead of using cmd.exe to launch the gdbserver, using start.exe launches a separate process and returns without waiting for the process to finish.

Unfortunately I can confirm the execution of 'additional shell commands' fails, here is the full log:
Code
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: D:\coding\projects\own\procpp\
Adding source dir: D:\coding\projects\own\procpp\
Adding file: D:\coding\projects\own\procpp\bin\Debug\procpp.exe
Changing directory to: D:/coding/projects/own/procpp/.
Set variable: PATH=.;C:\GNU\mingw\4.8.2\x64_seh\bin;C:\GNU\mingw\4.8.2\x64_seh;C:\GNU\mingw\4.7.2\x32_dw2\bin;C:\GNU\mingw\4.7.2\x32_dw2;C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\GNU\msys\bin;C:\GNU\gnuwin32\bin;D:\coding\lib\qt\4.8.5\x64_mingw-4.8.2_seh\bin;D:\coding\lib\opencv\2.4.6\x64_mingw-4.8.0_seh\bin;C:\GNU\perl\5.18.2\x64\site\bin;C:\GNU\perl\5.18.2\x64\bin;C:\GNU\python\2.7.5\x64;C:\Program Files\TortoiseSVN\bin;C:\Program Files\MATLAB\R2011b\runtime\win64;C:\Program Files\MATLAB\R2011b\bin;C:\Program Files\MiKTeX\miktex\bin\x64;C:\Program Files\Doxygen\bin;C:\Program Files (x86)\Nmap

[debug]Command-line: C:\GNU\mingw\4.8.2\x64_seh\bin\gdb.exe -nx -fullname  -quiet  -args D:/coding/projects/own/procpp/bin/Debug/procpp.exe
[debug]Working dir : D:\coding\projects\own\procpp

Starting debugger: C:\GNU\mingw\4.8.2\x64_seh\bin\gdb.exe -nx -fullname  -quiet  -args D:/coding/projects/own/procpp/bin/Debug/procpp.exe
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from D:/coding/projects/own/procpp/bin/Debug/procpp.exe...
[debug]done.
[debug](gdb)
[debug]>>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.7
[debug]Copyright (C) 2014 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "x86_64-w64-mingw32".
[debug]Type "show configuration" for configuration details.
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]Find the GDB manual and other documentation resources online at:
[debug]<http://www.gnu.org/software/gdb/documentation/>.
[debug]For help, type "help".
[debug]Type "apropos word" to search for commands related to "word".
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.7

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\GNU\codeblocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory D:/coding/projects/own/procpp/
[debug]Source directories searched: D:/coding/projects/own/procpp;$cdir;$cwd
[debug]>>>>>>cb_gdb:
[debug]> break main
[debug]Breakpoint 2 at 0x401625: file D:\coding\projects\own\procpp\src\main.cpp, line 45.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: D:\coding\projects\own\procpp\bin\Debug\procpp.exe

Child process PID: 4716

[debug][New Thread 4716.0x11e8]
[debug]Breakpoint 2, main () at D:\coding\projects\own\procpp\src\main.cpp:45
[debug]D:\coding\projects\own\procpp\src\main.cpp:45:908:beg:0x401625
[debug]>>>>>>cb_gdb:

At D:\coding\projects\own\procpp\src\main.cpp:45

[debug]> bt 30
[debug]#0  main () at D:\coding\projects\own\procpp\src\main.cpp:45
[debug]>>>>>>cb_gdb:
[debug]> quit

Debugger finished with status 0

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Run bash script before remote debugging
« Reply #6 on: May 18, 2014, 05:55:42 am »
Btw I tested 'shell' from gdb command line and it works.

Offline WinterMute

  • Multiple posting newcomer
  • *
  • Posts: 25
    • devkitPro
Re: Run bash script before remote debugging
« Reply #7 on: May 21, 2014, 03:59:32 am »
I assumed the "additional shell commands" were intended for the host shell rather than the gdb shell although I guess I could be wrong. If I add "shell start <file>" in the additional gdb commands then that works.

I'm using windows for this as well.

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Run bash script before remote debugging
« Reply #8 on: May 21, 2014, 08:31:21 am »
They are for the host shell, gdb executes them on whatever host it is launched. The 'additional shell commands' used to work in the past but somehow they don't anymore, at least on windows. I hope someone will look into it soon.

Inserting 'shell do something' into 'additional gdb commands' should be the same thing as inserting 'do something' into 'additional shell commands' but I prefer the latter to work again as it seems more convenient.