From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29617 invoked by alias); 28 Jun 2011 08:21:40 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 29602 invoked by uid 22791); 28 Jun 2011 08:21:38 -0000 X-SWARE-Spam-Status: No, hits=-0.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 28 Jun 2011 08:21:00 -0000 Message-ID: Subject: Re: C++ draft From: Yao Qi To: archer@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2011-q2/txt/msg00031.txt.bz2 On Tue, Jun 28, 2011 at 5:08 AM, Tom Tromey wrote: > I've been working on another proposal to move gdb to C++. =A0I'd > appreciate help with it. =A0Here is what I have so far. > > Do you find it reasonably convincing? =A0If not, why not? =A0What can be > improved? =A0Are there other good initial targets for conversion? =A0Are > there lurking problems of which I am unaware? > I don't have special preference over C or C++. > My proposal is: > > 1. Modify GDB so it can be compiled with -Wc++-compat. > =A0 This would be the first patch series. =A0There is already an archer > =A0 branch for this. > > 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is > =A0 not complete). =A0This would be the second patch series. > > 3. Require C++. > > 4. Change selected modules to use C++ rather than C. > =A0 I don't think a wholesale change makes sense, but some areas would > =A0 benefit. > > =A0 My first target would be to change the exception handling system to > =A0 use C++ exception. =A0This would enable us to begin using RAII in > =A0 some areas, which would help robustness. > > =A0 My concrete plan here is: > > =A0 * Use the GCC cleanup-checking plugin I already wrote to detect > =A0 =A0 cleanup-aware functions. > > =A0 * Modify these functions, using a script, to add an RAII-using > =A0 =A0 object to manage the local cleanups. =A0This is important so that > =A0 =A0 we run cleanups at the correct time during stack unwinding. > > =A0 * Change throw_exception to use 'throw' and all TRY_EXCEPT > =A0 =A0 instances to try...catch. > > =A0 * Finally, convert functions to static RAII usage when appropriate; > =A0 =A0 this will be an ongoing transition. > > =A0 I think our second target will be sorting out Python reference > =A0 counting, so we can avoid the many problems we have had there. > Tom, In your concrete plan, IIUC, your plan is about converting GDB to C++ *partially*, instead of re-write GDB *completely*. Is that correct? For example, I don't anything in your plan about converting *-tdep.c stuff into C++. Is it in your plan or we plan to leave them as they are now? Do we plan to move gdbserver to C++? I think no, because some baremental boards have too few memory to hold a C++ application. So we are in a state that both C and C++ co-exist in GDB for some time. I don't think C and C++ co-existance is a problem, or, your plan is about "make good use of C++ to replace some bad and error-prone stuffs in GDB, and keep the rest of GDB as it is". Is it right? Just want to know clearly what GDB will be after your plan is performed. --=20 Yao Qi http://sites.google.com/site/duewayqi/