[llvm] [C API] Add bindings for DWARF type encoding. (PR #102171)

David Blaikie via llvm-commits llvm-commits at lists.llvm.org
Fri Aug 9 10:28:25 PDT 2024


dwblaikie wrote:

OK, so we have two examples of prior art here, then? The macro enum, which independently duplicates the DWARF numbers that are also present in LLVM's C++ API (presumably in the Dwarf.def file) - or the language codes which has enum values that don't necessarily match the DWARF spec and are remapped to the DWARF numbering inside LLVM's C++ API?

Neither of these seem great (duplicating seems unfortunate/a maintenance burden, and having constants that don't match the DWARF spec or LLVM's internal representation seems like it produces unnecessary complexity/divergence/etc).

I guess the alternative would be to sink the Dwarf.def file down into the C API, use it there to generate the C enums, and use it up in LLVM's BinaryFormat to support the C++ API, and knowing they match up numerically, we can cast (without a switch remapping) between the two whenever we want.

I don't quite understand the complaint about FFIs, though? The need to be able to parse a C header without a preprocessor, to be able to map the C API into another language? I can't imagine we support that in any way, and presumably do things in headers that would break that all the time? Is that sort of guarantee documented anywhere (generally, and/or in LLVM in particular) about what we could/should do or not do in a C interop header to support this?

https://github.com/llvm/llvm-project/pull/102171


More information about the llvm-commits mailing list