From mboxrd@z Thu Jan 1 00:00:00 1970 From: Quality Quorum To: Christophe PLANAT Cc: gdb@sources.redhat.com Subject: Re: Interface gdb with a embedded custom RTOS Date: Thu, 05 Apr 2001 14:20:00 -0000 Message-id: References: <3ACC92D7.C1685CD@st.com> X-SW-Source: 2001-04/msg00044.html On Thu, 5 Apr 2001, Christophe PLANAT wrote: > qqi@world.std.com wrote: > > > ----- Original Message ----- > > From: Eli Zaretskii > > To: Quality Quorum > > Cc: > > Sent: Sunday, April 01, 2001 4:51 AM > > Subject: Re: Interface gdb with a embedded custom RTOS > > > > > > > > On Fri, 30 Mar 2001, Quality Quorum wrote: > > > > > > > I put some documents, gdb patches and code implementing multithreaded > > > > support for RTEMS on my web site: http://world.std.com/~qqi under > > > > the heading of GDB remote protocol. > > > > > > Thanks for the URL. > > > > > > How is this related to what's currently in GDB? If this document > > > describes what GDB does, it might serve as a useful source for updating > > > gdbint.texinfo. > > > > 1. This document describes what gdb does wrt single thread operations. > > 2. As far as I understand multi-threaded support over remote gdb protocol is > > mostly in the realm of wishfull thinking, so this document tries to fix it. > > 3. Reference implementation provides full blown working example to play with > > (along with a few general improvements, e.g. unifying remote and > > extended-remote targets in the single one, where exetended operations is an > > option). > > 4. My overall conclusion is that there are some serious limitations of gdb > > core wrt multi-threading support (BTW, that is why > > linux-threads implementation looks so screwy), which would not allow it be > > used effectively over remote gdb protocol. > > > > Thanks, > > > > Aleksey > > After analysing your documents, I understand that RTEMS is embedded in a user > application on a board (right ?). RTEMS is a RTOS, see http://www.rtems.com , you can dounload, build and run it on your standard PC (and on quite a few other embedded targets). > Does the user application launch the OS (I mean the main() which init RTEMS > kernel then creates threads and run them) or is it an other behavior model ? > In the case of an embedded kernel, I see 2 possible approaches : > > - by using an ISS, the OS+user_appli are downloaded by GDB in the ISS memory. > Then the program is run : init OS, creates and starts threads ...: In such case > how can GDB break a thread without breaking the OS ? Does GDB ask the OS to > stop a thread (in case of break) whereas the OS still run ? Or does GDB break > the thread directly (user debug info) and the OS too since the OS and the user > appli are the same code in fact ? Here RTOS-land break usually means OS break - whole thing stops at the breakpoint and switches control to stub, the only exception I know is VxWorks, which has per task debugging mode, however, in the system debuggin mode it will behave as most other RTOSes do. > - by using an application board (no code downloaded). The OS is started at the > reset but never stopped (in ROM). I need more infos on the threading support in > such case There are countless ways to start an RTOS, e.g. I am usually doing it using BOOTP. I would suggest building RTOS and trying debugger on the thing, it will immediately clarify a lot of things you are askig about. > > Thanks a lot for your help > > Christophe Planat > Thanks, Aleksey