Thank you so far, this got me (unsurprisingly) one step further, but then the external function resolve error is moved to the library loading stage:
~/afl++ $ g++-11 -Wl,-flat_namespace -Wl,-undefined,dynamic_lookup -g -fPIC -std=c++11 -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin/include -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin -I/usr/local//Cellar/gmp/6.2.1/include -shared instrumentation/afl-gcc-pass.so.cc -o afl-gcc-pass.so => compiles because the linker does not bail on functions it cannot resolve at link time. ~/afl++ $ ./afl-gcc-fast -o test-instr test-instr.c afl-cc ++3.15a by Michal Zalewski, Laszlo Szekeres, Marc Heuse - mode: GCC_PLUGIN-DEFAULT error: unable to load plugin './afl-gcc-pass.so': 'dlopen(./afl-gcc-pass.so, 9): Symbol not found: __ZN8opt_pass14set_pass_paramEjb Referenced from: ./afl-gcc-pass.so Expected in: flat namespace in ./afl-gcc-pass.so' Looking which library might be supplying this call does not show any library: ~/afl++ $ egrep -ral __ZN8opt_pass14set_pass_paramEjb /usr/local/ /usr/local//var/homebrew/linked/gcc/libexec/gcc/x86_64-apple-darwin20/11.1.0/f951 /usr/local//opt/gcc@11/libexec/gcc/x86_64-apple-darwin20/11.1.0/f951 /usr/local//opt/gfortran/libexec/gcc/x86_64-apple-darwin20/11.1.0/f951 /usr/local//opt/gcc/libexec/gcc/x86_64-apple-darwin20/11.1.0/f951 /usr/local//Cellar/gcc/11.1.0_1/libexec/gcc/x86_64-apple-darwin20/11.1.0/f951 (on the other hand it is the same on Linux, I cannot find a library that actually supplies that function. Thank you! Regards, Marc On 22.07.21 22:16, Iain Sandoe wrote: > > >> On 22 Jul 2021, at 20:41, Andrew Pinski via Gcc <gcc@gcc.gnu.org> wrote: >> >> On Thu, Jul 22, 2021 at 7:37 AM Marc <m...@mh-sec.de> wrote: >>> > >>> I have a gcc plugin (for afl++, >>> https://github.com/AFLplusplus/AFLplusplus) that works fine when >>> compiled on Linux but when compiled on MacOS (brew install gcc) it fails: >>> >>> ~/afl++ $ g++-11 -g -fPIC -std=c++11 >>> -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin/include >>> -I/usr/local/Cellar/gcc/11.1.0_1/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0/plugin >>> -I/usr/local//Cellar/gmp/6.2.1/include -shared >>> instrumentation/afl-gcc-pass.so.cc -o afl-gcc-pass.so >> >> A few things, You are not building the plugin with the correct options >> for darwin. >> Basically you need to allow undefined references > > -Wl, -undefined, dynamic_lookup > > but if you expect those to bind to the main exe (e.g. cc1plus) at runtime, > then you will need to build that with dynamic export. (-export_dynamic) > > These things will *not* transfer to arm64 macOS and they will probably > produce build warnings from newer linkers. > > === > > I suspect that we will need to find a different recipe for that case > (possibly using the main exe as a "link library" on the plugin link line, I > guess). > >> and then also use >> dylib as the extension. > > That’s a convention for shared libs but it won’t stop a plugin working (in > fact things like python use .so on macOS) > > for pluign modules, (e.g. Frameworks) even omitting the extension completely > has been done. > > (so this is not the source of the problem) > >> A few other things too. I always forgot the exact options to use on >> Darwin really. GNU libtool can help with that. > > perhaps, but I am not sure it’s maintained agressively .. so make sure to > check what you find is up to date. > > cheers, > Iain. > -- Marc Heuse www.mh-sec.de PGP: AF3D 1D4C D810 F0BB 977D 3807 C7EE D0A0 6BE9 F573
