From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <9fb1f0189acbe5546193608dae59e08e@isd.dp.ua>
To: 9fans@9fans.net
From: yaroslav <yarikos@gmail.com>
Date: Thu, 18 Jul 2013 11:49:26 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] mallocz in APE
Topicbox-Message-UUID: 6c5af616-ead8-11e9-9d60-3106f5b1d025

APE programs which require libmp fail to link due to unresolved
mallocz symbol.  Easily solved by providing a local implementation,
but why: it's already there - in an alternative form though:

	cpu% nm /386/lib/ape/libap.a  | grep -i mallocz
	9mallocz.8: T _MALLOCZ
	9mallocz.8: U malloc
	9mallocz.8: U memset

I don't really see the reasons for this rename, yet other APE libs
like libsec follow it:

	cpu% nm /386/lib/ape/libsec.a | grep -i mallocz
	sha2_64.8: U _MALLOCZ
	sha2_128.8: U _MALLOCZ
	rsaalloc.8: U _MALLOCZ
	egalloc.8: U _MALLOCZ
	dsaalloc.8: U _MALLOCZ

And libmp does not:

	cpu% nm /386/lib/ape/libmp.a | grep -i mallocz
	mpaux.8: U mallocz
	mpmul.8: U mallocz

Here's why:

	cpu% grep -ni mallocz /sys/src/ape/lib/*/*.h /sys/src/ape/lib/*/*/*.h
	/sys/src/ape/lib/9/libc.h:105: extern 	void *_MALLOCZ(int, int);
	/sys/src/ape/lib/9/libc.h:132: #define mallocz _MALLOCZ
	/sys/src/ape/lib/draw/libc.h:100: extern 	void *_MALLOCZ(int, int);
	/sys/src/ape/lib/draw/libc.h:127: #define mallocz _MALLOCZ
	/sys/src/ape/lib/mp/port/libc.h:14: extern	void*	mallocz(ulong, int);
	/sys/src/ape/lib/sec/port/libc.h:105: extern 	void *_MALLOCZ(int, int);
	/sys/src/ape/lib/sec/port/libc.h:132: #define mallocz _MALLOCZ

Note the libmp's one standing out.

A quick fix is to bring up mallocz bits in
/sys/src/ape/lib/mp/port/libc.h into agreement with the rest.

Replacing _MALLOCZ back with mallocz within APE realm seems to me a
better option to consider.

Comments are welcome.