Author Topic: Debugging remote embedded target with gdb  (Read 15557 times)

msr

  • Community Member
  • Posts: 8
  • Hero Points: 1
Debugging remote embedded target with gdb
« on: July 25, 2008, 01:24:05 am »
Hello...

I am trying to use SlickEdit as the front end to gdb for a remote embedded target.  (It has been great for me debugging cygwin.  Now I am using CodeSourcery G++ Lite and OpenOCD for Luminary Stellaris, Arm Cortex.)

I wrote a program to capture the communication between SlickEdit and GDB.  This is what I get:

-----
[arm-none-eabi-gdb.exe -nw -interpreter=mi -quiet]
@"verified 448 bytes in 0.250000s\n"
set new-console on
@"requesting target halt and executing a soft reset\n"
(gdb)
&"set new-console on\n"
&"No symbol \"new\" in current context.\n"
^error,msg="No symbol \"new\" in current context."
(gdb)
set new-group off
&"set new-group off\n"
&"No symbol \"new\" in current context.\n"
^error,msg="No symbol \"new\" in current context."
(gdb)
-file-exec-and-symbols "blinky.axf"
^done
(gdb)
-gdb-set breakpoint pending on
^done
(gdb)
-gdb-set unwindonsignal on
^done
(gdb)
-thread-list-ids
&"warning: RMT ERROR : failed to get remote thread list.\n"
^done,thread-ids={},number-of-threads="0"
(gdb)
-exec-run
^running
(gdb)
&"Don't know how to run.  Try \"help target\".\n"
^error,msg="Don't know how to run.  Try \"help target\"."
(gdb)
-----

After this, SlickEdit reports: "Error: Don't know how to run.  Try "help target".  Then exits.

I have a .gdbinit file that connects to the target and  download/flashes the program.


If I do these same steps by hand, every thing is good right up to the "-exec-run".  The .gdbinit commands have downloading and started the program already.  I can look at the stack inspect registers, step into the code, etc.  I think a '-exec-continue' would work.

But the -exec-run command reports an error and ends everything.

I would really appreciate any help I can get!

(If I get this working, I will be influencing others to convert to SlickEdit/GNU from IAR.)

Thank You!

-Mike


Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2288
  • Hero Points: 295
Re: Debugging remote embedded target with gdb
« Reply #1 on: July 29, 2008, 09:30:57 pm »
Strangely, the commands you captured do not include a "-target-select remote ..."  How can this be if you are attaching to GDB remotely?

We have to treat some things differently for remote targets vs. regular debug targets, one of those differences is -exec-run vs. -exec-continue.  If you don't attach to the remote target in a normal way, we don't know this is a remote debugging session.  (Also see the other thread about suspend).

msr

  • Community Member
  • Posts: 8
  • Hero Points: 1
Re: Debugging remote embedded target with gdb
« Reply #2 on: July 30, 2008, 02:01:09 am »
Thank you for the response!

>Strangely, the commands you captured do not include a "-target-select remote ..."  How can this be if
>you are attaching to GDB remotely?

I have a .gdbinit file that performs the following:

----
target remote localhost:3333"
monitor flash cond_write_image erase c:\Luminary\DriverLib\boards\ek-lm3s6965_revc\blinky\gcc\blinky.bin 0 bin
monitor soft_reset_halt
----

I have tried sever variations of .gdbinit... hopefully this gives you a good idea of what is happening.
(The .gdbinit cammands are not capture by my program.)

Perhaps if I use the MI command "-target-select remote ..." it will changed how SE reacts?  I give that a try and report back...

Thanks,

-Mike

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2288
  • Hero Points: 295
Re: Debugging remote embedded target with gdb
« Reply #3 on: July 30, 2008, 01:45:14 pm »
We have no control over what you put in a .gdbinit -- we just hope that the contents of .gdbinit doesn't completely turn things upside down for us.  Therefore, using -target-select won't make any difference as far as SlickEdit is concerned.  The only way you get SlickEdit to know the session is remote is to attach using "Attach to Remote GDB Server".

msr

  • Community Member
  • Posts: 8
  • Hero Points: 1
Re: Debugging remote embedded target with gdb
« Reply #4 on: July 30, 2008, 05:04:51 pm »
OK, I used the menu option "Debug | Attach Debugger | Attach to Remote Process Using GDB..."  and it almost worked.  (It seemed to use port 8002 regardless of what I put in the dialog, so I changed my gdb server.)

I could step and run, use breakpoints, etc  (YEAH!)

But suspending still doesn't work.  I get the following error:

"Error suspending debugger:  Could not find the gdb proxy application window"

Thanks for your continued help!

-Mike

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2288
  • Hero Points: 295
Re: Debugging remote embedded target with gdb
« Reply #5 on: July 30, 2008, 05:44:32 pm »
Did you turn off the proxy?  Go to Macro > Set Macro Variable... and check def_gdb_use_proxy.
It should be set to 1.  Because of the deficiencies I have described with GDB, without the proxy, you can forget about suspend doing anything.

Keep in mind that the proxy lives between GDB and the gdbserver.  GDB connects to the proxy on the port defined by def_gdb_proxy_port, default is 8002, then the proxy connects to the server on the port that you specify in the dialog.

chrisant

  • Senior Community Member
  • Posts: 1413
  • Hero Points: 131
Re: Debugging remote embedded target with gdb
« Reply #6 on: July 30, 2008, 06:43:00 pm »
Mike, you stopped using your program for capturing the communication between SlickEdit and GDB, right?

msr

  • Community Member
  • Posts: 8
  • Hero Points: 1
Re: Debugging remote embedded target with gdb
« Reply #7 on: July 30, 2008, 08:22:11 pm »

I am suddenly VERY HAPPY!  It is all working GREAT!!  ;D

Yes, Chrisant, I had stopped using my program... BUT, when I still couldn't get SE to connect to my GDB server, I used it again to learn that SE was trying to connect to port 8002.  That is when I changed my GDB server to listen on port 8002.  This seemed to make it work, without suspend, but I now know that listening on port 8002 was the wrong thing to do!  (I don't know why I originally could not connect.  Perhaps my server just wasn't up...)

Dennis, thank you so very much for your help.  I can't say enough...  look for new licenses and upgrades coming from Vantage/Legrand in the near future.

-Mike