Date: Sat, 20 Jan 2018 20:05:48 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Mark Millard <marklmi26-fbsd@yahoo.com>, FreeBSD Toolchain <freebsd-toolchain@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Attribute alloc__size use and clang 5.0.1 vs. gcc7 (e.g.): __builtin_object_size(p,1) and __builtin_object_size(p,3) disagreements result Message-ID: <8c4c5985-885a-abf7-93df-0698c645d36e@FreeBSD.org> In-Reply-To: <F227842D-6BE2-4680-82E7-07906AF61CD7@yahoo.com> References: <1AA0993D-81E4-4DC0-BBD9-CC42B26ADB1C@yahoo.com> <F227842D-6BE2-4680-82E7-07906AF61CD7@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Very interesting , thanks for running such tests ...
On 01/20/18 18:59, Mark Millard wrote:
> [Noting a typo in the program source, and
> so in the output text: the 2nd occurance of: "my_calloc_alt0
> should have been: "my_calloc_alt1
> . Hand edited corrections below for clarity.]
>
> On 2018-Jan-20, at 3:27 PM, Mark Millard <marklmi26-fbsd@yahoo.com> wrote:
>
>> [Bugzilla 225197 indirectly lead to this.
>> Avoiding continuing there.]
>>
>> I decided to compare some alternate uses of
>> __attribute__((alloc_size(. . .))) compiled
>> and run under clang 5.0.1 and gcc7. I did not
>> get what I expected based on prior discussion
>> material.
>>
>> This is an FYI since I do not know how important
>> the distinctions that I found are.
>>
>> Here is the quick program:
>>
>> # more alloc_size_attr_test.c
>> #include <stdlib.h>
>> #include <stdio.h>
>>
>> __attribute__((alloc_size(1,2)))
>> void* my_calloc_alt0(size_t n, size_t s)
>> {
>> void* p = calloc(n,s);
>> printf("calloc __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n"
>> ,(long) __builtin_object_size(p, 0)
>> ,(long) __builtin_object_size(p, 1)
>> ,(long) __builtin_object_size(p, 2)
>> ,(long) __builtin_object_size(p, 3)
>> );
>> return p;
>> }
>>
>> __attribute__((alloc_size(1))) __attribute__((alloc_size(2)))
>> void* my_calloc_alt1(size_t n, size_t s)
>> {
>> void* p = calloc(n,s);
>> printf("calloc __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n"
>> ,(long) __builtin_object_size(p, 0)
>> ,(long) __builtin_object_size(p, 1)
>> ,(long) __builtin_object_size(p, 2)
>> ,(long) __builtin_object_size(p, 3)
>> );
>> return p;
>> }
>>
>> int main()
>> {
>> void* p = my_calloc_alt0(2,7);
>> printf("my_calloc_alt0 __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n"
>> ,(long) __builtin_object_size(p, 0)
>> ,(long) __builtin_object_size(p, 1)
>> ,(long) __builtin_object_size(p, 2)
>> ,(long) __builtin_object_size(p, 3)
>> );
>> void* q = my_calloc_alt1(2,7);
>> printf("my_calloc_alt0 __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n"
> The above line should have been:
>
> printf("my_calloc_alt1 __builtin_object_size 0,1,2,3: %ld, %ld, %ld, %ld\n"
>
>> ,(long) __builtin_object_size(q, 0)
>> ,(long) __builtin_object_size(q, 1)
>> ,(long) __builtin_object_size(q, 2)
>> ,(long) __builtin_object_size(q, 3)
>> );
>> }
>>
>> # uname -apKU
>> FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r327485M amd64 amd64 1200054 1200054
>>
>> The system-clang 5.0.1 result was:
>>
>> # clang -O2 alloc_size_attr_test.c
> The later outputs are edited for clarity:
>
>> # ./a.out
>> calloc __builtin_object_size 0,1,2,3: 14, 14, 14, 0
>> my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 0
>> calloc __builtin_object_size 0,1,2,3: 14, 14, 14, 0
> my_calloc_alt1 __builtin_object_size 0,1,2,3: 14, 14, 14, 0
>> The lang/gcc7 result was:
>>
>> # gcc7 -O2 alloc_size_attr_test.c
>>
>> # ./a.out
>> calloc __builtin_object_size 0,1,2,3: -1, -1, 0, 0
>> my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 14
>> calloc __builtin_object_size 0,1,2,3: -1, -1, 0, 0
> my_calloc_alt1 __builtin_object_size 0,1,2,3: 14, 7, 14, 14
>> I'll ignore that gcc does not provide actual sizes
>> via __builtin_object_size for calloc use.
>>
>> Pairing the other lines for easy comparison, with
>> some notes mixed in:
>>
>> __attribute__((alloc_size(1,2))) style:
>> my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 (system clang)
>> my_calloc_alt0 __builtin_object_size 0,1,2,3: 14, 14, 14, 14 (gcc7)
>>
>> __attribute__((alloc_size(1))) __attribute__((alloc_size(2))) style:
> my_calloc_alt1 __builtin_object_size 0,1,2,3: 14, 14, 14, 0 (system clang)
> my_calloc_alt1 __builtin_object_size 0,1,2,3: 14, 7, 14, 14 (gcc7)
So on GCC7 it appears
__attribute__((alloc_size(1,2))) != __attribute__((alloc_size(1)))
__attribute__((alloc_size(2)))
This is not good as it was the base for r280801 .. related to the old
discussion about deprecating old compilers that don't accept VA_ARGS.
I am unsure if its a regression but it appears that for clang it is the
same thing though.
>> Thus. . .
>>
>> For __attribute__((alloc_size(1))) __attribute__((alloc_size(2))):
>> __builtin_object_size(p,1) is not equivalent (clang vs. gcc7)
>>
>> For both of the alloc_size usage styles:
>> __builtin_object_size(p,3) is not equivalent (clang vs. gcc7)
>>
>> This means that the two style of alloc_size use are not
>> equivalent across some major compilers/toolchains.
This is actually not a surprise: GCC and clang implementation of
__alloc_size__ has differences due to limitations on the LLVM IR (or the
fact there is one).
The alloc_size attribute is basically only used for the so-called
FORTIFY_SOURCE feature that depends on GCC with some support from the
C-library: last time I looked clang didn't support the compile-time
checks very well. The attributes are mostly unused in FreeBSD at this
time but, GCC7 -Walloc-size-larger-than=size depends on them (I have
never tested that though).
FWIW, we had an unfinished GSoC that attempted to implement
FORTIFY_SOURCE but we got stuck on the lack of clang support and other
issues. Lately Google has been spending some effort on it but it is more
limited and doesn't match the GCC behavior.
>> But I do not know if either of the differences is a problem or
>> not.
>>
>>
>> Note: without a sufficient -O<?> all the figures can be
>> the mix of -1's and 0's.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( markmi at dsl-only.net is
> going away in 2018-Feb, late)
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8c4c5985-885a-abf7-93df-0698c645d36e>