Embedded development with gdbserver and cross compiled gdb

[smartin]

Hi.

I have been using SlickEdit for a very long time, and I am now evaluating it at one of my customers to do embedded development.
We are developing for ARM processors using the ARM provided gcc cross compilers. As far as development is concerned everything works OK, however setting up deugging is a pain.

We can use the cross compiled gdb, however doing that we lose all the debugger funcionality available with SlickEdit (debugger windows, set breakpoints in code, etc).

We can attach to a gdbserver that talks to the ARM board, we get all the SlickEdit debugging features, however we cannot load our code onto the remote.

Any ideas on how to work around these restrictions?

Regards.

[hs2]

Time ago I used a selfhosted gdbserver via JTAG and SE gdb debugging.
Do you have a similar (host) gdbserver like e.g. Segger JLinkGDBServer ?
I think it supports JTAG/SWD loading the target app and provides a std. interface to a (host) gdb.
Or is it a fully-blown Linux target with filesystem ? Then you could use scp/ssh commands (PuTTY migth be your friend) to copy over the (stripped) binary and launch the remote gdbserver to attach to.
Good luck, HS2

[patrick]

When you're using the cross compiled gdb, you're still just connecting to a remote gdbserver, correct?

When you say you lose the breakpoint and debugger functionality, does that mean you set breakpoints, but they're not honored? Or the breakpoint icon doesn't appear when you try to set a breakpoint before even starting the debugger? The debugger windows aren't there, or just don't work?

It might help us if you run "set-var def-debug-logging 1" in the SlickEdit command line, and then tried to start debugging, to get some logs.  The error log would be generated in your configuration directory, under the logs/debug.log".  With the logs, and maybe some setup here so I can remote-debug an ARM device for testing, it should give me an idea of what's going on.

We definitely don't support any commands for getting files over to the target system.  If it's not vendor specific, it's something we could look at supporting in a future release.

[smartin]

hs2: I am using SEGGER JLinkGDBServer, so no ssh.

patrick: Yes. Just connecting to the GBD server.

When I select Debugger as my ARM GDB then when I do Start debug SlickEdit doesn't go into debug mode, the memory/register windows are not available.

The gdb debugger itself works fine, it just doesn't integrate into SlickEdit, so I don't think def-debug-logging will help.

Thanks for your comments.

[patrick]

There might still be some information in the debug.log, as it includes the startup of the gdb client, and some other things that happen before the switch the UI debug mode.  But that does sound strange, normally if something goes wrong early on, you'll get a message box with an error telling you why it couldn't enter debug mode.   I'll have to take a look at the code and see what sort of failures could not throw up a dialog.

[hs2]

@smartin: I”ve to stick to a dedicated debugger due to low-level HW driver work for the time being..
However, the good thing is, that your setup should work
I guess it’s a minor regression in the latest (?) SE when using a custom resp. cross gdb.

[Graeme]

We do remote debugging with an ARM / Linux target and locally running Centos in a Linux VM.  We copy the executable to the target using scp then we run gdbserver on the target  - make sure the port matches the port configured for remote debugging in Slick.  Then in slickedit use "attach to remote process GDB" and use the ARM GDB.  Then click the blue arrow and the program starts running.  Make sure your local sources match the executable that's on the target.  If you get any weird behaviour, delete all breakpoints and restart.  On the target, in the window where gdbserver is running, it should output a message indicating that debugging has started when you start the debugger in slick.

[smartin]

@patrick: I set def_debug_logging to 1, where do I pick up the log file? Here is a screencast of the problem. https://screencast-o-matic.com/watch/cYn1jCwFIx

@hs2: I am looking for a complete solution here. There are 8 of us here, all using IAR, however the IAR compiler does not support 64bit ARM yet, so I have been tasked with setting up a full development/debug environment, equivalent to what we have with IAR for the 32bit development. I would like to build this around SlickEdit as I have been using it for the last 10 years at least, and as far as I am concerned it is the best solution I have found for this kind of thing. I am currently looking at Eclipse and CLion to see how they handle it.

@Graeme: This system doesn't have Linux, it is our own realtime OS that runs directly on the bare metal.

[Graeme]

Dunno if this will help but a while back when we were developing for a Renesas target with no operating system at all, someone here wrote a GDB stub that allowed us to debug in the target with GDB.
https://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.html#Remote-Debugging

[smartin]

@graeme: Thanks for the link, however the gdb client/server is working correctly. That is not the problem. The problem is the SlickEdit/gdb client implementation not working correctly.

[patrick]

It will be in your configuration directory, under logs/debug.log.  If you're not sure where the config directory is on your system, look for it on the Help -> About page.  It defaults to $HOME/.slickedit/24.0.1 on Unix and MacOS, and My Documents\My SlickEdit Config on Windows.

A question about the screencast.  I thought you were connecting to a remote gdbserver.  Debug -> Start tries to run the program locally, which isn't going work for a cross compiled app.  You would want to use "Debug -> Attach to remote process (GDB)", which will prompt you for the gdb server host and port information or device information. 

One caveat with attach - there's a combo box in the attach dialog that allows you to select which GDB to use for the attach.  When I was experimenting with it last night, it looked like the combo box wasn't taking effect, and it was just using the GDB that was set as default in the Options -> Debugging -> Configurations page.  So you may need to change the global default temporarily to use the cross compiled gdb.  I haven't verified it yet, but if it's true, I can hotfix it.

[smartin]

@patrick: I had looked in the logs directory but I didn't actually find anything. I just looked again and there it was.

With regards the attach to remote, that works as far as opening debug mode, however it doesn't load the executable and so it is not applicable to my use case. When I run the debugger directly I can use teh "target remote" to connect to the gdbserver and load the executable, however SlickEdit doesn't go into debug mode so it is not functional for my use case.

When I tried the attach to remote it respected the combo box selection, so I don't think that that is a problem.

[patrick]

I'm not sure how I missed this in the screencast of the non-attach case, but GDB is just running in your Build window.  Have you changed the Debug target for the project so it's just running that GDB?  Our debug support won't pick that up.   It doesn't watch the shell for GDB sessions to manipulate, it has to start GDB itself, partly because we need to run it in the machine interface mode, where the command line is different and exposes events, etc...

Doing the attach is the only way this is going to work.  I need to work through the logs you sent, they are the logs of the attach you did.  It does look like it's using the gdb in "C:\Program Files\SlickEdit Pro 24.0.1\win\gdb.exe", and not the ARM cross compiled version.  So you might want to set the ARM gdb as your default temporarily, and see if that changes where you stand. 

Just to make sure I'm not misunderstanding, when you attach, when you say it doesn't load the executable, does that mean it's not uploading the executable to the target?  Or when you attach, the debug view acts like there's nothing going on, the buttons for pausing, continuing are greyed out?  Or something else?

[patrick]

Something seems to be wrong with GDB attach case when running on Windows, I've reproduced something where a connection to a local proxy process fails, and it doesn't seem to be a windows firewall issue.  Same thing seems to show up in your attach logs.  Doesn't effect other platforms.  We're looking into it.

[smartin]

@patrick: Thanks. I tested using the SlickEdit GDB at some stage as well. Maybe I didn't set it back. Good luck bug hunting.