<div dir="ltr">Hi Chris,<div><br></div><div>Thanks for the update on this. I'm interested what level of effort it would take to incorporate PowerPC support.</div><div>Would that derive from Till's work? I may be able to offer support in terms of development effort by myself or others.</div><div>Getting this working is critically important to us in the next year or so.</div><div><br></div><div>-Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 21, 2016 at 3:21 PM, Chris Johns <span dir="ltr"><<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Matt,<br>
<br>
Please excuse the delay in responding, I am currently traveling.<br>
<span class=""><br>
On 20/11/16 2:19 pm, Matt Rippa wrote:<br>
> I found this on Till's<br>
> page. <a href="http://www.slac.stanford.edu/~strauman/rtems/gdb/index.html" rel="noreferrer" target="_blank">http://www.slac.stanford.edu/~<wbr>strauman/rtems/gdb/index.html</a><br>
><br>
> Looks like all my bsp's are mentioned.<br>
><br>
<br>
</span>Yes the PowerPC is supported in Till's packages. These packages will not<br>
be merged into RTEMS and I do not know the status of them with the<br>
current code base.<br>
<br>
I have a new debug server [1] which has x86 and ARM (CortexA9) support.<br>
The server side of things is stable and the target support is starting<br>
to look good. This will be merged into the main repository once I have<br>
changed the name of the package from dbserver [2].<br>
<br>
I would welcome PowerPC support but I currently have no budget to<br>
complete that task.<br>
<br>
The new rtemsdbug server implements the latest GDB remote protocol and<br>
gives the user access to all threads except some special excluded<br>
threads needed to support the server. You attach to a running board<br>
giving you access to your application. With some simple techniques in<br>
your application you can debug initialisation. You can list the threads,<br>
switch to a thread and perform a back trace. A crash will put you at the<br>
instruction of the crash. Being a standard remote protocol it should<br>
integrate with a range of GUI front ends, I have been using Emacs and it<br>
is nice to use.<br>
<br>
At a technical level the server currently supports the "stop all" model<br>
and does not support the "non-stop" mode. No-stop mode could be added<br>
but it was not considered important for the initial release. There is no<br>
thread specific break-point support. It may be possible but I am not<br>
sure GDB's remote protocol is able to do this. I personally do not think<br>
this is a major issue. The server supports range stepping where<br>
supported which is a real performance boost when stepping. The server<br>
code supports libbsd and I have not tested it with the legacy stack but<br>
it should work.<br>
<br>
Known issues. First this is invasive debugging with software running on<br>
the target so there is a limit to what you can debug. Interrupts are an<br>
example of something you cannot debug when using TCP as the remote<br>
protocol. A bug which writes to any memory may corrupt the debug<br>
server's data or the networking stack. In general the support is really<br>
good for applications and even drivers which use tasks for interrupt<br>
processing, something that is important on SMP systems. I would like to<br>
refactor the transport to allow serial support. I have not tested the<br>
server on SMP systems.<br>
<br>
Current implementation limitations. The server needs support added to<br>
define XML based register sets as defined by GDB. This allows support<br>
for various specialised register sets such as a NEON on ARM, MMX on x86,<br>
or special registers found in embedded variants of devices. A current<br>
bug is breaking on a break point set in the path an excluded thread<br>
uses. This can happen when dealing with tasks that are doing things in<br>
the OS or networking stack.<br>
<br>
I hope this helps.<br>
<br>
Chris<br>
<br>
[1] <a href="https://ftp.rtems.org/pub/rtems/people/chrisj/dbserver/" rel="noreferrer" target="_blank">https://ftp.rtems.org/pub/<wbr>rtems/people/chrisj/dbserver/</a><br>
[2] Sebastian pointed out dbserver is a bad name due to a Goggle<br>
    search. I am not a database person. I will change the name<br>
    to rtemsdbug then merge.<br>
<span class=""><br>
> -Matt<br>
><br>
> On Fri, Nov 18, 2016 at 7:15 AM, Matt Rippa <<a href="mailto:mrippa@gemini.edu">mrippa@gemini.edu</a><br>
</span><span class="">> <mailto:<a href="mailto:mrippa@gemini.edu">mrippa@gemini.edu</a>>> wrote:<br>
><br>
>     Looking for guidance running gdb on ppc targets. Remote debugging<br>
>     would be ideal, but any method of setting a break point or seeing a<br>
>     stack trace would help.<br>
><br>
>     Is there a resource I can start reading to set this up? My three<br>
>     bsp's are below.<br>
><br>
>     Thank you,<br>
>     -Matt<br>
><br>
>     ../rtems-4.10.2/configure --target=powerpc-rtems4.10<br>
>     --prefix=/gem_sw/targetOS/<wbr>RTEMS/rtems-4.10 --enable-cxx<br>
>     --enable-rdbg --disable-tests --enable-networking --enable-posix<br>
>     --enable-readline --enable-rtemsbsp="beatnik mvme2307 mvme3100"<br>
><br>
><br>
><br>
><br>
</span>> ______________________________<wbr>_________________<br>
> users mailing list<br>
> <a href="mailto:users@rtems.org">users@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br>
><br>
</blockquote></div><br></div>