Support for a GCC-based backend

[ojeda]

Currently, bindgen uses libclang to understand C/C++ code. #1740 considers moving to a lower-level interface for LLVM, with discussion of whether keeping support for several interfaces is feasible.

It would be great to have support for non-LLVM backends as well. In particular, a GCC-based one. Clang is very compatible with GCC nowadays (in both the Clang driver and the support for GNU C language extensions), but there are still differences here and there, which means one needs to be careful when applying bindgen in complex projects compiled with GCC.

It would require compiling a GCC plugin and using callbacks like PLUGIN_PRE_GENERICIZE ("Allows to see low level AST in C and C++ frontends.") and/or others like PLUGIN_FINISH_PARSE_FUNCTION, PLUGIN_FINISH_TYPE, PLUGIN_FINISH_DECL, etc.; or perhaps another way to use GCC's parser/tooling/etc.; or possibly using other approaches that fetch the information in another way (e.g. querying the compiler via generated C files or extracting it from debug information).

Of course, tackling this would be non-trivial, and it might not be worth the maintenance cost, but it might be an interesting project to expand bindgen's capabilities, as well as relaxing the dependency on LLVM.

[bobbbay]

+1 for this (albeit two years later). I have a library that is incompatible with clang and must be compiled using gcc, but can't run bindgen on it. It would very nice to be able to simply set the backend to gcc and compile things as they should.

[emmatebibyte]

I'm trying to write some cross-platform tools and it would be nice to be able to use bindgen with them on any system.

[StellarHS]

In LLVM, some standard headers like wchar.h only find in model libcxx. That may cause some trouble when a code uses gcc. If it support for a GCC-based backend, that trouble can be easily solved.

[pvdrz]

This is unlikely to be implemented anytime soon unless someone else shows up and decides to give it a go

[Shinyzenith]

Hi, I'm not too familiar with bindgen internals but I want to support this! Is this a feature the bindgen team would like to see upstream? I'm willing to try my hands at making a PR. I'd rather not invest time blindly hence a stance on this proposal would be helpful.

My main motivation for this is to further the development of rust for linux. @ojeda sorry for the ping but I just wanna confirm if this is still a "good to have"/requirement for rust for linux since it's been 4 years.

[tgross35]

@Shinyzenith I can answer for RFL - yes, this is very much still wanted :) Especially with both rustc_codegen_gcc and gccrs probably going to be usable sometime this year I think demand for GCC-produced bindings will only go up from here, even outside of linux.

Just be aware that this is definitely quite a bit of effort.

[Shinyzenith]

@Shinyzenith I can answer for RFL - yes, this is very much still wanted :) Especially with both rustc_codegen_gcc and gccrs probably going to be usable sometime this year I think demand for GCC-produced bindings will only go up from here, even outside of linux.

Just be aware that this is definitely quite a bit of effort.

Hi, thanks for the response. I understand that this is a lot of effort -- maybe getting a draft PR up at the very least even if I'm unable to finish it in the future would help attract possible contributors to pick up the slack -- but that's probably a discussion for later 😅.

If anyone from the bindgen team could confirm if this proposal is accepted then I'd love to try my hands at it.