[GSoC2026] Add Fortran Debugging Support in LLDB

[xgupta]

No description provided.

[Michael137]

FYI: llvm/llvm-project#109119

[JDevlieghere]

@xgupta How familiar are you with LLDB? This seems like a pretty ambitious project and would certainly benefit from a mentor that works on LLDB and knows how all these things fit together. Even then this will likely still require a lot of commitment from reviewers.

It's also interesting that this is targeting gfortran and not flang. Do you still expect to use Flang to back the TypeSystem and do expression evaluation, similar to the approach we take with C-based languages and clang? This really seems like something that would benefit from an RFC and I'm not sure that's something I would expect from a GSoC student.

[xgupta]

I have been working supporting COBOL and PLI in lldb at Raincode Labs for more than a year so I know how to add a language support in LLDB. Other than that I work at AMD for a year which involve Fortran code. So I am familiar with fortran. That is all. At Raincode we use LLVM based COBOL/PLI compiler.

I am hopeful that we could have a basic support for Fortran in the GSOC timeframe and since there are other companies like AMD, NVIDIA, ARM which shows interest in debugging fortran code with lldb so eventually more effort comes.

There is reason I mention gfortron, I was never able to built flang on my system, it is resource hungry so plan to use gfortran to emit debug info and parse it in lldb. I can try to build flang from source again, test current status and update the description if it goes fine.

If you suggest we can drop expression evaluation and mention as optional.

CC @DavidSpickett who might be interested in this project.

[JDevlieghere]

I have been working supporting COBOL and PLI in lldb at Raincode Labs for more than a year so I know how to add a language support in LLDB. Other than that I work at AMD for a year which involve Fortran code. So I am familiar with fortran. That is all. At Raincode we use LLVM based COBOL/PLI compiler.

👍

I am hopeful that we could have a basic support for Fortran in the GSOC timeframe and since there are other companies like AMD, NVIDIA, ARM which shows interest in debugging fortran code with lldb so eventually more effort comes.

That would certainly be the ideal outcome, but in the meantime I assume you're signing up to maintain the Fortran language plugin?

There is reason I mention gfortron, I was never able to built flang on my system, it is resource hungry so plan to use gfortran to emit debug info and parse it in lldb. I can try to build flang from source again, test current status and update the description if it goes fine.

For Fortran to be part of upstream LLVM, we will need a testing story. The most obvious solution is to use the in-tree Fortran compiler. I think it'd be a hard sell to add an external dependency on GFortran.

If you suggest we can drop expression evaluation and mention as optional.

Not necessarily, I just think there are lot of unanswered questions here, which normally get discuss in an RFC. Do you expect the RFC process to be part of the GSoC project? If so I think that should probably be clearly stated in the project description. The other alternative is to have the RFC now and settle on all the details and have clear deliverables the community is on board with.

To be clear I'm not trying to push back on to this project, quite the opposite actually. I want to ensure that the person working on this has a real chance at success.

[xgupta]

I am hopeful that we could have a basic support for Fortran in the GSOC timeframe and since there are other companies like AMD, NVIDIA, ARM which shows interest in debugging fortran code with lldb so eventually more effort comes.

That would certainly be the ideal outcome, but in the meantime I assume you're signing up to maintain the Fortran language plugin?

Yes, I am available to maintain the plugin.

There is reason I mention gfortron, I was never able to built flang on my system, it is resource hungry so plan to use gfortran to emit debug info and parse it in lldb. I can try to build flang from source again, test current status and update the description if it goes fine.

For Fortran to be part of upstream LLVM, we will need a testing story. The most obvious solution is to use the in-tree Fortran compiler. I think it'd be a hard sell to add an external dependency on GFortran.

Today I was able to build flang with 'ninja -j1', while remaining dependency of clang and mlir was built fine with all the processors/threads enabled. I will update the proposal with Flang as a main compiler and GFortran as reference for debug info output.

If you suggest we can drop expression evaluation and mention as optional.

Not necessarily, I just think there are lot of unanswered questions here, which normally get discuss in an RFC. Do you expect the RFC process to be part of the GSoC project? If so I think that should probably be clearly stated in the project description. The other alternative is to have the RFC now and settle on all the details and have clear deliverables the community is on board with.

Yes, I am thinking to write a RFC in a day or two and wanted to do a few hours of research.

To be clear I'm not trying to push back on to this project, quite the opposite actually. I want to ensure that the person working on this has a real chance at success.

Thank you @JDevlieghere for the support.

[xgupta]

Hi @JDevlieghere, I have updated description to use flang instead of gfortran. Also I think it is better that selected candidate write RFC during community bonding period since they are the one implementing the changes.

Also I did tried debugging many programs to check what is missing, It seems flang debug info generation is in good shape since all the programs compile by flang -g (collected in https://github.com/xgupta/fortran-tests/) are debugging fine with gdb.