This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] track dynamic allocation in strlen (PR 91582)
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: Martin Sebor <msebor at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 30 Nov 2019 17:31:25 +0100
- Subject: Re: [PATCH] track dynamic allocation in strlen (PR 91582)
- References: <081f0235-96b3-988b-5605-ed5a0805b3c7@gmail.com>
On Tue, 12 Nov 2019 at 02:28, Martin Sebor <msebor@gmail.com> wrote:
>
> The attached patch extends the strlen pass to detect out-of-bounds
> accesses to memory allocated by calls to other allocation functions
> besides calloc and malloc, as well as VLAs, and user-defined
> functions declared with attribute alloc_size. There is some
> overlap with the _FORTIFY_SOURCE detection but thanks to
> the extensive use of ranges, this enhancement detects many more
> cases of overflow.
>
> The solution primarily improves warnings but some of the changes
> also improve codegen in some cases as a side-effect. I hope to
> take better advantage of the optimization opportunities the dynamic
> memory tracking opens up (and also better buffer overflow and array
> out-of-bounds detection) in GCC 11.
>
> Although the strlen pass already tracks some dynamic memory calls
> (calloc and malloc) rather than extending the same infrastructure
> (strinfo::stmt) to others I took the approach of adding a separate
> data member for the other calls (strinfo::alloc) and tracking those
> independently. I did this to keep the changes only minimally
> intrusive. In the future (post GCC 10) it might be worth
> considering merging both.
>
> Besides introducing the new member and making use of it, the rest
> of the changes were prompted by weaknesses exposed by test cases
> involving dynamically allocated objects.
>
> The patch is intended to apply on top of the two related patches
> posted last week ([1] and [2]). For all tests to pass also expects
> the fix for PR 92412 posted earlier today ([3]).
>
> Martin
Hi Martin,
The new tests gcc.dg/Wstringop-overflow-23.c and gcc.dg/Wstringop-overflow-24.c
fail on arm-eabi (they pass on arm*-linux-gnueabi*):
FAIL: gcc.dg/Wstringop-overflow-23.c (test for excess errors)
Excess errors:
/gcc/testsuite/gcc.dg/Wstringop-overflow-23.c:174:25: warning: passing
argument 4 of 'pfwr4_3' from incompatible pointer type
[-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/Wstringop-overflow-23.c:175:25: warning: passing
argument 4 of 'pfwr4_3' from incompatible pointer type
[-Wincompatible-pointer-types]
FAIL: gcc.dg/Wstringop-overflow-24.c (test for excess errors)
Excess errors:
/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c:33:12: warning: passing
argument 1 of 'rd1_int' from incompatible pointer type
[-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c:35:12: warning: passing
argument 1 of 'rd1_int' from incompatible pointer type
[-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c:202:25: warning: passing
argument 4 of 'pfwr4_3' from incompatible pointer type
[-Wincompatible-pointer-types]
/gcc/testsuite/gcc.dg/Wstringop-overflow-24.c:203:25: warning: passing
argument 4 of 'pfwr4_3' from incompatible pointer type
[-Wincompatible-pointer-types]
I'm seeing that at r278638
Christophe
>
> [1] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00429.html
> [2] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html
> [3] https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00800.html