From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28786 invoked by alias); 19 Aug 2015 15:31:22 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 28773 invoked by uid 89); 19 Aug 2015 15:31:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: usevmg21.ericsson.net Received: from usevmg21.ericsson.net (HELO usevmg21.ericsson.net) (198.24.6.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Wed, 19 Aug 2015 15:31:20 +0000 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 97.7B.26730.9C734D55; Wed, 19 Aug 2015 10:01:13 +0200 (CEST) Received: from [142.133.110.144] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.89) with Microsoft SMTP Server id 14.3.210.2; Wed, 19 Aug 2015 11:31:17 -0400 Message-ID: <55D4A144.70802@ericsson.com> Date: Wed, 19 Aug 2015 15:31:00 -0000 From: Simon Marchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.8.0 MIME-Version: 1.0 To: Yao Qi CC: Subject: Re: [PATCH] Replace some xmalloc-family functions with XNEW-family ones References: <1439848395-1869-1-git-send-email-simon.marchi@ericsson.com> <86614d3rsu.fsf@gmail.com> In-Reply-To: <86614d3rsu.fsf@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00520.txt.bz2 What Pedro said in his reply is exactly what I had in mind. On 15-08-18 04:49 AM, Yao Qi wrote: > Simon Marchi writes: > > Hi Simon, > Thanks for doing this. > >> This patch is part of the make-gdb-buildable-in-C++ effort. The idea is >> to change some calls to the xmalloc family of functions to calls to the >> equivalents in the XNEW family. This avoids adding an explicit cast, so >> it keeps the code a bit more readable. Some of them also map relatively >> well to a C++ equivalent (XNEW (struct foo) -> new foo), so it will be >> possible to do scripted replacements if needed. > > I am not against this patch, and I think this patch is useful to shorten > the code in some cases. However, I don't think we really need it to > make GDB buildable in C++, right? We can still use xmalloc in a C++ > program (xmalloc is still in use in GCC). Of course we can still use xmalloc (XNEW is based on it). I started to format the patch made by the auto-insert-casts script, but then thought the resulting code was very verbose and unreadable. Especially when you have something like struct this_is_a_very_long_structure_name *variable = ((struct this_is_a_very_long_structure_name *) xmalloc (sizeof (struct this_is_a_very_long_structure_name))); So no, we don't *need* it, but it's the right way forward, IMO. > XNEW/xmalloc -> new or struct -> class conversion should be done per > data structure rather than globally like this patch does. We only > convert C-inheritance data structures like breakpoint_ops, varobj, etc, > to C++ class, and leave the rest there unless it is necessary to change > them to C++ class. This is my personal understanding, and I'd like to > hear others thoughts. Exactly, I expect most XNEW to stay. We only change them when we C++ize the corresponding class/structure. Actually, I now realize we'll have to be careful to not miss any XNEW -> new conversion when we do this, the code would still build, but allocating with XNEW won't call the constructor of the class. It would give strange behaviours >> I only changed calls that were obviously allocating memory for one or >> multiple "objects". Allocation of variable sizes (such as strings or >> buffer handling) will be for later (and won't use XNEW). >> >> - xmalloc (sizeof (struct foo)) -> XNEW (struct foo) >> - xmalloc (num * sizeof (struct foo)) -> XNEWVEC (struct foo, num) >> - xcalloc (1, sizeof (struct foo)) -> XCNEW (struct foo) >> - xcalloc (num, sizeof (struct foo)) -> XCNEWVEC (struct foo, num) >> - xrealloc (p, num * sizeof (struct foo) -> XRESIZEVEC (struct foo, p, num) >> - obstack_alloc (ob, sizeof (struct foo)) -> XOBNEW (ob, struct foo) >> - obstack_alloc (ob, num * sizeof (struct foo)) -> XOBNEWVEC (ob, struct foo, num) >> - alloca (sizeof (struct foo)) -> XALLOCA (struct foo) >> - alloca (num * sizeof (struct foo)) -> XALLOCAVEC (struct foo, num) >> >> Some instances of xmalloc followed by memset to zero the buffer were >> replaced by XCNEW or XCNEWVEC. > > I am not against this conversion. If we accept this change, are > xmalloc/xcalloc/... not allowed to use, and XNEW/XNEWVEC/... should be > used instead. The restriction is not necessary to me. Agreed. >> >> I regtested on x86-64, Ubuntu 14.04, but the patch touches many >> architecture-specific files. For those I'll have to rely on the >> buildbot or people complaining that I broke their gdb. > > If arch-specific files are changes, we have several ways to make sure > changes don't break build at least, > > - Configure gdb with --enable-targets=all --enable-64-bit-bfd and > build, all *-tdep.c changes can be covered, > - Download some cross compile, such as arm/aarch64/mips gcc, and cross > compile native gdb for these archs, for example, configure gdb with > --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf CC=/foo/bar/arm-linux-gnueabihf-gcc > - Install mingw32 toolchain, and cross compile native gdb for win32. > > You can also apply for gcc compile farm account to build patched GDB > there. The complains of buildbot or people are the last guards, and we > should trigger as less complains as we can. I already build with --enable-targets=all. Is there a list of cross-compilers we can download to test building gdb with ? If you guys have links to already built cross-compilers to various architectures, I can create a wiki page for it. Otherwise, I'll try to build a few toolchains using crosstool-ng, it seems relatively easy.