binaryninja-api icon indicating copy to clipboard operation
binaryninja-api copied to clipboard

Support parsing C++ templates (at least concrete specializations)

Open CouleeApps opened this issue 1 year ago • 3 comments

What is the feature you'd like to have? The type parser should support parsing C++ template concrete specializations. Specifically concrete specializations and specifically just parsing into types, i.e. this does not involve creating templates in the typesystem like #3305.

Is your feature request related to a problem? I want to import C++ headers which use templates, like things that use std::vector<int>

Are any alternative solutions acceptable? I can manually create types for all of the template stuff, but that is tedious and error prone.

Additional Information: Need to extend clang_svcs.cpp ClangTypeToBinja and add CType::TemplateSpecialization. Probably also need to add a bunch of other clang structures to deal with the scaffolding around the templates, but with any luck this can be limited to only fully concrete types for which a layout and fields can be generated.

CouleeApps avatar Apr 10 '24 05:04 CouleeApps

Context (for searchability): I was trying to use the 'Import Header File' feature with some C++ headers from the JUCE audio library, and got an error like this:

error: /Users/devalias/Desktop/path/to/juce-6.0.4-osx/modules/juce_core/streams/juce_InputStream.h:261:5 CType::TemplateSpecialization not implemented

The code on that line looks like:

  • https://github.com/juce-framework/JUCE/blob/6.0.4/modules/juce_core/streams/juce_InputStream.h#L261C5-L261C63
private:
    JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR (InputStream)
};

And it's defined as:

  • https://github.com/juce-framework/JUCE/blob/6.0.4/modules/juce_core/system/juce_PlatformDefs.h#L223-L228
#define JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR(className) \
    JUCE_DECLARE_NON_COPYABLE(className) \
    JUCE_LEAK_DETECTOR(className)

Not sure where the template specialisation comes into it.. maybe further down the macro expansion rabbithole.

0xdevalias avatar Apr 10 '24 06:04 0xdevalias

This may or may not be relevant, but I was looking at ways to potentially work around this in the meantime via potentially pre-processing/expanding the headers. There seem to be a few ideas/tools mentioned here, but from a quick skim, I don't think any of them would do the full 'pre-process/expand' on their own:

  • https://stackoverflow.com/questions/5193867/how-to-expand-preprocess-c-template-code

Which linked (among other things):

  • https://cppinsights.io/
  • http://metashell.org/
    • http://metashell.org/manual/how_to/index.html#see-what-templates-are-instantiated-by-a-certain-normal-c-expression

Some other ideas here:

  • https://news.ycombinator.com/item?id=32969667
    • Ask HN: Any tool to look C++ interpretation template form syntax to substitution
    • https://stackoverflow.com/questions/4448094/can-we-see-the-templates-instantiated-by-the-c-compiler

0xdevalias avatar Apr 11 '24 00:04 0xdevalias

As well, we may want to look into a "collapse sub-structures" option, since most STL types are unholy hydras of nested zero-size structures and unions.

CouleeApps avatar Apr 11 '24 04:04 CouleeApps