public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: newlib@sourceware.org
Subject: [PATCH 2/6] newlib: rename mallocr.c to _mallocr.c
Date: Tue,  1 Mar 2022 20:36:19 -0500	[thread overview]
Message-ID: <20220302013623.368-3-vapier@gentoo.org> (raw)
In-Reply-To: <20220302013623.368-1-vapier@gentoo.org>

This file is a little confusing: it provides all of the mallocr logic,
but is compiled multiple times to produce a unique symbol each time.
For example, building mallocr.c with -DDEFINE_FREER produces freer.o
that only defines _free_r().  This is fine for most symbols, but it's
a little confusing when defining mallocr itself -- we produce a file
with the same symbol name, but we still need -DDEFINE_MALLOCR.  In
order to move the logic from the build rules to source files, using
mallocr.c both as a multiplexer and for defining a single symbol is a
bit tricky.  It's possible (if we add a lot of redundant preprocessor
checks to mallocr.c, or we add complicated build flags just for this
one files), but it's easier if we simply rename this to a dedicated
file.  So let's do that.

We do this as a dedicated commit because the next one will create a
new mallocr.c file and git's automatic diff algorithms can handle
trivial renames, but it can't handle renames+creates in the same
commit.
---
 newlib/libc/stdlib/Makefile.am               | 24 ++++++++++----------
 newlib/libc/stdlib/Makefile.in               | 24 ++++++++++----------
 newlib/libc/stdlib/{mallocr.c => _mallocr.c} |  0
 3 files changed, 24 insertions(+), 24 deletions(-)
 rename newlib/libc/stdlib/{mallocr.c => _mallocr.c} (100%)

diff --git a/newlib/libc/stdlib/Makefile.am b/newlib/libc/stdlib/Makefile.am
index 950ad98ac134..cb2fbe850b85 100644
--- a/newlib/libc/stdlib/Makefile.am
+++ b/newlib/libc/stdlib/Makefile.am
@@ -180,40 +180,40 @@ lib_a_CFLAGS = $(AM_CFLAGS)
 lib_a_DEPENDENCIES = $(LIBADD_OBJS) $(ELIX_OBJS)
 LIB_COMPILE = $(AM_V_CC)$(COMPILE)
 
-$(lpfx)mallocr.o: mallocr.c
+$(lpfx)mallocr.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_MALLOC -c $< -o $@
 
-$(lpfx)freer.o: mallocr.c
+$(lpfx)freer.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_FREE -c $< -o $@
 
-$(lpfx)reallocr.o: mallocr.c
+$(lpfx)reallocr.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_REALLOC -c $< -o $@
 
-$(lpfx)callocr.o: mallocr.c
+$(lpfx)callocr.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_CALLOC -c $< -o $@
 
-$(lpfx)cfreer.o: mallocr.c
+$(lpfx)cfreer.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_CFREE -c $< -o $@
 
-$(lpfx)malignr.o: mallocr.c
+$(lpfx)malignr.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_MEMALIGN -c $< -o $@
 
-$(lpfx)vallocr.o: mallocr.c
+$(lpfx)vallocr.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_VALLOC -c $< -o $@
 
-$(lpfx)pvallocr.o: mallocr.c
+$(lpfx)pvallocr.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_PVALLOC -c $< -o $@
 
-$(lpfx)mallinfor.o: mallocr.c
+$(lpfx)mallinfor.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_MALLINFO -c $< -o $@
 
-$(lpfx)mallstatsr.o: mallocr.c
+$(lpfx)mallstatsr.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_MALLOC_STATS -c $< -o $@
 
-$(lpfx)msizer.o: mallocr.c
+$(lpfx)msizer.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_MALLOC_USABLE_SIZE -c $< -o $@
 
-$(lpfx)malloptr.o: mallocr.c
+$(lpfx)malloptr.o: _mallocr.c
 	$(LIB_COMPILE) -DDEFINE_MALLOPT -c $< -o $@
 
 $(lpfx)dtoa.o: dtoa.c mprec.h
diff --git a/newlib/libc/stdlib/mallocr.c b/newlib/libc/stdlib/_mallocr.c
similarity index 100%
rename from newlib/libc/stdlib/mallocr.c
rename to newlib/libc/stdlib/_mallocr.c
-- 
2.34.1


  parent reply	other threads:[~2022-03-02  1:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-02  1:36 [PATCH 0/6] rework malloc logic from build rules to source files Mike Frysinger
2022-03-02  1:36 ` [PATCH 1/6] newlib: move nano-malloc logic from build " Mike Frysinger
2022-03-02  1:36 ` Mike Frysinger [this message]
2022-03-02  1:36 ` [PATCH 3/6] newlib: xstormy16: fix mallopt definition & mstats handling Mike Frysinger
2022-03-02  9:46   ` Corinna Vinschen
2022-03-09  9:23     ` Mike Frysinger
2022-03-10  8:12       ` Corinna Vinschen
2022-03-10  8:00     ` Sebastian Huber
2022-03-02  1:36 ` [PATCH 4/6] newlib: xstormy16: break up mallocr stubs Mike Frysinger
2022-03-02  1:36 ` [PATCH 5/6] newlib: xstormy16: move malloc multiplex logic from build to source files Mike Frysinger
2022-03-02  1:36 ` [PATCH 6/6] newlib: libc: move stdlib " Mike Frysinger
2022-03-02  9:47 ` [PATCH 0/6] rework malloc logic from build rules " Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220302013623.368-3-vapier@gentoo.org \
    --to=vapier@gentoo.org \
    --cc=newlib@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).