Hi Arijit, Andrew! Arijit, welcome to GCC!
On 2025-03-11T03:26:44+0530, Arijit Kumar Das via Gcc <gcc@gcc.gnu.org> wrote: > Thank you for the detailed response! This gives me a much clearer picture > of how things work. > > Regarding the two possible approaches: > > - I personally find *Option A (self-contained in-memory FS)* more > interesting, and I'd like to work on it first. Sure, that's fine. ..., and we could then still put Option B on top, in case that just Option A should turn out to be too easy for you. ;-) > - However, if *Option B (RPC-based host FS access)* is the preferred > approach for GSoC, I’d be happy to work on that as well. > For now, I’ll begin setting up the toolchain and running simple OpenMP > target kernels as suggested. Thanks again for your guidance! Let us know if you need further help; we understand it's not trivial to get this set up at first. Do you have access to a system with an AMD GPU supported by GCC, or any Nvidia GPU? Just a few more comments in addition to Andrew's very useful remarks. (Thank you, Andrew!) > On Mon, 10 Mar, 2025, 10:55 pm Andrew Stubbs, <a...@baylibre.com> wrote: >> On 10/03/2025 15:37, Arijit Kumar Das via Gcc wrote: >> > I have carefully read the project description and understand that the goal >> > is to modify *newlib* and the *run tools* to redirect system calls for file >> > I/O operations to a virtual, volatile filesystem in host memory, as the GPU Instead of "in host memory", it should be "in GPU memory" (for Option A). >> > lacks its own filesystem. Please correct me if I’ve misunderstood any >> > aspect. >> > I have set up the GCC source tree and am currently browsing relevant files >> > in the *gcc/testsuite* directory. However, I am unsure *where the run tools >> > source files are located and how they interact with newlib system calls.* >> Newlib isn't part of the GCC repo, so if you >> can't find the files then that's probably why! (I assume, by now you've found the newlib source code?) >> The "run" tools are installed as part of the offload toolchain, albeit >> hidden under the "libexec" directory because they're really only used >> for testing. You can find the sources with the config/nvptx or >> config/gcn backend files. Actually, only for GCN: 'gcc/config/gcn/gcn-run.cc'. For nvptx, it's part of <https://github.com/SourceryTools/nvptx-tools>: 'nvptx-run.cc'. >> Currently, system calls such as "open" simply return EACCESS >> ("permission denied") so the stub implementations are fairly easy to >> understand (e.g. newlib/libc/sys/amdgcn/open.c). (I assume, by now you've found the corresponding nvptx code in newlib?) >> The task would be to >> insert new code there that actually does something. You do not need to >> modify the compiler itself. Grüße Thomas
