Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lib: libc: common: Export z_malloc_heap #79123

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion lib/libc/common/source/stdlib/malloc.c
Original file line number Diff line number Diff line change
Expand Up @@ -114,7 +114,7 @@ extern char _heap_sentry[];

# endif /* else ALLOCATE_HEAP_AT_STARTUP */

Z_LIBC_DATA static struct sys_heap z_malloc_heap;
Z_LIBC_DATA struct sys_heap z_malloc_heap;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand this can be useful for debugging purposes; but, this more or less creates an implicit contract between an internal implementation detail of common libc and whatever will be using this (another Zephyr component? user application?), and I anticipate we will be seeing bugs like "unresolved symbol z_malloc_heap" (or even worse "sys_heap_runtime_stats_get crashing because z_malloc_heap is no longer struct sys_heap") in the future if we do this.

I would say we should define and implement Zephyr-flavoured mallinfo with the fields we need if we want to make the internal heap stats available to the components external to the common libc; otherwise, patches/hacks like these should stay in one's local branch.


#ifdef CONFIG_MULTITHREADING
Z_LIBC_DATA SYS_MUTEX_DEFINE(z_malloc_heap_mutex);
Expand Down
Loading