Skip to content

Fix pal_memory.c on OpenBSD#125010

Open
sethjackson wants to merge 1 commit intodotnet:mainfrom
sethjackson:fix-pal-memory
Open

Fix pal_memory.c on OpenBSD#125010
sethjackson wants to merge 1 commit intodotnet:mainfrom
sethjackson:fix-pal-memory

Conversation

@sethjackson
Copy link
Contributor

OpenBSD does not have an implementation of MALLOC_SIZE so reuse the TARGET_SUNOS one.

#define MALLOC_SIZE(s) malloc_usable_size(s)
#elif defined(TARGET_SUNOS)
#elif defined(TARGET_OPENBSD) || defined(TARGET_SUNOS)
#define MALLOC_SIZE(s) (*((size_t*)(s)-1))
Copy link
Member

Choose a reason for hiding this comment

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

Does this implementation actually work on OpenBSD?

Copy link
Contributor Author

@sethjackson sethjackson Feb 28, 2026

Choose a reason for hiding this comment

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

Now that I look at it again - no I do not think it will at all.

I don't think there is any implementation of malloc_size that will work. A bit unsure how to proceed here?

Copy link
Member

Choose a reason for hiding this comment

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

This is only need for efficient implementation of aligned realloc. You should be able to provide less efficient implementation that does not depend on malloc_size

Copy link
Member

Choose a reason for hiding this comment

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

(Every C allocator has to know the size internally to support realloc. It is unfortunate that OpenBSD does not expose it as an API. they have it as an internal macro only https://github.com/libressl/openbsd/blob/master/src/lib/libc/stdlib/malloc.c#L328-L330 .)

Copy link
Member

@am11 am11 Mar 15, 2026

Choose a reason for hiding this comment

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

malloc_usable_size was removed from OpenBSD 6.5 onwards deemed harmful: libressl/openbsd@a945275. Both OpenBSD and illumos would need manual tracking like: main...am11:runtime:patch-50. (Note: "Solaris" hasmalloc_usable_size and cmake check detects it, but illumos dropped it after OpenBSD did; seldom these two (solaris,illumos) diverge).

Copy link
Member

Choose a reason for hiding this comment

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

Both OpenBSD and illumos would need manual tracking like: main...am11:runtime:patch-50.

The documentation says that AlignedAlloc is a thin wrapper over aligned_alloc It is intentionally speced that way to allow it to be used for interop (allocated in managed code and free in native code, and vice versa). Once you add your own tracking, it is no longer the case.

I do not think we need the tracking to implement this, albeit with some inefficiency.

void* SystemNative_AlignedRealloc(void* ptr, uintptr_t alignment, uintptr_t new_size)
{
    void* result = SystemNative_AlignedAlloc(alignment, new_size);
    if (result != NULL)
    {
#ifdef MALLOC_SIZE
        uintptr_t old_size = MALLOC_SIZE(ptr);
        assert((ptr != NULL) || (old_size == 0));

        uintptr_t size_to_copy = (new_size < old_size) ? new_size : old_size
#else
        // Less efficient implementation for platforms that do not provide MALLOC_SIZE.
        ptr = realloc(ptr, new_size);
        if (ptr == NULL)
        {
            SystemNative_AlignedFree(result);
            return NULL;
        }
        uintptr_t size_to_copy = new_size;
#endif

        memcpy(result, ptr, size_to_copy);
        SystemNative_AlignedFree(ptr);
    }

    return result;
}

@jkotas jkotas added the os-openbsd OpenBSD OS, currently not officially supported label Feb 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-PAL-coreclr community-contribution Indicates that the PR has been added by a community member os-openbsd OpenBSD OS, currently not officially supported

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants