This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[PATCH] malloc: define __libc_memalign
- From: Joern Engel <joern at purestorage dot com>
- To: "GNU C. Library" <libc-alpha at sourceware dot org>
- Cc: Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>, Joern Engel <joern at purestorage dot com>
- Date: Mon, 25 Jan 2016 16:25:40 -0800
- Subject: [PATCH] malloc: define __libc_memalign
- Authentication-results: sourceware.org; auth=none
- References: <1453767942-19369-1-git-send-email-joern at purestorage dot com>
This one is special, in a horrible way. The libc implementation
of tls does memory allocations. Malloc depends on tls, so we have
a circular dependency. Libc solved this by having a weak definition
for __libc_memalign in tls which does little more than mmap.
If malloc is already initialized, the malloc version will override
the tls version. Otherwise tls will us it's own.
Life gets more interesting if people ship their own version of
malloc (this version) and provide hooks for libc malloc to catch
mistakes where allocations go to libc malloc that shouldn't. Those
hook also instrument __libc_memalign and get triggered by the tls
code - but only on unusual workloads where the stars align.
Defining an alias for any __libc_* function is wrong on many levels,
but that seems to be the only solution short of patching libc code.
https://codereviews.purestorage.com/r/23945/
JIRA: PURE-43462
---
tpc/malloc2.13/malloc.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/tpc/malloc2.13/malloc.c b/tpc/malloc2.13/malloc.c
index 50a50949bd56..19eea9f77deb 100644
--- a/tpc/malloc2.13/malloc.c
+++ b/tpc/malloc2.13/malloc.c
@@ -5537,6 +5537,25 @@ strong_alias(dlget_state, get_state);
strong_alias(dlset_state, set_state);
strong_alias(dlposix_memalign, posix_memalign);
+/*
+ * This one is special, in a horrible way. The libc implementation
+ * of tls does memory allocations. Malloc depends on tls, so we have
+ * a circular dependency. Libc solved this by having a weak definition
+ * for __libc_memalign in tls which does little more than mmap.
+ * If malloc is already initialized, the malloc version will override
+ * the tls version. Otherwise tls will us it's own.
+ *
+ * Life gets more interesting if people ship their own version of
+ * malloc (this version) and provide hooks for libc malloc to catch
+ * mistakes where allocations go to libc malloc that shouldn't. Those
+ * hook also instrument __libc_memalign and get triggered by the tls
+ * code - but only on unusual workloads where the stars align.
+ *
+ * Defining an alias for any __libc_* function is wrong on many levels,
+ * but that seems to be the only solution short of patching libc code.
+ */
+strong_alias(dlmemalign, __libc_memalign);
+
/* ------------------------------------------------------------
History:
--
2.7.0.rc3