gcc plugin on MacOS failure

[Marc]

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 <mh@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