From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101801 invoked by alias); 18 Aug 2015 13:09:44 -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 101761 invoked by uid 89); 18 Aug 2015 13:09:43 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 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; Tue, 18 Aug 2015 13:09:41 +0000 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id DD.2F.26730.525C2D55; Tue, 18 Aug 2015 07:39:49 +0200 (CEST) Received: from [142.133.110.95] (147.117.188.8) by smtp-am.internal.ericsson.com (147.117.188.92) with Microsoft SMTP Server id 14.3.210.2; Tue, 18 Aug 2015 09:09:39 -0400 Message-ID: <55D32E92.2070506@ericsson.com> Date: Tue, 18 Aug 2015 13:09:00 -0000 From: Antoine Tremblay 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 , Simon Marchi 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"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg00466.txt.bz2 On 08/18/2015 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). > > 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. > >> >> 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. > >> >> 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. > Just a note , I have to test my build also for multi arch soon and I checked the gcc compile farm, while it looked very promising the current online servers are ppc and x86 only... Cross compiling looks like a better way , I plan to use https://github.com/palves/multi-build for inspiration to make a makefile for all this... Unfortunately though with cross compiling the tests won't be done..