Re: [GSoC] Tooling for running BPF GCC tests on a live kernel

[Piyush Raj via Gcc]

Hello
Apologies for sending my draft proposal so close to the deadline. You
can find it here:
https://docs.google.com/document/d/1UL-mGDWyfEjne3f6uEZOI5KG4s9XTP53QZ_LJjoqn-s/edit?usp=sharing

Please share any comments or suggestions you might have. If any
section needs more clarity, do let me know, I'd be happy to revise it.
I’ll update the PDF on the GSoC portal accordingly.
Thanks!

On Thu, 3 Apr 2025 at 19:07, Jose E. Marchesi  wrote:

> We get reports occassionally and normally we open bugzillas for them,
> but not always.
>
> We can compile a list of recent fixes for particular verification
> failure so a set of initial tests can be written during the GSOC
> project.
>
> Going forward, once the run-time testsuite is in place, each fix shall
> be accompanied with the corresponding new test(s).
Sure, I’ve already planned time in the schedule for compiling those
and adding them to the testsuite.

> BPF programs are hooked into the kernel via several mechanisms: kprobes,
> etc.  There may be a way to locate these points using GDB.
>
> However, note that the BPF code gets JITted into whatever native native
> instructions of the host architecture.  Having a debugger relating the
> JITted native instructions to the corresponding source locations would
> require the JITter to somehow translate the debug info as well I
> guess...  an interesting perspective but definitely out of scope of this
> project :)
Thanks for the detailed explanation!
I was mainly curious about the current state of debugging tools and
techniques for eBPF, especially when dealing with large or complex
programs. I’ll definitely try to explore this further once my semester
wraps up in May :)

Best regards,
Piyush

Re: GSoC[Fortran Runtime argument check ] Draft of Proposal and some doubts about the needs

[Steve Kargl via Gcc]

On Mon, Apr 07, 2025 at 02:42:10PM +0800, Gwen Fu wrote:
> Thanks for your reply !
> >The word "parameter" has very a specific meaning in Fortran. The
> >entity that is passed into a function or subroutine is an "actual
> >argument". The entity within the functions associated with the
> >"actual argument" is a "dummy argument".
> 
> Can I understand "dummy parameters" as temporary variables in a function
> similar to C/C++, which copy the value of the passed parameter?
> Or this is pass by value in C++.

Not in Fortran terminology.

program foo
  integer, parameter :: bar = 1
  print *, bar
end program foo

'parameter' is an attribute that is used to designate a named constant.

program foo
  call bar(i)
  print *, i
end
subroutine bar(j)
  j = 42
end 

'i' is an actual argument, and it is implicitly typed.
'j' is a dummy argument, and it is implicitly typed.

Fortran standard does not prescribe pass-by-value or pass-by-reference,
except if the 'dummy argument' has a 'value' attribute.  The 'value'
attribute the interface for the subprogram must have an explicit 
interface.

> >It is not clear to me what you're trying to accomplish. gfortran
> >already has an -fimplicit-none option that enforces no implicit
> >typing. This option will catch the "typo" type error. Gfortran
> >also has the -fallow-argument-mismatch. If the code is within
> >a single file, gfortran will build an explicit interface when
> >it encounters an external procedure, and then it uses that interface
> >to check any additional references.
> I looked up the meaning of these two compilation options.
> Both of them are compile time options .
> But this project  needs to provide an option run-time test .
> I am currently trying to understand the concept of runtime options and
> what can happen.

It is still unclear to me what you are trying to accomplish.
Implicit typying and implicit interfaces are a compile-time
thing.  

function foo(x)
  foo = x * x
end

The above has an implicit interface and implicit types for
'foo' and 'x'.  The -fimplicit-none option capture this.

% gfortran14  -c a.f90
troutmask:kargl[206] gfortran14 -c -fimplicit-none a.f90
a.f90:1:14:

1 | function foo(x)
  |  1
Error: Symbol 'x' at (1) has no IMPLICIT type
a.f90:1:0:

1 | function foo(x)
Error: Function 'foo' at (1) has no IMPLICIT type


An -fcheck=implicit-type option that generates a runtime
error that does not make sense to me unless the aim is
to slow down the compile code.  The above code would be
transformed into something like (ignoring passing convention).

float
foo(float x)
{
  if (runtime_option & fcheck_implicit_type)
 runtime_error("'foo' has an implicit type");

  if (runtime_option & fcheck_implicit_type)
 runtime_error("'x' has an implicit type");

  return (x * x);
} 

-- 
Steve

[GSoC] Initial Draft

[Carter Weidman via Gcc]


Here is my initial draft for my proposal. Please provide as much feedback as 
possible. Upon more research I realize I will almost definitely have time to do 
more than just the bind and device_type clause. I have prepared significant 
research for the cache directive as well, and could definitely include this in 
my proposal. I will also expand upon the device_type section but need to tend 
to an obligation and wanted to post this ASAP. Rip it shreds please!

Thank you!
Carter

Implementing support for the bind clause:

The bind clause will dictate what name will be used when a procedure is called 
from an accelerator device such as a GPU or FPGA. Essentially, users can 
specify multiple versions of the same procedure, one to be run on a host call 
and others that accelerators can call. This is done by specifying either an 
identifier or a string after the bind clause.

The primary benefits of implementing this functionality will be allowing highly 
specialized implementations of procedures, such as custom FFT or BLAS routines 
to be used instead of compiler generated code. It also allows clear definitions 
between host/device functions and greater interoperability with external 
libraries.

Implementation Notes:
We first will need to extend the parser to handle specification of the bind 
clause.
The files that we’ll need to use for this will be 
gcc/c-family/c-pragma.cc, gcc/c-parser.cc, and 
cp/cp-parser.cc (For just the C and C++ implementations). 
Fortran implementation may also be considered (likely) but to begin, we’ll just 
consider these two. Some validation methods already present in GCC may be 
utilized, such as oacc_verify and oacc_finalize. Semantic analysis will also of 
course be performed to ensure proper bind-names are passed.

The parsed clause will then need to be represented in GIMPLE IR (from the AST). 
This will be done by adding a GIMPLE node to represent and store the specified 
procedure to bind to. We will need to make some additions to gcc/tree.h, 
gcc/gimple.def, and gcc/gimple.h such as adding a new bind clause definition 
{OMP_CLAUSE_BIND(NODE)} for example. Storing this symbol-name information in 
GIMPLE IR ensures that, during the linking stage, GCC correctly produces object 
files containing accelerator IR sections and metadata (.gnu.offload_lto_* 
sections).

This new information will also need to be lowered into a device specific IR 
(PTX and GCN) that will allow the accelerator to pull the procedure from the 
bind clause for use. The relevant files here will be gc/config/nvptx and 
gcc/config/gcn.

Timeline:
Week1: Finish research and general design details for implementing bind and 
device_type clause.
Week2: Implement parser support for the bind clause. This will include 
debugging and ensure all new code passes in GCC’s current testing 
infrastructure. Additional testing will be designed to ensure proper 
functionality.
Week3: Implement GIMPLE representation of bind clause. Ensure debugging and 
testing are performed on both the parser and GIMPLE rep.
Week4: Map the routines to external devices (PTX and GCN). We will be able to 
test if the accelerators are implementing the correct routine by seeing what is 
emitted from the backend. Another useful metric would be the compute time, as 
we expect better performance when offloading to an accelerator.
Week5: Finalize implementation and test everything as a whole, ensuring current 
GCC testing passes as well as any important new test that will be implemented 
along the way.

Implementing support for the device_type clause:
Similarly to the bind clause, the device_type clause can specify on which 
device to use a specific procedure. This would allow a user to design many 
different procedures, with device specific implementations. Bind and 
device_type are very much thematic related, hence my interest in both of them.

Thankfully, implementing this function is very similar in the general method. 
The device_type will be parsed the same as any OpenACC directive, lowered into 
both GIMPLE and device-specific IR. If Fortran is included as well (which is 
very likely), it will go from the AST to GENERIC then to GIMPLE. One major 
difference between device_type and bind is that device_type is a configuration 
setting, so we would ideally like to store this setting for any future compiler 
use by the user. A feature to change or disable a specific device for a 
procedure should be considered.

The relevant files are also similar, though I will add some additional ones for 
configuration purposes.
gcc/common/config.cc
gcc/config/gcn/gcn.cc
gcc/config/nvptx/nvptx.cc
gcc/common/config/nvptx/nvptx-common.cc
gcc/lto-section-in.cc/lto-section-out.cc
gcc/lto-wrapper.c

Week6: Begin implementing device_type in parsers. Testing + semantic 
analysis/validity
Week7: Implement relevant GIMPLE (GENERIC) nodes for device_type. Will include 
storing info