Re: [PATCH] Replace some xmalloc-family functions with XNEW-family ones

[Simon Marchi <simon.marchi@ericsson.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.