Re: Change in preprocessor behavior
On Tue, Jun 21, 2022 at 2:34 AM Dave Blanchard wrote: > > At some point between GCC 9 and GCC 12, the preprocessor started behaving > differently. Before if GCC were launched as /lib/cpp or /usr/bin/cpp (I > think) it would assume the user wanted to preprocess something and > automatically launch in preprocessor mode. Now the behavior has changed and > it just acts as the normal compiler. Can someone kindly point me to the patch > or commit where this feature was changed, and the rationale for doing so? > Thank you. It still does that for me. > ~/install/gcc-12/usr/local/bin/cpp t.c # 0 "t.c" # 0 "" # 0 "" ... maybe you can be more specific as to how you invoke 'cpp'. Did you build gcc yourself? What is the 'cpp' you invoke (is it maybe a script or a symlink?) Richard. > -- > Dave Blanchard
Re: Build of any gcc breaks on my sparc / illumos env
> As you can see, I use both illumos as and ld, but I also tried using gnu as > with the same result. I also tried using gnu ld (which is not recommended > on a sparc build, AFAIK), but that brought in different problems earlier. > Anyone can help? Using GNU as + Solaris ld is the recommended combination with recent versions of the compiler, but Solaris ld must be recent enough, otherwise building for sparc-sun-solaris2.11 probably does not work indeed. -- Eric Botcazou
Safer vararg calls
Hi, Looking for feedback on the adding new attribute to function calls that will help create safer vararg functions. Consider the case where a vararg function takes list of arguments of the same type. In my case, there are terminated with a sentinel of null. Char *result = delimitedstr(‘:’ “foo”, “bar”, “zoo”, NULL) ; The standard prototype is char * delimitedstr(char delim, char *p1…) ; Which will currently allow many incorrect calls: delimitedstr(‘:’, “foo”, 5, 7.3, ‘a’) ;// bad types + missing sentinel. The __attribute__((sentinel)) can force the last arg to be null. My proposal is to add new attribute ((va_vector)) that will add a check that all parameters in a vararg list match the typeof the last parameter. So that: __attribute__ ((va_typed)) delimitedstr(char delim, char *p1…) ; Will flag a call where any of the parameter after p1, is not a string. This can result in cleaner, safer code, without making the calling sequence more difficult, or modifying the behavior of the call. For Java developers, this is basically the same type checking provided by the as ‘datatype …’ (without the conversion into array). I am Looking for feedback, Pointers on how to implement, as I do not have experience with extending gcc. Yair
Re: Safer vararg calls
On Tue, 21 Jun 2022 at 11:17, Yair Lenga via Gcc wrote: > > Hi, > > Looking for feedback on the adding new attribute to function calls that will > help create safer vararg functions. > > Consider the case where a vararg function takes list of arguments of the same > type. In my case, there are terminated with a sentinel of null. > > Char *result = delimitedstr(‘:’ “foo”, “bar”, “zoo”, NULL) ; > > The standard prototype > is char * delimitedstr(char delim, char *p1…) ; > > Which will currently allow many incorrect calls: > delimitedstr(‘:’, “foo”, 5, 7.3, ‘a’) ;// bad types + missing sentinel. > > The __attribute__((sentinel)) can force the last arg to be null. > > My proposal is to add new attribute ((va_vector)) that will add a check that > all parameters in a vararg list match the typeof the last parameter. So that: "va_vector" is a bad name IMHO. It tells me nothing about what it means. Does it have something to do with SIMD vectors? > > __attribute__ ((va_typed)) delimitedstr(char delim, char *p1…) ; "va_typed" at least suggests something to do with types, but it doesn't tell me they have to be the same type. > > Will flag a call where any of the parameter after p1, is not a string. In your example NULL does not have the same type as the earlier arguments. You would have to write (char*)NULL to suppress a diagnostic. I also wonder how a mixture of char* and const char* arguments would be handled in your example. > > This can result in cleaner, safer code, without making the calling sequence > more difficult, or modifying the behavior of the call. > > For Java developers, this is basically the same type checking provided by the > as ‘datatype …’ (without the conversion into array). > > I am Looking for feedback, Pointers on how to implement, as I do not have > experience with extending gcc. > > Yair
GCC 10.4 Release Candidate available from gcc.gnu.org
The first release candidate for GCC 10.4 is available from https://gcc.gnu.org/pub/gcc/snapshots/10.4.0-RC-20220621/ ftp://gcc.gnu.org/pub/gcc/snapshots/10.4.0-RC-20220621/ and shortly its mirrors. It has been generated from git commit r10-10862-g3c390f4ad27c3d79fd1817276a6d3217fd9bfb51. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 10.4 on Tuesday, June 28th.
Re: Build of any gcc breaks on my sparc / illumos env
Well we got gcc's verbose but in the we need ld's. Should be something like -Wl,-v If someone actually knew offhand which linker script template of used in this cases it would help. I don't and always have to dig. --joel On Mon, Jun 20, 2022, 12:09 PM Gabriele Bulfon wrote: > Thanks! This is what I get adding "-v", and to me it's not telling > anything interesting, maybe you can see more than I can? > > Reading specs from > /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/specs > > COLLECT_GCC=/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/xgcc > > COLLECT_LTO_WRAPPER=/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/lto-wrapper > Target: sparc-sun-solaris2.11 > Configured with: > /data/sources/sonicle/xstream-userland-gate/components/gcc-6/gcc-6.5.0/configure > --prefix=/usr/gcc/6 --mandir=/usr/gcc/6/share/man --bindir=/usr/gcc/6/bin > --libdir=/usr/gcc/ > 6/lib --sbindir=/usr/gcc/6/sbin --infodir=/usr/share/info > --sysconfdir=/etc --without-gnu-as --with-as=/usr/bin/as > --build=sparc-sun-solaris2.11 --sbindir=/usr/gcc/6/bin --libdir=/usr/gcc/6/ > lib --libexecdir=/usr/gcc/6/lib --host sparc-sun-solaris2.11 --build > sparc-sun-solaris2.11 --target sparc-sun-solaris2.11 > --with-pkgversion='XStreamOS 6.5.0-XS-2' --with-bugurl=https://bugs. > xstreamos.org --enable-plugins --enable-objc-gc --enable-initfini-array > --enable-languages=c,c++,fortran,lto,objc --without-gnu-ld > --with-ld=/usr/bin/ld --with-build-time-tools=/usr/gnu/spar > c-sun-solaris2.11/bin --disable-libitm --without-gnu-as > --with-as=/usr/bin/as LDFLAGS=-R/usr/gcc/6/lib > Thread model: posix > gcc version 6.5.0 (XStreamOS 6.5.0-XS-2) > > COMPILER_PATH=/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/:/usr/ccs/bin/ > > LIBRARY_PATH=/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/:/lib/:/usr/lib/ > COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-B' > '/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc' > '-nostdinc++' '-L/data/sources/sonicle/old-xstream-userl > and-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src' > '-L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstd > c++-v3/src/.libs' > '-L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs' > '-B' '/usr/gcc/6/sparc-sun-solaris2.11 > /bin/' '-B' '/usr/gcc/6/sparc-sun-solaris2.11/lib/' '-isystem' > '/usr/gcc/6/sparc-sun-solaris2.11/include' '-isystem' > '/usr/gcc/6/sparc-sun-solaris2.11/sys-include' '-shared' '-nostdlib' '-L/ > data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs' > '-L/data/sources/sonicle/old-xstream-userland-gate/component > s/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src' > '-L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs' > '-L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc' > '-o' '.libs/libstdc++.so.6.0.22' '-mcpu=v9' > > /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc/collect2 > -V -G -dy -z text -M > /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/spa > rcv7/./gcc/libgcc-unwind.map -Y P,/usr/gcc/6/lib:/lib:/usr/lib -R > /usr/gcc/6/lib -L /usr/gcc/6/lib -Qy -o .libs/libstdc++.so.6.0.22 > -L/data/sources/sonicle/old-xstream-userland-gate/componen > ts/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src > -L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs > -L > /data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs > -L/data/sources/sonicle/old-xstream-userland-gate/components > /gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs > -L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/sr > c > -L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/src/.libs > -L/data/sources/sonicle/old-xstream-userland-gate/components/g > cc-6/build/sparcv7/./gcc > -L/data/sources/sonicle/old-xstream-userland-gate/components/gcc-6/build/sparcv7/./gcc > /usr/lib/crti.o /usr/lib/values-Xa.o > /data/sources/sonicle/old-xstream-userlan > d-gate/components/gcc-6/build/sparcv7/./gcc/crtbeginS.o > .libs/compatibility.o .libs/compatibility-debug_list.o > .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o > .libs/compatibil > ity-atomic-c++0x.o .libs/compatibility-thread-c++0x.o > .libs/compatibility-chrono.o .libs/compatibility-condvar.o -z allext
GCC 10.3.1 Status Report (2022-06-21), branch frozen for release
Status == The GCC 10 branch is frozen for the release of GCC 10.4 with a first release candidate published. All changes require release manager approval. Quality Data Priority # Change from last report --- --- P10 - 1 P2 409 + 2 P3 51 - 1 P4 204 P5 24 --- --- Total P1-P3 460 Total 688 Previous Report === https://gcc.gnu.org/pipermail/gcc/2022-June/23.html
Re: Change in preprocessor behavior
On Tue, 21 Jun 2022 09:28:00 +0200 Richard Biener wrote: > On Tue, Jun 21, 2022 at 2:34 AM Dave Blanchard wrote: > > > > At some point between GCC 9 and GCC 12, the preprocessor started behaving > > differently. Before if GCC were launched as /lib/cpp or /usr/bin/cpp (I > > think) it would assume the user wanted to preprocess something and > > automatically launch in preprocessor mode. Now the behavior has changed and > > it just acts as the normal compiler. Can someone kindly point me to the > > patch or commit where this feature was changed, and the rationale for doing > > so? Thank you. > > maybe you can be more specific as to how you invoke 'cpp'. Did you > build gcc yourself? What > is the 'cpp' you invoke (is it maybe a script or a symlink?) Oops, it looks like my script had accidentally overwritten 'cpp' with a symlink to gcc. Fixed that and it's working now. Thanks.
_Unwind_Resume() references in libgcc division functions
Hello,
I noticed that several division related routines provided by libgcc such
as __divdi3, __moddi3 and __umoddi3 have references to _Unwind_Resume
for the sparc-rtems target. For example:
.file "libgcc2.c"
! GNU C17 (GCC) version 13.0.0 20220621 (experimental) [master
r13-1187-gab981aab92c] (sparc-rtems6)
! compiled by GNU C version 12.1.1 20220517 [revision
325d82b08696da17fb26bd2e1b6ba607649357fb], GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3, isl version isl-0.16.1-GMP
! GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
! options passed: -msoft-float -mcpu=leon3 -g -g -g -O0 -O2 -O0
-fbuilding-libgcc -fno-stack-protector -fexceptions
-fnon-call-exceptions -fvisibility=hidden
.LLBE7:
.LLBE6:
! /home/EB/sebastian_h/src/gcc/libgcc/libgcc2.c:1225: w = __udivmoddi4
(uu.ll, vv.ll, (UDWtype *) 0);
.loc 1 1225 5
std %g2, [%fp-16] ! D.3900, w
! /home/EB/sebastian_h/src/gcc/libgcc/libgcc2.c:1226: if (c)
.loc 1 1226 6
ld [%fp-4], %g1! c, tmp284
cmp %g1, 0 ! tmp284,
be .LL25
nop!
b .LL28
nop!
.LL27:
mov %i0, %g1!, tmp283
mov %g1, %o0! D.3909,
.LLEHB2:
call_Unwind_Resume, 0
nop!,
.LL28:
Could someone please give me a hint, why the compiler generates this
code? I was unable to figure this out by looking at the pre-processed
code. I tried to reproduce it with a simple division by zero test case,
but this didn't work:
unsigned f(unsigned i)
{
return i / 0;
}
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
Re: _Unwind_Resume() references in libgcc division functions
On Tue, Jun 21, 2022 at 03:13:19PM +0200, Sebastian Huber wrote: > Hello, > > I noticed that several division related routines provided by libgcc such as > __divdi3, __moddi3 and __umoddi3 have references to _Unwind_Resume for the > sparc-rtems target. For example: That is because: ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),) # Provide default flags for compiling divmod functions, if they haven't been # set already by a target-specific Makefile fragment. LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions endif which is there so that e.g. Ada or other -fnon-call-exceptions languages can have properly working divisions. Jakub
Re: _Unwind_Resume() references in libgcc division functions
On 21/06/2022 15:24, Jakub Jelinek wrote: On Tue, Jun 21, 2022 at 03:13:19PM +0200, Sebastian Huber wrote: Hello, I noticed that several division related routines provided by libgcc such as __divdi3, __moddi3 and __umoddi3 have references to _Unwind_Resume for the sparc-rtems target. For example: That is because: ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),) # Provide default flags for compiling divmod functions, if they haven't been # set already by a target-specific Makefile fragment. LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions endif which is there so that e.g. Ada or other -fnon-call-exceptions languages can have properly working divisions. Thanks for the hint. It seems also the optimization level has an impact. The _Unwind_Resume dependency is only present if I use CFLAGS_FOR_TARGET="-O0 -g". -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/
[PATCH] static analysis support for posix file desccriptor APIs
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index b6dcc45a58a..04631f737ea 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1269,6 +1269,7 @@ ANALYZER_OBJS = \
analyzer/region-model-reachability.o \
analyzer/sm.o \
analyzer/sm-file.o \
+ analyzer/sm-fd.o \
analyzer/sm-malloc.o \
analyzer/sm-pattern-test.o \
analyzer/sm-sensitive.o \
diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt
index 23dfc797cea..d99acfbb069 100644
--- a/gcc/analyzer/analyzer.opt
+++ b/gcc/analyzer/analyzer.opt
@@ -54,6 +54,10 @@ The minimum number of supernodes within a function for
the analyzer to consider
Common Joined UInteger Var(param_analyzer_max_enodes_for_full_dump)
Init(200) Param
The maximum depth of exploded nodes that should appear in a dot dump
before switching to a less verbose format.
+Wanalyzer-double-close
+Common Var(warn_analyzer_double_close) Init(1) Warning
+Warn about code paths in which a file descriptor can be closed more than
once.
+
Wanalyzer-double-fclose
Common Var(warn_analyzer_double_fclose) Init(1) Warning
Warn about code paths in which a stdio FILE can be closed more than once.
@@ -66,6 +70,10 @@ Wanalyzer-exposure-through-output-file
Common Var(warn_analyzer_exposure_through_output_file) Init(1) Warning
Warn about code paths in which sensitive data is written to a file.
+Wanalyzer-file-descriptor-leak
+Common Var(warn_analyzer_file_descriptor_leak) Init(1) Warning
+Warn about code paths in which a file descriptor is not closed.
+
Wanalyzer-file-leak
Common Var(warn_analyzer_file_leak) Init(1) Warning
Warn about code paths in which a stdio FILE is not closed.
@@ -82,6 +90,14 @@ Wanalyzer-mismatching-deallocation
Common Var(warn_analyzer_mismatching_deallocation) Init(1) Warning
Warn about code paths in which the wrong deallocation function is called.
+Wanalyzer-mismatching-operation-on-file-descriptor
+Common Var(warn_analyzer_mismatching_operation_on_file_descriptor) Init(1)
Warning
+Warn about the code paths in which read on write-only file descriptor or
write on read-only file descriptor is called.
+
+Wanalyzer-possible-invalid-file-descriptor
+Common Var(warn_analyzer_possible_invalid_file_descriptor) Init(1) Warning
+warn about code paths in which a possibly invalid file descriptor is
passed to a must-be-a-valid file descriptor function argument.
+
Wanalyzer-possible-null-argument
Common Var(warn_analyzer_possible_null_argument) Init(1) Warning
Warn about code paths in which a possibly-NULL value is passed to a
must-not-be-NULL function argument.
@@ -90,6 +106,10 @@ Wanalyzer-possible-null-dereference
Common Var(warn_analyzer_possible_null_dereference) Init(1) Warning
Warn about code paths in which a possibly-NULL pointer is dereferenced.
+Wanalyzer-read-write-on-closed-file-descriptor
+Common Var(warn_analyzer_read_write_on_closed_file_descriptor) Init(1)
Warning
+Warn about code paths in which a read on write in performed on a closed
file descriptor.
+
Wanalyzer-unsafe-call-within-signal-handler
Common Var(warn_analyzer_unsafe_call_within_signal_handler) Init(1) Warning
Warn about code paths in which an async-signal-unsafe function is called
from a signal handler.
diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc
new file mode 100644
index 000..23e79e3e16a
--- /dev/null
+++ b/gcc/analyzer/sm-fd.cc
@@ -0,0 +1,697 @@
+/* FIXME: add copyright header. */
+
+#include "config.h"
+#include "system.h"
+#include "coretypes.h"
+#include "tree.h"
+#include "function.h"
+#include "basic-block.h"
+#include "gimple.h"
+#include "options.h"
+#include "diagnostic-path.h"
+#include "diagnostic-metadata.h"
+#include "function.h"
+#include "json.h"
+#include "analyzer/analyzer.h"
+#include "diagnostic-event-id.h"
+#include "analyzer/analyzer-logging.h"
+#include "analyzer/sm.h"
+#include "analyzer/pending-diagnostic.h"
+#include "analyzer/function-set.h"
+#include "analyzer/analyzer-selftests.h"
+#include "tristate.h"
+#include "selftest.h"
+#include "analyzer/call-string.h"
+#include "analyzer/program-point.h"
+#include "analyzer/store.h"
+#include "analyzer/region-model.h"
+
+#include
+#if ENABLE_ANALYZER
+
+namespace ana
+{
+
+namespace
+{
+class fd_state_machine : public state_machine
+{
+public:
+ fd_state_machine (logger *logger);
+
+ bool
+ inherited_state_p () const final override
+ {
+return false;
+ }
+
+ state_machine::state_t
+ get_default_state (const svalue *sval) const final override
+ {
+if (tree cst = sval->maybe_get_constant ())
+ {
+int val = TREE_INT_CST_LOW (cst);
+if (val < 0)
+ {
+return m_null;
+ }
+ }
+return m_start;
+ }
+
+ bool on_stmt (sm_context *sm_ctxt, const supernode *node,
+const gimple *stmt) const final override;
+
+ void on_condition (sm_context *sm_ctxt, const supernode *node,
+ const gimple *stmt, const svalue *lhs, const
tree_code op,
+ const svalue *rhs) const fi
Re: [PATCH] static analysis support for posix file desccriptor APIs
This is a patch for extending static analysis support for posix file descriptor APIs which is a part of my GSoC project. I've written a few testcases, which are all passing. There are a few TODOs like adding the copyright header and adding docs to gcc/doc/invoke.texi. I'm looking for suggestions for whether the names of warnings I have chosen are appropriate, and configuring my vsocde editor to follow the GNU coding conventions. - Immad
Re: [PATCH] static analysis support for posix file desccriptor APIs
Hi Immad, thanks for this patch. Overall, looks like you're making good progress. Various notes and nitpicks inline below, throughout... On Tue, 2022-06-21 at 22:00 +0530, Mir Immad wrote: [...snip...] > > diff --git a/gcc/analyzer/analyzer.opt b/gcc/analyzer/analyzer.opt > index 23dfc797cea..d99acfbb069 100644 > --- a/gcc/analyzer/analyzer.opt > +++ b/gcc/analyzer/analyzer.opt > @@ -54,6 +54,10 @@ The minimum number of supernodes within a function > for > the analyzer to consider > Common Joined UInteger Var(param_analyzer_max_enodes_for_full_dump) > Init(200) Param > The maximum depth of exploded nodes that should appear in a dot dump > before switching to a less verbose format. I'm not yet sure if this is a good idea, but I wonder if all of these warnings ought to have a "-Wanalyzer-fd-" prefix? "file-descriptor" is rather long, and the analyzer's warnings are already tending to be on the long side, and having a consistent prefix might make it easier for users to grok them. (though this feels like a "what color do we paint the bikeshed?" issue; see e.g. https://bikeshed.org/ ) > > +Wanalyzer-double-close > +Common Var(warn_analyzer_double_close) Init(1) Warning > +Warn about code paths in which a file descriptor can be closed more > than > once. ...so this could be Wanalyzer-fd-double-close > + > Wanalyzer-double-fclose > Common Var(warn_analyzer_double_fclose) Init(1) Warning > Warn about code paths in which a stdio FILE can be closed more than > once. > @@ -66,6 +70,10 @@ Wanalyzer-exposure-through-output-file > Common Var(warn_analyzer_exposure_through_output_file) Init(1) Warning > Warn about code paths in which sensitive data is written to a file. > > +Wanalyzer-file-descriptor-leak > +Common Var(warn_analyzer_file_descriptor_leak) Init(1) Warning > +Warn about code paths in which a file descriptor is not closed. ...and Wanalyzer-fd-leak > + > Wanalyzer-file-leak > Common Var(warn_analyzer_file_leak) Init(1) Warning > Warn about code paths in which a stdio FILE is not closed. > @@ -82,6 +90,14 @@ Wanalyzer-mismatching-deallocation > Common Var(warn_analyzer_mismatching_deallocation) Init(1) Warning > Warn about code paths in which the wrong deallocation function is > called. > > +Wanalyzer-mismatching-operation-on-file-descriptor > +Common Var(warn_analyzer_mismatching_operation_on_file_descriptor) > Init(1) > Warning > +Warn about the code paths in which read on write-only file descriptor > or > write on read-only file descriptor is called. Maybe: Wanalyzer-fd-access-mode-mismatch ? Lose the "the" in "the code paths", so maybe: "Warn about code paths in which a write is attempted on a read-only file descriptor, or vice- versa." > + > +Wanalyzer-possible-invalid-file-descriptor > +Common Var(warn_analyzer_possible_invalid_file_descriptor) Init(1) > Warning > +warn about code paths in which a possibly invalid file descriptor is > passed to a must-be-a-valid file descriptor function argument. > + Wanalyzer-fd-use-without-check ? FWIW I believe that this isn't strictly speaking a security issue, that if code blithely assumes the fd is open and then tries to read/write it, the access will fail with errno set to EBADF. But it seems worth warning for; code that doesn't bother implementing error-checking seems suspect to me. > > +Wanalyzer-read-write-on-closed-file-descriptor Maybe: Wanalyzer-fd-use-after-close ? > +Common Var(warn_analyzer_read_write_on_closed_file_descriptor) Init(1) > Warning > +Warn about code paths in which a read on write in performed on a > closed > file descriptor. Typo "read on write"; maybe replace with "Warn about code paths in which a file descriptor is used after being closed." ? [...snip...] > + > diff --git a/gcc/analyzer/sm-fd.cc b/gcc/analyzer/sm-fd.cc > new file mode 100644 > index 000..23e79e3e16a > --- /dev/null > +++ b/gcc/analyzer/sm-fd.cc > @@ -0,0 +1,697 @@ > +/* FIXME: add copyright header. */ Obviously the FIXME needs fixing :) > + > +#include "config.h" > +#include "system.h" > +#include "coretypes.h" > +#include "tree.h" > +#include "function.h" > +#include "basic-block.h" > +#include "gimple.h" > +#include "options.h" > +#include "diagnostic-path.h" > +#include "diagnostic-metadata.h" > +#include "function.h" > +#include "json.h" > +#include "analyzer/analyzer.h" > +#include "diagnostic-event-id.h" > +#include "analyzer/analyzer-logging.h" > +#include "analyzer/sm.h" > +#include "analyzer/pending-diagnostic.h" > +#include "analyzer/function-set.h" > +#include "analyzer/analyzer-selftests.h" > +#include "tristate.h" > +#include "selftest.h" > +#include "analyzer/call-string.h" > +#include "analyzer/program-point.h" > +#include "analyzer/store.h" > +#include "analyzer/region-model.h" > + > +#include Presumably you're including here for the definitions of O_RDONLY and O_WRONLY. As we discussed off-list, I think we want to avoid the use of the host's O_RDONLY and O_WRONLY in this file, as they might n
Re: [PATCH] static analysis support for posix file desccriptor APIs
On Tue, 21 Jun 2022, David Malcolm via Gcc wrote: > So ultimately that's something we want to fix, though exactly how, I'm > not quite sure; we presumably want to look up the target's definitions > of those macros - but I don't think the analyzer has access to the > cpp_reader instance from the frontend. Normally that would use a target hook to specify the values of those macros. The default would be the traditional Unix values of 0, 1, 2 for O_RDONLY, O_WRONLY, O_RDWR, while Hurd would need its own definition of the hook to use values 1, 2, 3 (I don't know if there are any non-Hurd systems not using the traditional values). -- Joseph S. Myers jos...@codesourcery.com
Narrowing down preprocessor-related potential defect
Hello folks,
I am not subscribed to this mailing list, so please address
responses directly to me.
I have a program that generates this error:
.c: In function ‘f0’:
.c:117:4: error: this ‘else’ clause does not guard...
[-Werror=misleading-indentation]
117 | //#endif //
|^~~~
.c:120:2: note: ...this statement, but the latter is misleadingly
indented as if it were guarded by the ‘else’
120 | }
| ^
cc1: all warnings being treated as errors
for this small snippet of code:
void *
f0(void *ip6hdr)
{
if (ip6hdr) {
//#ifdef KQD
// } else if (0) {
//#endif //
} else if (ip6hdr) {
} else {
}
return 0;
}
The failure was induced by a commit to a header file that is not
even directly included by this source file.
To produce the error the file must include a large swath of header
files (some part of FreeBSD, some proprietary). Additionally, the
failure is very, very sensitive to the contents of the source &
included header files.
Normally, to investigate a potential gcc defect, one would
preprocess the file and pare down the output. But, preprocessing
the input and compiling the preprocessed output causes the failure
to evaporate. This is probably because the standalone preprocessor
does not produce a verbatim rendering of the input sources.
Nevertheless, the preprocessed output, containing proprietary code,
is on the order of 80K lines, which is too large (IMHO) to submit
in a defect report. Consequently, I need to narrow this down
further. But, making progress beyond the current state is
challenging because the failure is very sensitive to the contents
of the input source, and header files are including other headers
to a depth of 13.
I am here to solicit ideas on how to further narrow this this
down. Is there any undocumented option that I can use to cause the
standalone preprocessor to produce output identical to input?
Note that '-traditional-cpp' does not work because some of the code
is not recognized (variadic macros, for example).
thutt
--
Re: Narrowing down preprocessor-related potential defect
On Tue, 21 Jun 2022 at 20:31, thutt--- via Gcc wrote: >I am here to solicit ideas on how to further narrow this this >down. Is there any undocumented option that I can use to cause the >standalone preprocessor to produce output identical to input? >Note that '-traditional-cpp' does not work because some of the code >is not recognized (variadic macros, for example). This seems off-topic for the gcc mailing list. It belongs on the gcc-help list. Have you tried not using a standalone preprocessor? The usual approach is to add -save-temps to the gcc invocation, so it leaves the preprocessed output in a separate .i file. N.B. it's a warning, not an error. You told GCC to turn that warning into an error.
Re: Narrowing down preprocessor-related potential defect
On Tue, 21 Jun 2022, 20:35 Jonathan Wakely, wrote: > On Tue, 21 Jun 2022 at 20:31, thutt--- via Gcc wrote: > >I am here to solicit ideas on how to further narrow this this > >down. Is there any undocumented option that I can use to cause the > >standalone preprocessor to produce output identical to input? > >Note that '-traditional-cpp' does not work because some of the code > >is not recognized (variadic macros, for example). > > This seems off-topic for the gcc mailing list. It belongs on the gcc-help > list. > > Have you tried not using a standalone preprocessor? > > The usual approach is to add -save-temps to the gcc invocation, so it > leaves the preprocessed output in a separate .i file. > > N.B. it's a warning, not an error. You told GCC to turn that warning > into an error. > GCC has a whole guide to test case reduction here: https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction I don't know how much will be applicable it usable in this instance.
Re: GCC 10.4 Release Candidate available from gcc.gnu.org
On 6/21/22 6:33 AM, Jakub Jelinek via Gcc wrote: The first release candidate for GCC 10.4 is available from https://gcc.gnu.org/pub/gcc/snapshots/10.4.0-RC-20220621/ ftp://gcc.gnu.org/pub/gcc/snapshots/10.4.0-RC-20220621/ and shortly its mirrors. It has been generated from git commit r10-10862-g3c390f4ad27c3d79fd1817276a6d3217fd9bfb51. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 10.4 on Tuesday, June 28th. I bootstrapped and tested the RC on powerpc64 BE on power 7 and 8 and LE on power 8, 9, and 10 and all went fine.
Re: Narrowing down preprocessor-related potential defect
Jonathan Wakely writes: > âs External Email > > On Tue, 21 Jun 2022 at 20:31, thutt--- via Gcc wrote: > >I am here to solicit ideas on how to further narrow this this > >down. Is there any undocumented option that I can use to cause the > >standalone preprocessor to produce output identical to input? > >Note that '-traditional-cpp' does not work because some of the code > >is not recognized (variadic macros, for example). > > This seems off-topic for the gcc mailing list. It belongs on the gcc-help > list. > > Have you tried not using a standalone preprocessor? I am not using a standalone preprocessor. Only using gcc directly to preprocess and compile the file results in the failure. > The usual approach is to add -save-temps to the gcc invocation, so it > leaves the preprocessed output in a separate .i file. This doesn't have a satisfactory outcome. The file is preprocessed and multiple spaces appear to be replaced with a single space. The resultant output has no tabs that are not in quoted strings. It is currently believed the failure is produced when a mix of tabs and spaces are present. > > N.B. it's a warning, not an error. You told GCC to turn that warning > into an error. I'm aware of that. We treat all warnings as errors. --
Re: [PATCH] static analysis support for posix file desccriptor APIs
On Tue, 2022-06-21 at 18:50 +, Joseph Myers wrote:
> On Tue, 21 Jun 2022, David Malcolm via Gcc wrote:
>
> > So ultimately that's something we want to fix, though exactly how,
> > I'm
> > not quite sure; we presumably want to look up the target's
> > definitions
> > of those macros - but I don't think the analyzer has access to the
> > cpp_reader instance from the frontend.
>
> Normally that would use a target hook to specify the values of those
> macros. The default would be the traditional Unix values of 0, 1, 2
> for
> O_RDONLY, O_WRONLY, O_RDWR, while Hurd would need its own definition of
> the hook to use values 1, 2, 3 (I don't know if there are any non-Hurd
> systems not using the traditional values).
I found that it's at least theoretically possible to access the
preprocessor from within the analyzer; e.g. given:
#define O_RDONLY 42
and then breaking in the debugger in ana::run_checkers:
(gdb) p cpp_lookup (parse_in, (unsigned char *)"O_RDONLY",
(size_t)strlen ("O_RDONLY"))
$1 = (cpp_hashnode *) 0x7fffea794248
(gdb) p *$1
$2 = {ident = {str = 0x7fffea7877d0 "O_RDONLY", len = 8, hash_value =
3761648590}, is_directive = 0, directive_index = 0, rid_code = 0, flags
= 0, type = NT_USER_MACRO, deferred = 0, value = {answers =
0x7fffea7a5480, macro = 0x7fffea7a5480, builtin = 3933885568, arg_index
= 21632}}
(gdb) p $1->value.macro.exp.tokens.type
$6 = CPP_NUMBER
(gdb) p $1->value.macro.exp.tokens.val.str
$7 = {len = 2, text = 0x3ec182b "42"}
so given the C/C++ FEs it might be possible for the analyzer to try to
lookup the value of O_RDONLY.
But I'm wary of this; e.g. the LTO case, and for non-trivial macro
definitions.
Joseph: is the target hook the way to go with this? Would it look
something like:
DEFHOOK (fd_access_mode, "FIXME", int (int))
taking the build configuration's O_ access mode, and returning the
target configurations's access mode (so e.g fd_access_mode (O_RDONLY)
would return the target's int) ?
Thanks
Dave
Re: [PATCH] static analysis support for posix file desccriptor APIs
On Tue, 21 Jun 2022, David Malcolm via Gcc wrote: > Joseph: is the target hook the way to go with this? Would it look > something like: > > DEFHOOK (fd_access_mode, "FIXME", int (int)) > > taking the build configuration's O_ access mode, and returning the > target configurations's access mode (so e.g fd_access_mode (O_RDONLY) > would return the target's int) ? I think it would probably take the GCC-specific READ_WRITE, READ_ONLY, WRITE_ONLY you suggested, rather than the host's O_*. (Consider that it might make sense in future to have checks for other O_* flags, some of which might not be supported on the host.) -- Joseph S. Myers jos...@codesourcery.com
Re: [RFC] analyzer: allocation size warning
On Sat Jun 18, 2022 at 12:13 AM CEST, David Malcolm wrote:
> On Fri, 2022-06-17 at 22:23 +0200, Tim Lange wrote:
> > On Fri, Jun 17, 2022 at 01:48:09PM -0400, David Malcolm wrote:
> > > On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote:
>
> [...snip...]
>
> > >
> >
> > I have resent the patch using git send-email as a reply to my original
> > message.
> > The new message looks properly formatted in the archive:
> > https://gcc.gnu.org/pipermail/gcc/2022-June/238911.html
>
> Thanks; that's *much* more readable.
>
>
> [...snip...]
>
> > >
> > >
> > >
> > > On symbolic buffer sizes:
> > > warning: Allocated buffer size is not a multiple of the pointee's
> > > size
> > > [CWE-131] [-Wanalyzer-allocation-size]
> > > 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3 }
> > > */
> > > | ^~~~
> > > ‘test_3’: event 1
> > > |
> > > | 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line malloc3
> > > }
> > > */
> > > | | ^~~~
> > > | | |
> > > | | (1) Allocation is incompatible with ‘int *’; either the
> > > allocated size is bogus or the type on the left-hand side is wrong
> > > |
> > >
> > >
> > > Is there location information for both the malloc and for the
> > > assignment, here?
> >
> > I'm not sure whether I understand your question but the warning is
> > emitted at the gcall* with a ssa var lhs and the call_fndecl on the
> > rhs.
> > I think that is enough to split that up into "(1) n + sizeof(int)
> > allocated here" and "(2) Allocation at (1) is incompatible with..."?
>
> Probably, yes.
>
> FWIW I wrote some more notes about the events in my reply to to your
> reply to Prathamesh, here:
> https://gcc.gnu.org/pipermail/gcc/2022-June/238917.html
>
> [...snip...]
>
> > >
> > > There are some things to discuss from my side:
> > > * The tests with the "toy re-implementation of CPython's object
> > > model"[2] fail due to a extra warning emitted. Because the analyzer
> > > can't know the calculation actually results in a correct buffer size
> > > when viewed as a string_obj later on, it emits a warning, e.g. at
> > > line
> > > 61 in data-model-5.c. The only mitigation would be to disable the
> > > warning for structs entirely. Now, the question is to rather have
> > > noise
> > > on these cases or disable the warning for structs entirely?
> > >
> > > Can you post the full warning please?
> >
> > /path/to/data-model-5.c: In function ‘alloc_obj’:
> > /path/to/data-model-5.c:61:31: warning: Allocated buffer size is not a
> > multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-size]
> > 61 | base_obj *obj = (base_obj *)malloc (sz);
> > | ^~~
> > ‘new_string_obj’: events 1-2
> > |
> > | 69 | base_obj *new_string_obj (const char *str)
> > | | ^~
> > | | |
> > | | (1) entry to ‘new_string_obj’
> > |..
> > | 75 | = (string_obj *)alloc_obj (&str_type, sizeof
> > (string_obj) + len + 1);
> > | |
> >
> > | | |
> > | | (2) calling ‘alloc_obj’ from
> > ‘new_string_obj’
> > |
> > +--> ‘alloc_obj’: events 3-4
> > |
> > | 59 | base_obj *alloc_obj (type_obj *ob_type, size_t sz)
> > | | ^
> > | | |
> > | | (3) entry to ‘alloc_obj’
> > | 60 | {
> > | 61 | base_obj *obj = (base_obj *)malloc (sz);
> > | | ~~~
> > | | |
> > | | (4) Allocation is
> > incompatible with ‘base_obj *’; either the allocated size is bogus or
> > the type on the left-hand side is wrong
> > |
> >
> > >
> > > These testcases exhibit a common way of faking inheritance in C, and
> > > I
> > > think it ought to be possible to support this in the warning.
> > >
> > > I thing what's happening is we have
> > >
> > > struct base
> > > {
> > > /* fields */
> > > };
> > >
> > > struct sub
> > > {
> > > struct base m_base;
> > > /* extra fields. */
> > > };
> > >
> > > struct base *construct_base (size_t sz)
> > > {
> > > struct base *p = (struct base *) malloc (sz);
> > >
> > > /* set up fields of base in p */
> > >
> > > return p;
> > > }
> > >
> > > Or is this on the interprocedural path as called with a specific
> > > sizeof
> > > for struct sub?
> >
> > At (4), it does not know that base_obj is later used as a "base
> > struct".
> > As it is called with sizeof(struct sub), my checker thinks the buffer
> > is
> > too large for one but too small for another base_obj.
> >
> > >
> > > Maybe we can special-case these by detecting where
Re: [RFC] analyzer: allocation size warning
On Tue, 2022-06-21 at 22:00 +0200, Tim Lange wrote:
> On Sat Jun 18, 2022 at 12:13 AM CEST, David Malcolm wrote:
> > On Fri, 2022-06-17 at 22:23 +0200, Tim Lange wrote:
> > > On Fri, Jun 17, 2022 at 01:48:09PM -0400, David Malcolm wrote:
> > > > On Fri, 2022-06-17 at 17:54 +0200, Tim Lange wrote:
> >
> > [...snip...]
> >
> > > >
> > >
> > > I have resent the patch using git send-email as a reply to my
> > > original
> > > message.
> > > The new message looks properly formatted in the archive:
> > > https://gcc.gnu.org/pipermail/gcc/2022-June/238911.html
> >
> > Thanks; that's *much* more readable.
> >
> >
> > [...snip...]
> >
> > > >
> > > >
> > > >
> > > > On symbolic buffer sizes:
> > > > warning: Allocated buffer size is not a multiple of the
> > > > pointee's
> > > > size
> > > > [CWE-131] [-Wanalyzer-allocation-size]
> > > > 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line
> > > > malloc3 }
> > > > */
> > > > | ^~~~
> > > > ‘test_3’: event 1
> > > > |
> > > > | 33 | int *ptr = malloc (n + sizeof(int)); /* { dg-line
> > > > malloc3
> > > > }
> > > > */
> > > > | | ^~~~
> > > > | | |
> > > > | | (1) Allocation is incompatible with ‘int *’; either the
> > > > allocated size is bogus or the type on the left-hand side is
> > > > wrong
> > > > |
> > > >
> > > >
> > > > Is there location information for both the malloc and for the
> > > > assignment, here?
> > >
> > > I'm not sure whether I understand your question but the warning
> > > is
> > > emitted at the gcall* with a ssa var lhs and the call_fndecl on
> > > the
> > > rhs.
> > > I think that is enough to split that up into "(1) n + sizeof(int)
> > > allocated here" and "(2) Allocation at (1) is incompatible
> > > with..."?
> >
> > Probably, yes.
> >
> > FWIW I wrote some more notes about the events in my reply to to
> > your
> > reply to Prathamesh, here:
> > https://gcc.gnu.org/pipermail/gcc/2022-June/238917.html
> >
> > [...snip...]
> >
> > > >
> > > > There are some things to discuss from my side:
> > > > * The tests with the "toy re-implementation of CPython's object
> > > > model"[2] fail due to a extra warning emitted. Because the
> > > > analyzer
> > > > can't know the calculation actually results in a correct buffer
> > > > size
> > > > when viewed as a string_obj later on, it emits a warning, e.g.
> > > > at
> > > > line
> > > > 61 in data-model-5.c. The only mitigation would be to disable
> > > > the
> > > > warning for structs entirely. Now, the question is to rather
> > > > have
> > > > noise
> > > > on these cases or disable the warning for structs entirely?
> > > >
> > > > Can you post the full warning please?
> > >
> > > /path/to/data-model-5.c: In function ‘alloc_obj’:
> > > /path/to/data-model-5.c:61:31: warning: Allocated buffer size is
> > > not a
> > > multiple of the pointee's size [CWE-131] [-Wanalyzer-allocation-
> > > size]
> > > 61 | base_obj *obj = (base_obj *)malloc (sz);
> > > | ^~~
> > > ‘new_string_obj’: events 1-2
> > > |
> > > | 69 | base_obj *new_string_obj (const char *str)
> > > | | ^~
> > > | | |
> > > | | (1) entry to ‘new_string_obj’
> > > |..
> > > | 75 | = (string_obj *)alloc_obj (&str_type, sizeof
> > > (string_obj) + len + 1);
> > > | |
> > >
> > > | | |
> > > | | (2) calling ‘alloc_obj’ from
> > > ‘new_string_obj’
> > > |
> > > +--> ‘alloc_obj’: events 3-4
> > > |
> > > | 59 | base_obj *alloc_obj (type_obj *ob_type,
> > > size_t sz)
> > > | | ^
> > > | | |
> > > | | (3) entry to ‘alloc_obj’
> > > | 60 | {
> > > | 61 | base_obj *obj = (base_obj *)malloc (sz);
> > > | | ~~~
> > > | | |
> > > | | (4) Allocation
> > > is
> > > incompatible with ‘base_obj *’; either the allocated size is
> > > bogus or
> > > the type on the left-hand side is wrong
> > > |
> > >
> > > >
> > > > These testcases exhibit a common way of faking inheritance in
> > > > C, and
> > > > I
> > > > think it ought to be possible to support this in the warning.
> > > >
> > > > I thing what's happening is we have
> > > >
> > > > struct base
> > > > {
> > > > /* fields */
> > > > };
> > > >
> > > > struct sub
> > > > {
> > > > struct base m_base;
> > > > /* extra fields. */
> > > > };
> > > >
> > > > struct base *construct_base (size_t sz)
> > > > {
> > > > struct base *p = (struct base *) malloc (sz);
> > > >
> > > > /* set up fields
