[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