Help with GDB on Powerpc Targets

[Chris Johns]

Hi Matt,

Please excuse the delay in responding, I am currently traveling.

On 20/11/16 2:19 pm, Matt Rippa wrote:
> I found this on Till's
> page. http://www.slac.stanford.edu/~strauman/rtems/gdb/index.html
> 
> Looks like all my bsp's are mentioned.
> 

Yes the PowerPC is supported in Till's packages. These packages will not
be merged into RTEMS and I do not know the status of them with the
current code base.

I have a new debug server [1] which has x86 and ARM (CortexA9) support.
The server side of things is stable and the target support is starting
to look good. This will be merged into the main repository once I have
changed the name of the package from dbserver [2].

I would welcome PowerPC support but I currently have no budget to
complete that task.

The new rtemsdbug server implements the latest GDB remote protocol and
gives the user access to all threads except some special excluded
threads needed to support the server. You attach to a running board
giving you access to your application. With some simple techniques in
your application you can debug initialisation. You can list the threads,
switch to a thread and perform a back trace. A crash will put you at the
instruction of the crash. Being a standard remote protocol it should
integrate with a range of GUI front ends, I have been using Emacs and it
is nice to use.

At a technical level the server currently supports the "stop all" model
and does not support the "non-stop" mode. No-stop mode could be added
but it was not considered important for the initial release. There is no
thread specific break-point support. It may be possible but I am not
sure GDB's remote protocol is able to do this. I personally do not think
this is a major issue. The server supports range stepping where
supported which is a real performance boost when stepping. The server
code supports libbsd and I have not tested it with the legacy stack but
it should work.

Known issues. First this is invasive debugging with software running on
the target so there is a limit to what you can debug. Interrupts are an
example of something you cannot debug when using TCP as the remote
protocol. A bug which writes to any memory may corrupt the debug
server's data or the networking stack. In general the support is really
good for applications and even drivers which use tasks for interrupt
processing, something that is important on SMP systems. I would like to
refactor the transport to allow serial support. I have not tested the
server on SMP systems.

Current implementation limitations. The server needs support added to
define XML based register sets as defined by GDB. This allows support
for various specialised register sets such as a NEON on ARM, MMX on x86,
or special registers found in embedded variants of devices. A current
bug is breaking on a break point set in the path an excluded thread
uses. This can happen when dealing with tasks that are doing things in
the OS or networking stack.

I hope this helps.

Chris

[1] https://ftp.rtems.org/pub/rtems/people/chrisj/dbserver/
[2] Sebastian pointed out dbserver is a bad name due to a Goggle
    search. I am not a database person. I will change the name
    to rtemsdbug then merge.

> -Matt
> 
> On Fri, Nov 18, 2016 at 7:15 AM, Matt Rippa <mrippa at gemini.edu
> <mailto:mrippa at gemini.edu>> wrote:
> 
>     Looking for guidance running gdb on ppc targets. Remote debugging
>     would be ideal, but any method of setting a break point or seeing a
>     stack trace would help.
> 
>     Is there a resource I can start reading to set this up? My three
>     bsp's are below.
> 
>     Thank you,
>     -Matt
> 
>     ../rtems-4.10.2/configure --target=powerpc-rtems4.10
>     --prefix=/gem_sw/targetOS/RTEMS/rtems-4.10 --enable-cxx
>     --enable-rdbg --disable-tests --enable-networking --enable-posix
>     --enable-readline --enable-rtemsbsp="beatnik mvme2307 mvme3100"
> 
> 
> 
> 
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>