In playing around with this some more, I get different behavior for the compiled binary, in and out of codeql database create.

codeql database create ./gpp_db --overwrite --language=cpp --command="g++ -std=c++17 ./test.cpp -o gpp_test"
Initializing database at /Users/b/projects/foo/gpp_db.
Running build command: [g++, -std=c++17, ./test.cpp, -o, gpp_test]
Finalizing database at /Users/b/projects/foo/gpp_db.
Successfully created database at /Users/b/projects/foo/gpp_db.

./gpp_test
size 48

g++ -std=c++17 ./test.cpp -o gpp_test2
./gpp_test2
size 32

Going from a fully clean install on Ubuntu 22, both sizeof() and CodeQL produce the same results.

I wrote a quick tool to compare DWARF and CodeQL results (https://github.com/WilliamParks/Struct-Check), and it seems std::function is the only improperly sized struct in the large project I've been working with

Hi @WilliamParks,

Thanks for your question. There are two things going on here:

1. clang's target architecture detection fails when running the compilation under codeql database create, and it creates a x86-64 binary instead of a arm64 binary. This is due to a know issue: the component tracing the build is a x86-64 binary and not a universal binary. This explains the mismatch you observed while running the executables. To work around this please specify an explicit -target during compilation, e.g., -target arm64-apple-macos11. This will not affect the size reported by CodeQL though.
2. The front-end we're using currently assumes x86-64 struct member alignment even when the target is arm64. One of the underlying structs of std::function does some alignment trickery causing the struct to be larger than expected for the arm64 target.

The second issue is in principle fixable. However, to properly prioritise this, would you mind explaining what your use-case is?

Hi @jketema,
Ahh, interesting! Thanks for passing that along. I didn't think to check what type of binary was being produced.

I'm using CodeQL static analysis as part of a fuzzing research project. I've been doing development on an arm64 mac, but it'll actually run on an x86-64 system. Because of that, I think this is low priority.

Thanks!

Thanks for sketching the context in which you use this. I've opened some internal issues to track the problems you observed.