From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,NO_DNS_FOR_FROM, URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from [192.168.12.80] (unknown [182.2.69.4]) by gnuweeb.org (Postfix) with ESMTPSA id 7A33B7E2DA; Sun, 20 Mar 2022 16:36:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gnuweeb.org; s=default; t=1647794221; bh=7HDpyaqJ3Esg6x9zu/669IsMjA3/gjhXtFUxFcLvI2g=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=t/OJzLcPJ6palU0G8VBm8GL7mgyhaL4txMim5jjNoSSqxL+IHDtr9KTKTCFY3pajw boHc4Vs/H+D0WddZYUyGN98VqfBFrtB8eeKi/9oBKsu6Wgz0HgoQUW5/xqgXLHVhJg sangfkhey3/s3f7qGLgt5vdq83QQiB3222pw5lZpM1AYT1Y2rtroMdFY+YnQlzU6fo nJ1BTvZdtVKaz1x0n8tj9izDxMa4lasTqKhcgHU/I++Ss/FKyrylGxEZ2j9hQwrD1k erV9fk3ubqkvgPIORXHXwhI8eOY0Ub7x2OHrkPBzjVRUj747PFguEuvtO6X5xCg08H o/NV20RDq6loQ== Message-ID: Date: Sun, 20 Mar 2022 23:36:55 +0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US To: Willy Tarreau Cc: "Paul E. McKenney" , Alviro Iskandar Setiawan , Nugraha , Linux Kernel Mailing List , GNU/Weeb Mailing List References: <20220320093750.159991-1-ammarfaizi2@gnuweeb.org> <20220320093750.159991-6-ammarfaizi2@gnuweeb.org> <20220320161644.GF8067@1wt.eu> From: Ammar Faizi Subject: Re: [RFC PATCH v1 5/6] tools/nolibc/stdlib: Implement `malloc()`, `calloc()`, `realloc()` and `free()` In-Reply-To: <20220320161644.GF8067@1wt.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: On 3/20/22 11:16 PM, Willy Tarreau wrote: > Ammar, > > a few points below: > > On Sun, Mar 20, 2022 at 04:37:49PM +0700, Ammar Faizi wrote: >> +struct nolibc_heap { >> + size_t len; >> + char user_p[] __attribute__((__aligned__)); >> +}; > > Note that many programs assume that malloc() returns a field aligned > to 2*sizeof(pointer) and unless I'm mistaken, above the user pointer > will only be aligned by one pointer. This may have an impact when the > compiler decides to use SIMD instructions. Section 7.20.3 of C99 states this about `malloc()`: """ The pointer returned if the allocation succeeds is suitably aligned so that it may be assigned to a pointer to any type of object. """ And this is what GCC doc says about __attribute__((__aligned__)): """ The aligned attribute specifies a minimum alignment for the variable or structure field, measured in bytes. When specified, alignment must be an integer constant power of 2. Specifying no alignment argument implies the maximum alignment for the target, which is often, but by no means always, 8 or 16 bytes. """ Link: https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes Simple experiment on Linux x86-64... ``` ammarfaizi2@integral2:/tmp$ cat > test.c #include int main(void) { printf("alignof = %zu\n", __alignof__(long double)); return 0; } ammarfaizi2@integral2:/tmp$ gcc -o test test.c ammarfaizi2@integral2:/tmp$ ./test alignof = 16 ammarfaizi2@integral2:/tmp$ ``` We have `long double` which requires 16 byte alignment. So __attribute__((__aligned__)) should cover this. And yes, it's true that it's 2*sizeof(void*), but importantly for the above reason. >> +#ifndef offsetof >> +#define offsetof(TYPE, FIELD) ((size_t) &((TYPE *)0)->FIELD) >> +#endif >> + >> +#ifndef container_of >> +#define container_of(PTR, TYPE, FIELD) ({ \ >> + __typeof__(((TYPE *)0)->FIELD) *__FIELD_PTR = (PTR); \ >> + (TYPE *)((char *) __FIELD_PTR - offsetof(TYPE, FIELD)); \ >> +}) >> +#endif > > These ones are independent on the malloc code and should move to a > different patch and likely to a different file. I'm seeing we already > have a few macros in types.h and since it's shared by almost everything > it might be more suitable there. OK, will do it in the v2. Thanks! -- Ammar Faizi