This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
[RFC] std::vector and std::string ASan annotations design
- From: Ivan Baravy <i dot baravy at samsung dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: 'Maksim Ostapenko' <m dot ostapenko at samsung dot com>
- Date: Tue, 24 Jan 2017 20:14:03 +0300
- Subject: [RFC] std::vector and std::string ASan annotations design
- Authentication-results: sourceware.org; auth=none
- Cms-type: 201P
- References: <CGME20170124171405eucas1p2e0cac2c1cc388e57f403857cf79cd24f@eucas1p2.samsung.com>
Hello,
libc++ has a feature of ASan annotations inside std::vector [1,2] and
std::string [3]. These make it possible to detect container overflows,
i.e. accesses between its size and capacity. I also noticed similar
approach to libstdc++ [4], unfinished though. I really like the idea to
have this feature in libstdc++ and I prepared patches providing the
annotations mostly based on libc++ code. However, while this development
I faced a design issue I want to discuss with you.
In libc++, all the string's API functions are defined in corresponding
header file. This allows ASan annotations to be placed there (and only
there) and thus not affect dso binary. In libstdc++, instead,
basic_string.h has both definitions and declarations of public API
functions. Therefore I had to put some ASan annotations into
basic_string.tcc file which becomes a part of libstdc++ binary.
As a result,
- Sanitized applications require sanitized libstdc++ to run, and vice
versa;
- Sanitized libstdc++ requires all applications and libraries using
std::string to be sanitized.
The only solution I see for now is to move definitions into
basic_string.h in libc++ manner. However this is not acceptable for
upstream, I assume, which is my aim. Could you suggest a better solution
or give me any pointers on the issue?
Thank you.
Regards,
Ivan
[1]
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20140505/104822.html
[2]
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20140901/113973.html
[3] https://reviews.llvm.org/D12577
[4] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=207517