Flang Fortran plugin for LLDB status? (original) (raw)

September 18, 2024, 2:58am 1

Hello! I was wondering if there’s any current status of a Fortran plugin for LLDB.

Currently, I’m able to build several of my team’s projects with Flang. Now I’m wondering about the debugger situation. Notably, debugging on arm64 Macs is what I’m interested in. Neither LLDB nor GDB seems available at the moment, but for different reasons. It seems LLDB doesn’t have a language plugin for Fortran. While I’ve been able to build GCC’s experimental arm64-darwin branch, GDB is a separate project which doesn’t have this experimental arm64-darwin support yet.

Has anyone started work on a Fortran plugin for LLDB? If so, is there a place I could go to keep an eye on it? Or has this not been started yet?

Thank you much!

I know there is an effort to improve the debug information created by flang, and I have tried lldb while checking that out.

It’s possible that some things will “just work” as the debug information improves, but for now you’re debugging as if it’s an assembly program effectively (see my comments here for an example).

Edit: this only happened because I didn’t enable debug info, look a the new issue for the current status.

There is no active effort to support Fortran in lldb at this time. My guess is that a very basic skeleton language plugin would bring big improvements, but I have not tried it myself. I suspect some things are just “if no language plugin → fail”, even if there is no special work needed for it in Fortran.

I will at least open a tracking issue for Fortran support, and you can watch that.

It’s better than I remembered actually. We do get source mappings correct.

If you have some time, could you try debugging one of your programs and see what does and doesn’t work? Add them as comments to that issue. I’m unfamiliar with Fortran so coming up with examples is tricky.

You’ll have to use flang but this is fine just try it and I can figure out if it’s flang not emitting the right debug info, or lldb is not handling it correctly.

Unless this arm64-darwin branch has gfortran already?

mattrobin September 18, 2024, 5:17pm 4

@DavidSpickett, thanks for the reply and status update!

When I had tried debugging a flang compiled binary with lldb, stopping at a breakpoint resulted in warning: This version of LLDB has no plugin for the language "fortran95". Inspection of frame variables will be limited., which is what you mentioned in your GitHub issue as well. Previously, I’ve usually had my IDE abstract away whichever debugger I was using, so I’m not super familiar with using the debuggers directly, but I’m sure I can figure it out and explore things a bit further.

I believe the arm64-darwin version of gfortran has been fully functioning for a while, at least, in providing running executables. I don’t know if there’s additional debugging information that still needs to be worked on or not, though. I’m not particularly knowledgeable about compilers, so I don’t know how much debugging info is added in the backend portion vs some earlier phase, and therefore if there is missing work in that component or not.

For your last question, do you mean a gfortran compiled binary could be debugged by lldb? I was under the impression that there was a significant amount of custom debugging information that each compiler suite added that the other suite didn’t handle well. Though, maybe this is a smaller portion than I expect. I’ll be sure to give the gfortran compiled binary a debugging test a try when I have some time. But at least from the user (me) side of things, I’m guessing lldb won’t provide a ton of information until the Fortran skeleton plugin is added.

jingham September 19, 2024, 12:25am 5

Note, Rust gets a little further - even though there is no Rust Language plugin for lldb - by just claiming “Rust is pretty close to C++”. That’s done in TypeSystemClang.cpp:TypeSystemClangSupportsLanguage. You might try adding Fortran to Rust, D & Dylan and see if you get any further.

There are cases where compilers have quirks or emit info that only one debugger bothers to / can support but in general LLDB is not tied to any given compiler.

Sometimes folks ask if you have to debug llvm projects with lldb, and no, you can use any tools you want. Just like gdb isn’t just for gnu projects. Sure they have some symbiosis but we try to keep it to a minimum.

If there was something gfortran emitted, unless it was completely non-standard, we would want it to work. And I suspect as time goes on, flang will adopt many of gfortran’s quirks here anyway, as it’s the role model in this area.

Part of my problem here personally is I’m not a Fortran user so I don’t know what folks expect. Are there special variables in the runtime, do you need extra formats for printing, can we properly create “clang” AST to represent some of the types (flang AST?).

As Jim said, we get a lot of the basics from pretending that everything is C++. It’s the specifics where your experience with Fortran would help but as with all debugging, it’s a case of taking note of things as you come across them rather than being able to run some comprehensive test suite and see what’s missing.

Aside from GDB’s fortran tests but I think it would be more effort to get those running than to start a language plugin and write our own.

Let me see what I can gather from my colleagues who work on GDB, and GDB’s public documentation. That’s a good place to start.

Rekindle November 6, 2025, 8:05pm 7

Sir, did a fortran language plugin ever get completed?

No, and there is no work currently happening on this topic.

(aside from improving Flang’s debug information but that’s applicable to any tools)

Since the last comment here, there have been improvements in the infrastructure that a hypothetical plugin would use, and discussions on Rust support, which has many of the same challenges.

So LLDB is slowly making language plugins easier to make, but no change for Fortran at this time.

Rekindle November 11, 2025, 2:07pm 9

ok, thanks. I’ll keep waiting.