This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libsanitizer merge from upstream r208536


On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> On Thu, May 15, 2014 at 9:28 AM, Yury Gribov <y.gribov@samsung.com> wrote:
>> On 05/14/2014 08:51 AM, Konstantin Serebryany wrote:
>>>>
>>>> One theme I have been noticing in the libsanitizer code is that it has
>>>> all of the knowledge of glibc when it comes to syscalls but makes some
>>>> bad assumptions dealing with some structures.  For an example on MIPS
>>>> n64: stat and stat64 are different layout between user and kernel.
>>>> Don't ask, it is a historical mistake.
>>>>
>>>> Also it really forces target maintainers to maintain both glibc and
>>>> libsanitizer code.  ILP32 on aarch64 has some similar issues as x32
>>>> and MIPS n32.
>>>> Even Linus is pushing new 32bit targets to go the route of 64bit time
>>>> which is means libsanitizer code becomes even more complex.
>>>
>>>
>>> This is indeed a PITA.
>>> It is caused by our need to avoid even greater PITA of including
>>> system headers into the sanitizer files
>>> (we allow system #includes only in a handful of files).
>>
>>
>> Have you considered adding a configure-like step to your build process to
>> determine necessary sizes and then provide them to sanitizer files via some
>> config.h?
>
> No. We have to support too many build systems and hence do not want
> any configure step.
> All configuration has to be done in the sources.


I think  this argument is bogus.  Please do one build system and
support it.  Simple makefile and some scripts seems simple to support
so you don't need anything extra.

Thanks,
Andrew Pinski


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]