public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug analyzer/106302] New: RFE: provide a way for -fanalyzer to use target flags
@ 2022-07-14 15:35 dmalcolm at gcc dot gnu.org
2022-11-02 15:12 ` [Bug analyzer/106302] " dmalcolm at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-07-14 15:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
Bug ID: 106302
Summary: RFE: provide a way for -fanalyzer to use target flags
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106003, 106301
Target Milestone: ---
As noted in the discussion here:
https://gcc.gnu.org/pipermail/gcc/2022-June/238954.html
-fanalyzer sometimes uses specific target flags when modeling the behavior of
functions, see e.g.: sm-fd.cc, which currently has:
enum access_mode
fd_state_machine::get_access_mode_from_flag (int flag) const
{
/* FIXME: this code assumes the access modes on the host and
target are the same, which in practice might not be the case. */
if ((flag & O_ACCMODE) == O_RDONLY)
{
return READ_ONLY;
}
else if ((flag & O_ACCMODE) == O_WRONLY)
{
return WRITE_ONLY;
}
return READ_WRITE;
}
where we are using the values of O_ACCMODE, O_RDONLY, and O_WRONLY from the
host's headers, rather than those of the target.
See also bug 106301, where properly supporting mmap would mean looking at
values of MAP_ANONYMOUS, and of the various PROT_ values.
Joseph suggested adding a target hook for this, though I think we'd need an
enum for it, so that we can add various different "well known" values that we'd
want to query for on the host. Alternatively, perhaps we could directly query
the preprocessor somehow, though that wouldn't work for the LTO case.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003
[Bug 106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106301
[Bug 106301] RFE: analyzer support of mmap
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug analyzer/106302] RFE: provide a way for -fanalyzer to use target flags
2022-07-14 15:35 [Bug analyzer/106302] New: RFE: provide a way for -fanalyzer to use target flags dmalcolm at gcc dot gnu.org
@ 2022-11-02 15:12 ` dmalcolm at gcc dot gnu.org
2022-11-15 18:59 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-11-02 15:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Last reconfirmed| |2022-11-02
Status|UNCONFIRMED |WAITING
--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Patch posted here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604739.html
Waiting on review for C frontend parts.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug analyzer/106302] RFE: provide a way for -fanalyzer to use target flags
2022-07-14 15:35 [Bug analyzer/106302] New: RFE: provide a way for -fanalyzer to use target flags dmalcolm at gcc dot gnu.org
2022-11-02 15:12 ` [Bug analyzer/106302] " dmalcolm at gcc dot gnu.org
@ 2022-11-15 18:59 ` cvs-commit at gcc dot gnu.org
2022-11-15 19:11 ` dmalcolm at gcc dot gnu.org
2022-11-28 22:20 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-15 18:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by David Malcolm <dmalcolm@gcc.gnu.org>:
https://gcc.gnu.org/g:d8aba860b34203621586df8c5a6756b18c2a0c32
commit r13-4073-gd8aba860b34203621586df8c5a6756b18c2a0c32
Author: David Malcolm <dmalcolm@redhat.com>
Date: Tue Nov 15 13:53:42 2022 -0500
c, analyzer: support named constants in analyzer [PR106302]
The analyzer's file-descriptor state machine tracks the access mode of
opened files, so that it can emit -Wanalyzer-fd-access-mode-mismatch.
To do this, its symbolic execution needs to "know" the values of the
constants "O_RDONLY", "O_WRONLY", and "O_ACCMODE". Currently
analyzer/sm-fd.cc simply uses these values directly from the build-time
header files, but these are the values on the host, not those from the
target, which could be different (PR analyzer/106302).
In an earlier discussion of this issue:
https://gcc.gnu.org/pipermail/gcc/2022-June/238954.html
we talked about adding a target hook for this.
However, I've also been experimenting with extending the fd state
machine to track sockets (PR analyzer/106140). For this, it's useful to
"know" the values of the constants "SOCK_STREAM" and "SOCK_DGRAM".
Unfortunately, these seem to have many arbitrary differences from target
to target.
For example: Linux/glibc general has SOCK_STREAM == 1, SOCK_DGRAM == 2,
as does AIX, but annoyingly, e.g. Linux on MIPS has them the other way
around.
It seems to me that as the analyzer grows more ambitious modeling of the
behavior of APIs (perhaps via plugins) it's more likely that the
analyzer will need to know the values of named constants, which might
not even exist on the host.
For example, at LPC it was suggested to me that -fanalyzer could check
rules about memory management inside the Linux kernel (probably via a
plugin), but doing so involves a bunch of GFP_* flags (see PR 107472).
So rather than trying to capture all this knowledge in a target hook,
this patch attempts to get at named constant values from the user's
source code.
The patch adds an interface for frontends to call into the analyzer as
the translation unit finishes. The analyzer can then call back into the
frontend to ask about the values of the named constants it cares about
whilst the frontend's data structures are still around.
The patch implements this for the C frontend, which looks up the names
by looking for named CONST_DECLs (which handles enum values). Failing
that, it attempts to look up the values of macros but only the simplest
cases are supported (a non-traditional macro with a single CPP_NUMBER
token). It does this by building a buffer containing the macro
definition and rerunning a lexer on it.
The analyzer gracefully handles the cases where named values aren't
found (such as anything more complicated than described above).
The patch ports the analyzer to use this mechanism for "O_RDONLY",
"O_WRONLY", and "O_ACCMODE". I have successfully tested my socket patch
to also use this for "SOCK_STREAM" and "SOCK_DGRAM", so the technique
seems to work.
gcc/ChangeLog:
PR analyzer/106302
* Makefile.in (ANALYZER_OBJS): Add analyzer/analyzer-language.o.
(GTFILES): Add analyzer/analyzer-language.cc.
* doc/analyzer.texi: Document __analyzer_dump_named_constant.
gcc/analyzer/ChangeLog:
PR analyzer/106302
* analyzer-language.cc: New file.
* analyzer-language.h: New file.
* analyzer.h (get_stashed_constant_by_name): New decl.
(log_stashed_constants): New decl.
* engine.cc (impl_run_checkers): Call log_stashed_constants.
* region-model-impl-calls.cc
(region_model::impl_call_analyzer_dump_named_constant): New.
* region-model.cc (region_model::on_stmt_pre): Handle
__analyzer_dump_named_constant.
* region-model.h
(region_model::impl_call_analyzer_dump_named_constant): New decl.
* sm-fd.cc (fd_state_machine::m_O_ACCMODE): New.
(fd_state_machine::m_O_RDONLY): New.
(fd_state_machine::m_O_WRONLY): New.
(fd_state_machine::fd_state_machine): Initialize the new fields.
(fd_state_machine::get_access_mode_from_flag): Use the new fields,
rather than using the host values.
gcc/c/ChangeLog:
PR analyzer/106302
* c-parser.cc: Include "analyzer/analyzer-language.h" and
"toplev.h".
(class ana::c_translation_unit): New.
(c_parser_translation_unit): Call ana::on_finish_translation_unit.
gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/analyzer-decls.h
(__analyzer_dump_named_constant): New decl.
* gcc.dg/analyzer/fd-4.c (void): Likewise.
(O_ACCMODE): Define.
* gcc.dg/analyzer/fd-access-mode-enum.c: New test, based on .
* gcc.dg/analyzer/fd-5.c: ...this. Rename to...
* gcc.dg/analyzer/fd-access-mode-macros.c: ...this.
(O_ACCMODE): Define.
* gcc.dg/analyzer/fd-access-mode-target-headers.c: New test, also
based on fd-5.c.
(test_sm_fd_constants): New.
* gcc.dg/analyzer/fd-dup-1.c (O_ACCMODE): Define.
* gcc.dg/analyzer/named-constants-via-enum.c: New test.
* gcc.dg/analyzer/named-constants-via-enum-and-macro.c: New test.
* gcc.dg/analyzer/named-constants-via-macros-2.c: New test.
* gcc.dg/analyzer/named-constants-via-macros.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug analyzer/106302] RFE: provide a way for -fanalyzer to use target flags
2022-07-14 15:35 [Bug analyzer/106302] New: RFE: provide a way for -fanalyzer to use target flags dmalcolm at gcc dot gnu.org
2022-11-02 15:12 ` [Bug analyzer/106302] " dmalcolm at gcc dot gnu.org
2022-11-15 18:59 ` cvs-commit at gcc dot gnu.org
@ 2022-11-15 19:11 ` dmalcolm at gcc dot gnu.org
2022-11-28 22:20 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2022-11-15 19:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
David Malcolm <dmalcolm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution|--- |FIXED
--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Implemented for GCC 13 by the above patch.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug analyzer/106302] RFE: provide a way for -fanalyzer to use target flags
2022-07-14 15:35 [Bug analyzer/106302] New: RFE: provide a way for -fanalyzer to use target flags dmalcolm at gcc dot gnu.org
` (2 preceding siblings ...)
2022-11-15 19:11 ` dmalcolm at gcc dot gnu.org
@ 2022-11-28 22:20 ` pinskia at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-11-28 22:20 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106302
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.0
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-11-28 22:20 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-14 15:35 [Bug analyzer/106302] New: RFE: provide a way for -fanalyzer to use target flags dmalcolm at gcc dot gnu.org
2022-11-02 15:12 ` [Bug analyzer/106302] " dmalcolm at gcc dot gnu.org
2022-11-15 18:59 ` cvs-commit at gcc dot gnu.org
2022-11-15 19:11 ` dmalcolm at gcc dot gnu.org
2022-11-28 22:20 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).