[cfe-dev] cfe-dev Digest, Vol 80, Issue 91
Alangi Derick
alangiderick at gmail.com
Sat Feb 22 03:00:49 PST 2014
Hello
Fixes on three files: gcc.c, version.h, call.h
Index: gcc/gcc.c
===================================================================
--- gcc/gcc.c (revision 208009)
+++ gcc/gcc.c (working copy)
@@ -3108,8 +3108,21 @@
fputs (_(" -specs=<file> Override built-in specs with the
contents of <file>\n"), stdout);
fputs (_(" -std=<standard> Assume that the input sources are
for <standard>\n"), stdout);
fputs (_("\
+ -combine Compiling multiple source files telling the
driver to pass\n\
+ all the source files to the compiler
at once (allowing IMA).\n\
+ Currently, the only language
supported is C.\n"), stdout);
+ fputs (_(" -ansi In C mode, support all ISO C90
programs. In C++ mode, \n\
+ remove GNU extensions that
conflict with ISO C++. Turns \n\
+ off certain features of
GCC that are incompatible with ISO C90 \n\
+ of standard C++ such as
'asm' and 'typeof' keyword and predefined\n\
+ macros such as 'unix' and
'var' that identify the type of system you are using.\n"), stdout);
+ fputs (_("\
--sysroot=<directory> Use <directory> as the root directory for
headers\n\
and libraries\n"), stdout);
+ fputs (_(" -w Inhibit all warning messages.\n"),
stdout);
+ fputs (_("\
+ -Q Makes the compiler print out each function name
as it is compiled,\n\
+ and print some statistics about each pass
when it finishes.\n"), stdout);
fputs (_(" -B <directory> Add <directory> to the compiler's
search paths\n"), stdout);
fputs (_(" -v Display the programs invoked by the
compiler\n"), stdout);
fputs (_(" -### Like -v but options quoted and
commands not executed\n"), stdout);
Index: gcc/version.h
===================================================================
--- gcc/version.h (revision 208009)
+++ gcc/version.h (working copy)
@@ -1,3 +1,24 @@
+/* Version of GCC compiler.
+ Copyright (C) 2004-2014 Free Software Foundation, Inc.
+ Contributed by Nathan Sidwell <nathan at codesourcery.com>
+ Re-implemented in C++ by Diego Novillo <dnovillo at google.com>
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify it under
+the terms of the GNU General Public License as published by the Free
+Software Foundation; either version 3, or (at your option) any later
+version.
+
+GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+WARRANTY; without even the implied warranty of MERCHANTABILITY or
+FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
+for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+<http://www.gnu.org/licenses/>. */
+
#ifndef GCC_VERSION_H
#define GCC_VERSION_H
extern const char version_string[];
Index: gcc/calls.h
===================================================================
--- gcc/calls.h (revision 208009)
+++ gcc/calls.h (working copy)
@@ -1,4 +1,4 @@
-/* Declarations anda data types for RTL call insn generation.
+/* Declarations and data types for RTL call insn generation.
Copyright (C) 2013-2014 Free Software Foundation, Inc.
This file is part of GCC.
On Sat, Feb 22, 2014 at 8:30 AM, <cfe-dev-request at cs.uiuc.edu> wrote:
> Send cfe-dev mailing list submissions to
> cfe-dev at cs.uiuc.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> or, via email, send a message with subject or body 'help' to
> cfe-dev-request at cs.uiuc.edu
>
> You can reach the person managing the list at
> cfe-dev-owner at cs.uiuc.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of cfe-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: CentOS 6 distro detection (Rafael Esp?ndola)
> 2. analyzer: invoking a single analyzer from the static analysis
> tools. (Michael Katelman)
> 3. Address sanitizer failures in readdir and statfs on Mac
> (Jason Haslam)
> 4. Re: Address sanitizer failures in readdir and statfs on Mac
> (Kostya Serebryany)
> 5. Re: Address sanitizer failures in readdir and statfs on Mac
> (Alexander Potapenko)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 21 Feb 2014 13:17:03 -0500
> From: Rafael Esp?ndola <rafael.espindola at gmail.com>
> To: Dmitri Shubin <sbn at tbricks.com>
> Cc: cfe-dev Developers <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] CentOS 6 distro detection
> Message-ID:
> <
> CAG3jReKsVa6WF9h1q8qw1bxw0MdMnXrcfPKjqty_od0caNWjcw at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> This should be refactored so that it looks like
>
> if (RHEL OR CentOS) {
> figure out the version.
> }
>
> instead of repeating the RHEL or CentOS check for each version.
>
>
> On 16 January 2014 01:42, Dmitri Shubin <sbn at tbricks.com> wrote:
> > Hi,
> >
> > Currently CentOS 6 isn't detected as RHEL6 linux distro.
> >
> > Fix:
> >
> > Index: lib/Driver/ToolChains.cpp
> > ===================================================================
> > --- lib/Driver/ToolChains.cpp (revision 199352)
> > +++ lib/Driver/ToolChains.cpp (working copy)
> > @@ -2294,7 +2294,8 @@
> > StringRef Data = File.get()->getBuffer();
> > if (Data.startswith("Fedora release"))
> > return Fedora;
> > - else if (Data.startswith("Red Hat Enterprise Linux") &&
> > + else if ((Data.startswith("Red Hat Enterprise Linux") ||
> > + Data.startswith("CentOS")) &&
> > Data.find("release 6") != StringRef::npos)
> > return RHEL6;
> > else if ((Data.startswith("Red Hat Enterprise Linux") ||
> >
> > Thanks!
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 21 Feb 2014 14:22:18 -0800
> From: Michael Katelman <katelman at gmail.com>
> To: cfe-dev at cs.uiuc.edu
> Subject: [cfe-dev] analyzer: invoking a single analyzer from the
> static analysis tools.
> Message-ID:
> <CAAn2fBAc1_U_BUR2=k+scVrzLZy0kM=
> C9YS3wQpX7exu+TuqHg at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I was wondering if someone might be able to help me with cleanly invoking a
> single analyzer from the static analysis tools.
>
> I am not sure what I need to do (or, should be doing instead) in a
> situation like the one below where I've got a header like stdio.h included
> (--analyze figures it out, but then it appears that I lose the ability to
> apply a single checker) :
>
> % ./Debug+Asserts/bin/clang -cc1 -analyze
> -analyzer-checker=core.DivideZero ./tmp/main.c
>
> ./tmp/main.c:1:10: fatal error: 'stdio.h' file not found
> #include <stdio.h>
> ^
> 1 error generated.
>
> % cat ./tmp /main.c
>
> #include <stdio.h>
>
> int main( int argc, char** argv){
> int x = 1;
> int y = 0;
>
> printf("%d\n", x / y);
>
> return 0;
> }
>
> Thanks!
>
> -Mike
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/4758437a/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Fri, 21 Feb 2014 15:39:46 -0700
> From: Jason Haslam <jason.haslam at gmail.com>
> To: cfe-dev <cfe-dev at cs.uiuc.edu>
> Subject: [cfe-dev] Address sanitizer failures in readdir and statfs on
> Mac
> Message-ID: <35DDBB07-4B09-41E1-BA18-97639B417AE0 at gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> I see address sanitizer failures with TOT clang in readdir_r on Mac OS
> 10.9 like the following:
>
> =================================================================
> ==61104==ERROR: AddressSanitizer: heap-buffer-overflow on address
> 0x11617988 at pc 0x7fff36a bp 0xbffc2698 sp 0xbffc2684
> WRITE of size 48830 at 0x11617988 thread T0
> #0 0x7fff369 in wrap_readdir_r
> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x12369)
> ...
> 0x11617988 is located 0 bytes to the right of 520-byte region
> [0x11617780,0x11617988)
> allocated by thread T0 here:
> #0 0x800ab1f in wrap_malloc
> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x1db1f)
> ...
> SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 wrap_readdir_r
> ...
> ==61104==ABORTING
>
> I get similar failures in statfs. Does anybody else see this? I got around
> these issues with the attached patch. Is there a better way to fix this
> without disabling these interceptors?
>
> Jason
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0002.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: asan-mavericks.diff
> Type: application/octet-stream
> Size: 1145 bytes
> Desc: not available
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0001.obj
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140221/f1919fe4/attachment-0003.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Sat, 22 Feb 2014 09:53:47 +0400
> From: Kostya Serebryany <kcc at google.com>
> To: Jason Haslam <jason.haslam at gmail.com>
> Cc: cfe-dev <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] Address sanitizer failures in readdir and
> statfs on Mac
> Message-ID:
> <CAN=
> P9pi1QR9-iXiRW4obvEFsahJ_96PMXJd0yQ4YCz8traF7eQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> +glider
> Are you certain that this is not a real bug in your code?
> Could you provide a minimal test case?
> Does test/asan/TestCases/Linux/interception_readdir_r_test.cc work on your
> machine?
> (or, simply, does 'make check-asan' work?)
>
> This might be something in 10.9 that has changed since 10.8.
> Afaict, we are still not testing asan on 10.9 (glider?)
> Could you please send a preprocessed source of a test calling readdir_r so
> that I can see the definition of struct dirent?
>
> Looking at your report I see:
> WRITE of size 48830 at 0x11617988 thread T0
> 0x11617988 is located 0 bytes to the right of 520-byte region
> [0x11617780,0x11617988)
>
> So, somewhere in your heap you've allocated 520 bytes of memory for dirent.
> Then our readdir_r interceptor does this:
> int res = REAL(readdir_r)(dirp, entry, result);
> if (!res) {
> COMMON_INTERCEPTOR_WRITE_RANGE(ctx, result, sizeof(*result));
> if (*result)
> COMMON_INTERCEPTOR_WRITE_RANGE(ctx, *result, (*result)->d_reclen);
> }
>
> Since we see "WRITE of size 48830", this is likely the second
> "COMMON_INTERCEPTOR_WRITE_RANGE"
> with d_reclen=48830. That's quite unexpected I think.
>
> --kcc
>
>
>
>
> On Sat, Feb 22, 2014 at 2:39 AM, Jason Haslam <jason.haslam at gmail.com
> >wrote:
>
> > I see address sanitizer failures with TOT clang in readdir_r on Mac OS
> > 10.9 like the following:
> >
> > =================================================================
> > *==61104==ERROR: AddressSanitizer: heap-buffer-overflow on address
> > 0x11617988 at pc 0x7fff36a bp 0xbffc2698 sp 0xbffc2684*
> > *WRITE of size 48830 at 0x11617988 thread T0*
> > #0 0x7fff369 in wrap_readdir_r
> >
> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x12369)
> > ...
> > *0x11617988 is located 0 bytes to the right of 520-byte region
> > [0x11617780,0x11617988)*
> > *allocated by thread T0 here:*
> > #0 0x800ab1f in wrap_malloc
> >
> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x1db1f)
> > ...
> > SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 wrap_readdir_r
> > ...
> > ==61104==ABORTING
> >
> > I get similar failures in statfs. Does anybody else see this? I got
> around
> > these issues with the attached patch. Is there a better way to fix this
> > without disabling these interceptors?
> >
> > Jason
> >
> >
> >
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140222/68a8abeb/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Sat, 22 Feb 2014 11:30:53 +0400
> From: Alexander Potapenko <glider at google.com>
> To: Kostya Serebryany <kcc at google.com>
> Cc: clang-dev Developers <cfe-dev at cs.uiuc.edu>
> Subject: Re: [cfe-dev] Address sanitizer failures in readdir and
> statfs on Mac
> Message-ID:
> <CAG_fn=X1=
> Y+CiSPgfq4tAzxB2pp2USO0S2gZQV-Myb8XUkdJ2w at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> We're running ASan tests on 10.9, but IIRC Chrome bots are still on 10.8.
> However I doubt there's much difference between these two OSX versions.
> On Feb 22, 2014 9:53 AM, "Kostya Serebryany" <kcc at google.com> wrote:
>
> > +glider
> > Are you certain that this is not a real bug in your code?
> > Could you provide a minimal test case?
> > Does test/asan/TestCases/Linux/interception_readdir_r_test.cc work on
> your
> > machine?
> > (or, simply, does 'make check-asan' work?)
> >
> > This might be something in 10.9 that has changed since 10.8.
> > Afaict, we are still not testing asan on 10.9 (glider?)
> > Could you please send a preprocessed source of a test calling readdir_r
> so
> > that I can see the definition of struct dirent?
> >
> > Looking at your report I see:
> > WRITE of size 48830 at 0x11617988 thread T0
> > 0x11617988 is located 0 bytes to the right of 520-byte region
> > [0x11617780,0x11617988)
> >
> > So, somewhere in your heap you've allocated 520 bytes of memory for
> > dirent.
> > Then our readdir_r interceptor does this:
> > int res = REAL(readdir_r)(dirp, entry, result);
> > if (!res) {
> > COMMON_INTERCEPTOR_WRITE_RANGE(ctx, result, sizeof(*result));
> >
> > if (*result)
> > COMMON_INTERCEPTOR_WRITE_RANGE(ctx, *result, (*result)->d_reclen);
> > }
> >
> > Since we see "WRITE of size 48830", this is likely the second
> > "COMMON_INTERCEPTOR_WRITE_RANGE"
> > with d_reclen=48830. That's quite unexpected I think.
> >
> > --kcc
> >
> >
> >
> >
> > On Sat, Feb 22, 2014 at 2:39 AM, Jason Haslam <jason.haslam at gmail.com
> >wrote:
> >
> >> I see address sanitizer failures with TOT clang in readdir_r on Mac OS
> >> 10.9 like the following:
> >>
> >> =================================================================
> >> *==61104==ERROR: AddressSanitizer: heap-buffer-overflow on address
> >> 0x11617988 at pc 0x7fff36a bp 0xbffc2698 sp 0xbffc2684*
> >> *WRITE of size 48830 at 0x11617988 thread T0*
> >> #0 0x7fff369 in wrap_readdir_r
> >>
> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x12369)
> >> ...
> >> *0x11617988 is located 0 bytes to the right of 520-byte region
> >> [0x11617780,0x11617988)*
> >> *allocated by thread T0 here:*
> >> #0 0x800ab1f in wrap_malloc
> >>
> (/Users/jason/llvm/build/release/lib/clang/3.5/lib/darwin/libclang_rt.asan_osx_dynamic.dylib+0x1db1f)
> >> ...
> >> SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 wrap_readdir_r
> >> ...
> >> ==61104==ABORTING
> >>
> >> I get similar failures in statfs. Does anybody else see this? I got
> >> around these issues with the attached patch. Is there a better way to
> fix
> >> this without disabling these interceptors?
> >>
> >> Jason
> >>
> >>
> >>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/attachments/20140222/3943cbc7/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
> End of cfe-dev Digest, Vol 80, Issue 91
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140222/6b84f743/attachment.html>
More information about the cfe-dev
mailing list