February 24, 2026, 5:37pm 1

Description:

Fortran remains widely used in HPC, scientific computing, and numerical simulation. However, LLDB currently provides no meaningful variable inspection support for Fortran programs, resulting in errors such as:

error: Could not find type system for language fortran95: TypeSystem for language fortran95 doesn't exist

Currently, LLDB lacks a Fortran type system. While breakpoints, stepping, and backtraces work using DWARF line tables, variable inspection and expression evaluation fail due to the absence of a Fortran TypeSystem, DWARFASTParser, ExpressionParser and language integration layer.

This project aims to add initial Fortran debugging support to LLDB by consuming existing DWARF debug information generated by LLVM Flang.
The work will focus entirely on LLDB-side infrastructure. No major changes are expected to LLVM IR, DIBuilder, or the DWARF emission produced by Flang, as current flang compiler already generate sufficient debug information for common Fortran constructs.

Selected candidate will be expected to share an RFC(request for comment) proposal with the proposed architecture and integration of the Fortran language plugin to discuss on LLDB Discourse forum during the community bonding period.

Expected Outcome: The goal of this project is to implement a minimal but functional Fortran debugging stack inside LLDB that enables:

• Inspection of scalar variables (integer, real, logical)

• Inspection of function arguments and return values

• Static array inspection

• Character string inspection (character(len=*))

• Derived type (struct) inspection

• Module/global variable visibility

• Basic expression evaluation (p a, p a+1, p arr(2), p p%x)

Further reading
[1] Adding Programming Language Support - 🐛 LLDB
[2] Fortran language support in lldb · Issue #109119 · llvm/llvm-project · GitHub

Skills: Intermediate knowledge of C++; Basic Fortran knowledge or desire to learn, Ability to comprehend DWARF debug format and standard.

Project size: Large

Difficulty: Medium

Mentors: Shivam Gupta

3 Likes

2 Likes

The general progression is the following:

• You need a custom TypeSystem for sure. It will force you to define your own DWARF AST Parser. You should leave most of the functions unimplemented by returning void or an equivalent to nullptr. That’s fine, you’ll be implementing things little by little. The TypeSystem is used for both understanding DWARF and creating an AST for expression evaluation. Be aware of that because that means you don’t need to implement everything.
• Then, you start adding support for primitive types (ints, floats, char, etc). It seems that this is a function you’ll have to deal with GetBuiltinTypeForDWARFEncodingAndBitSize for that, but if not, it’s something similar that deals with basic types.
• Then, you add support for pointers and references.
• Then, you add support for named entitied, like variables. In clang’s parlance you have decls that represent something with a name and you’ll see how Clang’s typesystem converts many DWARF entities into Decls. You have to do something similar using flang’s own decls. Here you can see that the purpose of the typesystem and DWARF AST Parser is to create a flang’s AST as if flang’s own front end would have generated it. That will allow you to use flang’s own libraries to inspect the layout of objects, query properties of objects, and eventually do expression evaluation via flang.
• The next step is to add support for structs, which is a bit tricky. The DWARF AST Parser build structs lazily. Once it sees a struct declaration in DWARF, it created an incomplete decl without fields, and only when the user really needs to inspect the elements of the struct, the DWARF AST Parser gets invoked again to complete recursively the definition.

In all steps, try to have tests, and start with minimal cases like a program with one variable, then multiple variables with different types, then strings, then functions, etc.

This is enough for work a few months, but if you just want to explore this before committing to it, adding support for displaying an int would already give you some context on everything that needs to be done.

Hi @chinmaylk99,

Thanks again for showing the interest. Don’t worry, take your time.

You can list me as mentor in your final GSoC submission.

Using AI tools to learn things is fine but proposal should reflect your thoughtful decisions.

I have taken a took, technical approach is looking good.

Thanks
Shivam

Hello @Shivam and @wallace, I have been exploring this project for about 2-3 weeks now., going throuh FORTRAN docs and looking into lldb working for TypeSystemClang., though couldn’t make much headway since I had a full time internship which ended a week ago.

So, the past week I have been working on this actively and have now gotten basic types int, real, logical and character to work! Phew!

Current Progress!

If anyone is stuck or overwhelmed and wondering how to explore here is what I did after reading a bunch on DWARF/ELF and how debuggers work (Building a Debugger - Sy Brand is a wonderful resource along with great cppcon talks on youtube) -

Initially I started following @wallace post and lldb’s guide to adding a language. I created a TypeSystemFlang to add support for FORTRAN. I kept most functions unimplemented and returned nullptr or equivalent such where needed and only implemented basic functions like GetSupportedLanguages and such as suggested by @wallace.

However soon I was overwhelmed by the project and could not understand the where to begin with implementing the functions. So I tried to figure out the flow from Command Object., as I was trying to make the “frame variable *” command work. I tried enabling all logs and tried to see the flow but to no awail. Though I did understand how stack frame and DIEs in DWARF was used but couldn’t see how TypeSystemFlang came into the flow. I was stuck here for a while.

I could see that TypeSystemFlang was initialized but then no other function was called from the instance except for GetDwarfAstParser. So similar to TypeSystemFlang I implemented that with null stubs as well.

Then I had the idea of instead of finding the flow from lldb, why not check from TypeSystemFlang or my new DWARFAstParserFlang? So I wrote a macro which would log current function and line number on every block open (functions and conditions) in my classes TypeSystemFlang and DWARFAstParserFlang and voila!

Now things became much easier as I could see the complete flow from my classes as I single stepped through a program with lldb and using the frame variable command. The missing link between dwarf and typesystem was the function ParseFunctionFromDWARF. Following that I implemented the functions as needed (shamelessly copying some from TypeSystemClang and DWARFAstParserClang as needed ; ) ) .

Eventually I got printing to work as well by using Dump* functions so commands like frame variable * (where * is name of variable) worked.

Eventually I got characters to work as well

Now I have a much better understanding of LLDB and DWARF!

Hello @Shivam @wallace.
Now, I have got pointers and structures working as well. I am working out arrays now and exploring how can I make an AST for flang’s libraries to consume.

Any help or guidance would be appreciated, especially from someone who has worked on Flang.

This is great! I’m glad you were able to make such a good progress.

how can I make an AST for flang’s libraries to consume.

That’s only useful for expression evaluation. I’m not the owner of this project but I don’t think you need to do that. There’s a framework in LLDB called DIL that you can use to perform some level of expression evaluation without requiring the flang compiler. I think that’s what frame var uses by default, and you can extend it with fortran-specific tokens.

My suggestion would be to start upstreaming what you have, that way you can get early feedback from the community.

This is great! I’m glad you were able to make such a good progress

Thanks!

I think that’s what frame var uses by default, and you can extend it with fortran-specific tokens

Yes that is what has gotten me de-referencing and member lookup automatically. I am now getting basic arithmetic to work using that as well.

My suggestion would be to start upstreaming what you have, that way you can get early feedback from the community

Yes, I was thinking to do that as well, maybe after I smooth out the rough edges a bit - mainly things like formatting and adding testing (still figuring out lldb’s testing suite!).

I will try to have an upstream PR or maybe an RFC here in a few days.

Thanks Aryan for the interest in the project. It was a great progress, but since this project is reserved for GSoC, might be better if GSoC student start it fresh.

We have some great proposals and right now these are in evaluation period.

this project is reserved for GSoC

Ohh, I forgot to mention here, I have applied for GSoC as well. I have mailed my proposal to you as well a few days back. I am an undergrad in my fourth year of engineering at Pune Institute of Computer Technology (PICT).

1 Like