This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Replace some xmalloc-family functions with XNEW-family ones
- From: Simon Marchi <simon dot marchi at ericsson dot com>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Wed, 19 Aug 2015 11:31:16 -0400
- Subject: Re: [PATCH] Replace some xmalloc-family functions with XNEW-family ones
- Authentication-results: sourceware.org; auth=none
- References: <1439848395-1869-1-git-send-email-simon dot marchi at ericsson dot com> <86614d3rsu dot fsf at gmail dot com>
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 <simon.marchi@ericsson.com> 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.