This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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




On 08/18/2015 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).

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..



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]