GSoC 2021 project help

[Adharsh Kamath via Gcc]

Hi everyone
I came across the list of project ideas that were selected for GSoC 2020
and I'm interested in contributing to the project regarding the *Implementation
of OMPD in GCC, libgomp, and GDB. *
I was able to build GCC from source, as specified in the *Before you apply*
section.
Is this project going to be considered for GSoC 2021 as well?
How can I get started with this project? Can I contact the mentor who is
mentioned in the above project's description regarding this?

Thanks,
Adharsh

Re: GSoC 2021 project help

[Adharsh Kamath via Gcc]

Hi Martin,
Thank you very much for the detailed response.

On Tue, Dec 22, 2020 at 3:37 AM Martin Jambor  wrote:
>
> Hi Adharsh,
>
> I will be the GSoC organizer for GCC the next year (unless someone else
> wants to be).
>
> On Sun, Dec 20 2020, Adharsh Kamath via Gcc wrote:
> > Hi everyone
> > I came across the list of project ideas that were selected for GSoC 2020
> > and I'm interested in contributing to the project regarding the
*Implementation
> > of OMPD in GCC, libgomp, and GDB. *
>
> > Is this project going to be considered for GSoC 2021 as well?
>
> On one hand, I am very pleased that you are interested in a GCC GSoC
> program, on the other, I am worried about the project you picked because
> it is very difficult.  We had a student attempting it last year, which
> unfortunately failed, and in the process it became painfully clear just
> how tough it was for a newcomer.

I saw the conversations from previous editions of GSoC to get a better idea
of the project and what I could do to improve on that, and they gave me a
better understanding of what is expected from this project.

> Moreover, Google has shrunk the duration of GSoC this year, making it
> even more difficult to attempt such a big endeavor, and so I was not
> planning to keep it in the list of proposed projects for 2021.
>
> Having said that, if you managed to bring about some real progress with
> OMPD, it would have a big impact and would indeed be very welcome, so at
> least I am not dead set against considering it.  But you'll have to
> convince us you really understand what you are attempting.
>
> Do you have some rudimentary knowledge of OpenMP?  Have you looked at
> the OMPD part of the standard?  Do you feel you understand what its
> goals are?

Yes. I have completed Parallel computing, and Compiler design courses at my
university and OpenMP was a major portion of the Parallel computing course.
I also did a project earlier this summer, to generate OpenMP programs for
mathematical equations.
The code and results for that project can be found here -
https://github.com/adharshkamath/Mathy-Compiler
In addition to older GSoC conversations, I read the OMPD specification in
the OpenMP specification and that gave me a clearer idea of what an OMPD
implementation should do.
>From what I understood, the OMPD implementation (library) should be a
shared library that can be dlopen-ed by the debugger. This OMPD library
will provide an API that will be used by the debugger to access the state
of the OpenMP program.
However, the OMPD library itself will not access the state. Instead, it
will use functions provided by the debugger to do it.  Please correct me if
I'm wrong anywhere.

> > I was able to build GCC from source, as specified in the *Before you
apply*
> > section.
>
> This project would not deal so much with the compiler but mainly with
> the run-time OpenMP library libgomp, in the libgomp subdirectory of the
> GCC git repository.  At some point you'll have to familiarize yourself
> with it, so it might be a good way to start.

Since I had used OpenMP previously, seeing libgomp gave me a better idea
about the actual OpenMP implementation in GCC. Thank you for suggesting it.

> You can compile some simple OpenMP program with options
> -fopenmp -fdump-tree-optimized
> and the generated dump file should show you what the compiler did to the
> OpenMP directives and what are the entry points to the run-time library
> (for the pragmas used in the program).

In addition to the optimized tree, I examined other dumps like
gimple,omplower, and ompexp, which gave me an understanding of how the
compiler deals with OpenMP programs in multiple stages.

> > How can I get started with this project? Can I contact the mentor who is
> > mentioned in the above project's description regarding this?
>
> I believe you can, in fact I have CCed him on this email already.
> Jakub, what are your thoughts?  Can you think of some preliminary work
> for Adharsh so that he can get a taste of what he is up to, and so that
> we know whether he has a good chance of completing the project?  (And
> IMHO completing really means writing something substantial and useful.
> The entire OMPD is simply too large, I'm afraid).

I would love to do some preliminary work regarding this project to get a
better idea of how much I can contribute and accordingly prepare a timeline.

Thanks,
Adharsh

GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath via Gcc]

Hello,
I came across the list of possible project ideas for GSoC 2021 and I'd
like to contribute to the project regarding the static analysis pass
in GCC.
How can I get started with this project?

Thanks,
Adharsh

Re: GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath via Gcc]

Hi David. Thank you for the reply.
On Tue, Jan 19, 2021 at 2:12 AM David Malcolm  wrote:
>
> On Thu, 2021-01-14 at 10:45 +0530, Adharsh Kamath wrote:
> > Hello,
> > I came across the list of possible project ideas for GSoC 2021 and
> > I'd
> > like to contribute to the project regarding the static analysis pass
> > in GCC.
> > How can I get started with this project?
>
> Hi Adharsh
>
> Sorry about the delay in responding to your email.
>
> Thanks for your interest in the static analysis pass.
>
> Some ideas on getting started with GCC are here:
>   https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply
>
> The analyzer has its own wiki page here:
>   https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer

I examined the analyzer dumps for a few programs. I also read the
documentation on the internals of
the static analyzer and I've understood the basics of how the analyzer works.

> I've actually already implemented some of the ideas that were on the
> GSoC wiki page myself since last summer, so I've updated that page
> accordingly:
>   https://gcc.gnu.org/wiki/SummerOfCode?action=diff&rev2=187&rev1=184
> I've added the idea of SARIF ( https://sarifweb.azurewebsites.net/ ) as
> an output format for the static analyzer (and indeed, for the GCC
> diagnostics subsystem as a whole).
>
> Do any of the ideas on the page look appealing to you?  I'm open to
> other ideas you may have relating to the analyzer, or indeed to gcc
> diagnostics.

Yes. Making a plugin for the Linux kernel seems very interesting to me.
I'd also like to extend support for C++ but I'm not sure if both ideas would be
possible, given the time constraints. How do I start with the plugin for
the Linux kernel?

Thanks,
Adharsh

Re: GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath via Gcc]

On Fri, Jan 22, 2021 at 9:32 PM David Malcolm  wrote:
>
> On Fri, 2021-01-22 at 20:46 +0530, Adharsh Kamath wrote:
> > Hi David. Thank you for the reply.
> > On Tue, Jan 19, 2021 at 2:12 AM David Malcolm 
> > wrote:
> > > On Thu, 2021-01-14 at 10:45 +0530, Adharsh Kamath wrote:
> > > > Hello,
> > > > I came across the list of possible project ideas for GSoC 2021
> > > > and
> > > > I'd
> > > > like to contribute to the project regarding the static analysis
> > > > pass
> > > > in GCC.
> > > > How can I get started with this project?
> > >
> > > Hi Adharsh
> > >
> > > Sorry about the delay in responding to your email.
> > >
> > > Thanks for your interest in the static analysis pass.
> > >
> > > Some ideas on getting started with GCC are here:
> > >   https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply
> > >
> > > The analyzer has its own wiki page here:
> > >   https://gcc.gnu.org/wiki/DavidMalcolm/StaticAnalyzer
> >
> > I examined the analyzer dumps for a few programs. I also read the
> > documentation on the internals of
> > the static analyzer and I've understood the basics of how the
> > analyzer works.
>
> Excellent.  Building GCC from source and stepping through it in the
> debugger would be good next steps.  You'll need plenty of disk space.
>  "run_checkers" is a good breakpoint to set if you're looking for the
> entrypoint to the analyzer.

Yes, I'll try this.

> > > I've actually already implemented some of the ideas that were on
> > > the
> > > GSoC wiki page myself since last summer, so I've updated that page
> > > accordingly:
> > >
> > > https://gcc.gnu.org/wiki/SummerOfCode?action=diff&rev2=187&rev1=184
> > > I've added the idea of SARIF ( https://sarifweb.azurewebsites.net/
> > > ) as
> > > an output format for the static analyzer (and indeed, for the GCC
> > > diagnostics subsystem as a whole).
> > >
> > > Do any of the ideas on the page look appealing to you?  I'm open to
> > > other ideas you may have relating to the analyzer, or indeed to gcc
> > > diagnostics.
> >
> > Yes. Making a plugin for the Linux kernel seems very interesting to
> > me.
> > I'd also like to extend support for C++ but I'm not sure if both
> > ideas would be
> > possible, given the time constraints.
>
> I think that picking just one would be better than trying to do both.
>
> > How do I start with the plugin for
> > the Linux kernel?
>
> I added plugin support to the analyzer in:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=66dde7bc64b75d4a338266333c9c490b12d49825
>
> There's an example plugin in that patch.  The kernel source tree
> already has some plugins, so hopefully those together give some
> pointers on how to write a "hello world" analyzer plugin that runs as
> part of the kernel build, which would be another next step, I guess.

I will go through the plugin in the kernel source tree and try to write a simple
analyzer plugin.

> Unfortunately I'm not a Linux kernel developer, so I don't have deep
> knowledge of what checks would be useful and the subtle details that
> are likely to be necessary.  I'll try to reach out internally within
> Red Hat - we have plenty of kernel developers here.
>
> Some ideas:
> * detecting code paths that acquire a lock but then fail to release it
> * detecting code paths that disable interrupts and then fail to re-
> enable them
> * detecting mixups between user-space pointers and kernel-space
> pointers
>
> The kernel has its own checker called "smatch" which may give other
> ideas for warnings.
>
> The state machine checker in the analyzer takes its inspiration from
> the Stanford "MC" checker (among other places, such as typestate),
> which has been used to implement warnings for the Linux kernel, albeit
> some very old versions of the kernel.
>
> See::
>   * "How to write system-specific, static checkers in Metal" (Benjamin
> Chelf, Dawson R Engler, Seth Hallem), from 2002
>   * "Checking system rules using system-specific, programmer-written
> compiler extensions" Proceedings of Operating Systems Design and
> Implementation (OSDI), September 2000. D. Engler, B. Chelf, A. Chou,
> and S. Hallem.
>   * "Using Programmer-Written Compiler Extensions to Catch Security
> Holes" (Ken Ashcraft, Dawson Engler) from 2002
>
> These are working on 20-year-old in-kernel APIs that might be obsolete
> now, but they have examples of interrupt checking, and user-space vs
> kernel-space pointer checking.
>
> Focusing on error-handling paths in driver code might be best.
>
> Does this answer your questions?

Yes. Thank you very much for these resources. I will go through them.

Adharsh

Re: GCC GSoC 2021 - Static analyzer project

[Adharsh Kamath via Gcc]

Hi David,

> Building GCC from source and stepping through it in the
> debugger would be good next steps.  You'll need plenty of disk space.
>  "run_checkers" is a good breakpoint to set if you're looking for the
> entrypoint to the analyzer.
>

I tried this and I understood the control flow in the analyzer.

> There's an example plugin in that patch.  The kernel source tree
> already has some plugins, so hopefully, those together give some
> pointers on how to write a "hello world" analyzer plugin that runs as
> part of the kernel build, which would be another next step, I guess.
>

I implemented a very simple hello world plugin here -
https://github.com/adharshkamath/Hello-world-plugin.

It just prints a Hello message while building the Linux Kernel, if the
-fanalyzer option is enabled. I referred to the example plugin in the
static analyzer
and the plugins in the kernel source to do this.

> See::
>   * "How to write system-specific, static checkers in Metal" (Benjamin
> Chelf, Dawson R Engler, Seth Hallem), from 2002
>   * "Checking system rules using system-specific, programmer-written
> compiler extensions" Proceedings of Operating Systems Design and
> Implementation (OSDI), September 2000. D. Engler, B. Chelf, A. Chou,
> and S. Hallem.
>   * "Using Programmer-Written Compiler Extensions to Catch Security
> Holes" (Ken Ashcraft, Dawson Engler) from 2002
>

These were useful and interesting to read. Thank you for suggesting them.
Adharsh