Re: [RFC PATCH v2 6/8] tools/nolibc/stdlib: Implement `malloc()`, `calloc()`, `realloc()` and `free()`

[Willy Tarreau <w@1wt.eu>]

On Tue, Mar 22, 2022 at 11:52:43AM +0000, David Laight wrote:
> > +struct nolibc_heap {
> > +	size_t	len;
> > +	char	user_p[] __attribute__((__aligned__));
> 
> Doesn't that need (number) in the attribute?

That was my question in the previous review but Ammar pointed me to
the doc indicating that without value it's "large enough for any type"
(i.e. the usual double-long stuff). So that's fine.

> > +static __attribute__((unused))
> > +void *malloc(size_t len)
> > +{
> > +	struct nolibc_heap *heap;
> 
> If you do (say):
> 	len = ROUNDUP(len + sizeof *heap, 4096)
> you can optimise a lot of the realloc() calls.

Could be, but do we *really* care ? Again, I didn't even intend to
implement dynamic allocation at all for the targetted use cases.

> I actually wonder if compiling a mini-libc.a
> and then linking the programs against it might
> be better than all these static functions?
> -ffunction-sections can help a bit (where supported).

That was really not the intent when I started this project this
a few years ago. Instead the purpose precisely was *not* to have
to depend on any pre-compiled stuff and it seems a few of us find
this lack of dependency convenient. Right now using bare-metal
compilers from kernel.org/pub/tools/crosstool works out of the
box and is very convenient for testing and for pre-init stuff; if
the compiler can build the kernel, it can also build your userland
code.

Willy