Re: [PATCH] arm64/io: Remind compiler that there is a memory side effect
On Sun, Apr 03, 2022 at 09:47:47AM +0200, Ard Biesheuvel wrote: > On Sun, 3 Apr 2022 at 09:47, Ard Biesheuvel wrote: > > On Sun, 3 Apr 2022 at 09:38, Andrew Pinski wrote: > > > It might not be the most restricted fix but it is a fix. > > > The best fix is to tell that you are writing to that location of memory. > > > volatile asm does not do what you think it does. > > > You didn't read further down about memory clobbers: > > > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Clobbers-and-Scratch-Registers > > > Specifically this part: > > > The "memory" clobber tells the compiler that the assembly code > > > performs memory reads or writes to items other than those listed in > > > the input and output operands > > > > > > > So should we be using "m"(*addr) instead of "r"(addr) here? > > > > (along with the appropriately sized casts) > > I mean "=m" not "m" That can generate writeback addressing modes, which I think breaks MMIO virtualisation. We usually end up using "Q" instead but the codegen tends to be worse iirc. In any case, for this specific problem I think we either need a fixed compiler or some kbuild magic to avoid using it / disable the new behaviour. We rely on 'asm volatile' not being elided in other places too. Will
GCC 12.0.1 Status Report (2022-04-04)
Status == The GCC development branch is in regression and documentation fixing mode (Stage 4) in preparation for the release of GCC 13. Re-opening of general development will happen once we reach zero P1 regressions which is when we branch for the release. Time wise history projects that to happen around end of April 2022. While we've made progress since mid January in the quest to squash P1 regressions and other important bugs there's still quite a bit of work ahead. Please look after bugs you have assigned to yourself that are blocking the release and consider helping out with looking after bugs that are in an area of the compiler where you'd be considered experienced. Again this is also the time to look after non-primary/secondary targets and ensure they build, install and work correctly. We will not hold off releasing with late discovered problems there. Quality Data Priority # Change from last report --- --- P1 23- 15 P2 387 + 77 P3 84- 202 P4 248 + 27 P5 25 --- --- Total P1-P3 494 - 140 Total 767 - 113 Previous Report === https://gcc.gnu.org/pipermail/gcc/2022-January/238136.html
Re: GSoC: Extending the Static Analysis Pass
On Sun, 2022-04-03 at 17:56 +0200, Tim Lange wrote: > Hi everyone, > Hi David, Hi Tim > > I'm interested in extending the static analysis pass as a GSoC > project. Excellent. > Short introduction of me: I'm Tim, currently doing my master in > computer science with focus on IT security at TU Darmstadt. I already > worked with IFDS as part of my bachelor thesis and took both program > analysis courses in my masters. I suspect you know much more about the theory than I do :) (my bachelor's degree only had an optional course on compilers, let alone static analysis) > > Specifically, I thought about extending the analyzer to check new > things i.e. the POSIX file-descriptor project. I would prefer a > medium-sized project, do you think this is doable? I think so. > > Also, I've read a bit through the internal documentation and got a > question. The documentation mostly mentions the Reps paper as the > source for the exploded supergraph. But the paper suggests more such > as > having extensional summaries that lead to the same context > sensitivity > as unbounded call-strings. In contrast, the documentation also talks > about being call-strings limited and searching for complex-enough > methods to be worth summarizing. > Do you only use the exploded supergraph idea but not the rest? > Otherwise why do you use call-strings and search for methods worth > summarizing? > I think I'm abusing the "exploded graph" terminology from the paper. As I understand the Reps et al paper, they're tracking quite fine- grained dataflow facts at their nodes, whereas the state objects in GCC's -fanalyzer are very coarse-grained, containing a blob of state: the store, tracking memory, a set of constraints, and a set of state- machine info. So I'm merely using "exploded graph" to express that I'm combining program points and program states into one graph-based representation, and that I'm using graph reachability - but I'm not doing the IFDS approach (or the "IDE" approach from the followup paper). As I understand things, the analyzer is using symbolic execution to try to explore a subset of the paths through the code, with some heuristics to try to explore the most "interesting" paths, eventually giving up when we hit complexity limits. My hope is that by focusing on specific states, that I can generate meaningful descriptions about what's going on to the end-user. The call summarization logic in the analyzer is very much just a placeholder right now; there's plenty of scope for improving it (which could itself be a GSoC project, but I think that one would be a large one). Hope this all makes sense, and that the analyzer sounds interesting; let me know if you have other questions. Dave > Best regards > Tim >
Re: GSoC: Working on the static analyzer
Hi David,
Sorry for such late reply. I've been busy with classes and exams.
As the contributor applications are opening, I would like to put forward a
proposal for a medium project for extending the static analyzer to work
with POSIX file descriptor APIs. As evident in this thread, I've been
interested in this project for quite some time, and have in fact written
some proof-of-concept code. I'm pretty much familiar with the parts of the
code base which are relevant for this project and am confident in
completing it in given time frame.
Do you have any inputs on how to start writing the proposal? Should I start
by reading the past year proposals?
Regards,
Immad MIr
On Mon, Feb 14, 2022 at 4:35 AM David Malcolm wrote:
> On Sun, 2022-02-13 at 17:57 -0500, David Malcolm wrote:
> > On Sun, 2022-02-13 at 21:16 +0530, Mir Immad wrote:
> > > Hi,
> > >
> > > I wanted some clarification on bifurcating the exploded graph at
> > > call
> > > to
> > > open().
> > > Should the analyzer warn for code like this "when open fails" (like
> > > strchr
> > > does when 'strchr' returns NULL)
> > >
> > > int fd = open("NOFILE", O_RDONLY);
> > > write(fd, "a", 1);
> > >
> > > because of the bad file descriptor.
> > > unless it is written like this:
> > > if (!errno)
> > > write(fd, "a", 1);
> >
> > "open" returns a non-negative integer on success, and returns -1 and
> > sets errno on an error. As I understand it, errno is never cleared
>
> "modified" would be a better word than "cleared" here, sorry
>
> Dave
>
> > unless an error occurs, so errno could already be set due to a prior
> > failure. Hence I believe the correct way to write such code is to
> > check fd for being -1, rather than checking errno.
> >
> > It's probably best to bifurcate the state at the open call, into
> > "success" and "failure" outcomes, so that we can track that the
> > caller
> > "owns" the filedescriptor on success, and thus we can complain about
> > fd
> > leaks on paths that discard the value without closing it.
> >
> > We can then warn if we see -1 passed as the fd value into "write",
> > since that implies that the open call failed. If we bifurcate the
> > state at the open call, then for:
> >
> > int fd = open("NOFILE", O_RDONLY);
> > write(fd, "a", 1);
> >
> > we'd have the execution paths:
> >
> > (a) "when 'open' succeeds" (setting fd to a conjured_svalue >=0, and
> > setting sm-state on that value)
> >
> > (b) "when 'open' fails" (setting fd to -1, and errno to a
> > conjured_svalue known to be nonzero)
> >
> > and at the call to "write" on path (b) we see the -1 passed to it,
> > and
> > can complain accordingly.
> >
> > I'm not sure if we also want to track that the file was O_RDONLY
> > (which
> > suggests that the "write" should fail), but that would be a nice
> > bonus.
> >
> > Hope this is helpful
> > Dave
> >
> >
> >
> > >
> > > Thank you.
> > >
> > > On Tue, Feb 1, 2022 at 8:28 PM Mir Immad
> > > wrote:
> > >
> > > > I worked around the leak detection and also handled the case
> > > > where
> > > > the fd
> > > > is not saved. I wonder why sm-file hasn't implemented it yet. I'm
> > > > attaching
> > > > a text file with analyzer warnings. I'm still on gcc-11.2.0, will
> > > > move to
> > > > v12 next thing.
> > > >
> > > > > I wonder if it's worth checking for attempts to write to a fd
> > > > > that
> > > > > was
> > > > > opened with O_RDONLY, or the converse?
> > > >
> > > > Yes, it does not make sense to warn for write on read-only closed
> > > > fd
> > > > or
> > > > converse. But, it does make sense to warn for write operation on
> > > > valid
> > > > read-only fd. For this, we might have to analyze calls to the
> > > > open()
> > > > carefully -- get the literal value of the second argument to the
> > > > call
> > > > and
> > > > do bit-mask decomposition on it to find if O_RDONLY or O_WRONLY
> > > > are
> > > > in it.
> > > > We might have to maintain separate vectors for these and check
> > > > for
> > > > them in
> > > > calls to write and read -- warn if write is being called on read-
> > > > only
> > > > fd
> > > > and converse. How do we equate them? Does gimple store unique ids
> > > > for
> > > > each
> > > > tree? or something like SAME_TREE? Just thinking out loud.
> > > >
> > > > > how much state does it make sense to track for a fd?
> > > > Sorry, I didnt get it. Do you mean how may states I'm using?
> > > > unchecked,
> > > > closed, null and leak_by_not_saved (for the call-tree that does
> > > > not
> > > > have a
> > > > lhs).
> > > >
> > > > > Also, at some point, we're going to have to handle "errno" -
> > > > > but
> > > > > given
> > > > > that might be somewhat fiddly it's OK to defer that until
> > > > > you're
> > > > > more
> > > > > familiar with the code
> > > >
> > > > I'm looking forward to figure it out.
> > > >
> > > > Thank you.
> > > >
> > > >
> > > > On Sat, Jan 29, 2022 at 11:09 PM David Malcolm <
> > > > dmalc...@redhat.com>
> > > > wrote:
> > > >
> > > > > On Sat, 2022-01-29 a
