`bear intercept` prints empty events.json with dynamically linked arm-none-eabi-gcc

[stijlist]

Describe the bug bear intercept is working with gcc but not with arm-none-eabi-gcc.

Both are dynamically linked:

~/SimpleMakefile:master:> otool -L (which gcc)
/usr/bin/gcc:
    /usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
~/SimpleMakefile:master:> otool -L (which arm-none-eabi-gcc)
/opt/homebrew/bin/arm-none-eabi-gcc:
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1200.3.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.0.0)

Bear is not working with arm-none-eabi-gcc:

~/c/b/S/firmware:main:> make clean; bear intercept -- make
rm -fR build
mkdir build     
arm-none-eabi-gcc -c -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32F446xx -ICore/Inc -IDrivers/STM32F4xx_HAL_Driver/Inc -IDrivers/STM32F4xx_HAL_Driver/Inc/Legacy -IDrivers/CMSIS/Device/ST/STM32F4xx/Include -IDrivers/CMSIS/Include -Og -Wall -fdata-sections -ffunction-sections -g -gdwarf-
[snip]
arm-none-eabi-size build/stove-controller.elf
   text    data     bss     dec     hex filename
   5436      20    1644    7100    1bbc build/stove-controller.elf
arm-none-eabi-objcopy -O ihex build/stove-controller.elf build/stove-controller.hex
arm-none-eabi-objcopy -O binary -S build/stove-controller.elf build/stove-controller.bin    
~/c/b/S/firmware:main:> du -h events.json 
0B  events.json

Bear is working with gcc:

Running bear intercept -- make in a simple C project (e.g. https://github.com/lostella/SimpleMakefile) prints non-empty events.json.

~/c/b/S/firmware:main:> cd ~/SimpleMakefile/
~/SimpleMakefile:master:> make clean
rm -f *.o
~/SimpleMakefile:master:> make
gcc  -O3   -c -o main.o main.c
gcc  -O3   -c -o functions.o functions.c
gcc  -lm main.o functions.o -o runme 
~/SimpleMakefile:master:> otool -L (which gcc)
/usr/bin/gcc:
    /usr/lib/libxcselect.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
~/SimpleMakefile:master:> cat events.json
{"rid":"722590632463888551","timestamp":"2024-01-31T18:49:52.238084Z","started":{"execution":{"executable":"/usr/bin/gcc", ...

To Reproduce Steps to reproduce the behavior:

Install arm-gnu-toolchain. Clone this minimal makefile example. Install bear from homebrew.

Run bear intercept -- make. Observe events.json is empty.

Expected behavior I expect bear intercept to work the same with dynamically linked gcc and dynamically linked arm-eabi-none-gcc.

Environment:

• OS name: Darwin
• OS version: Ventura 13.6.4
• OS architecture: arm64
• Bear version: 3.1.3
• Bear install method: brew install bear

macos SIP status:

~/stove-controller:main:> csrutil status
System Integrity Protection status: unknown (Custom Configuration).

Configuration:
    Apple Internal: disabled
    Kext Signing: enabled
    Filesystem Protections: disabled
    Debugging Restrictions: enabled
    DTrace Restrictions: disabled
    NVRAM Protections: enabled
    BaseSystem Verification: enabled
    Boot-arg Restrictions: enabled
    Kernel Integrity Protections: disabled
    Authenticated Root Requirement: enabled

This is an unsupported configuration, likely to break in the future and leave your machine in an unknown state.

Before you send...

• Have you read the README.md file or man bear? Yes.
• Have you looked what other open issues Bear has? Yes.
• Are you sure that the build works without Bear? Yes.

[stijlist]

I really appreciate the tool, by the way - thanks for writing it!

I'm happy to provide more debugging information if it's helpful.

[stijlist]

Oh, I realize now that this might be the same issue as #468. Is there a way to force the dynamically linked (bear 2.x) behavior if I know SIP is disabled and I can use LD_PRELOAD?

I'm not sure why it works for gcc though.

[rizsotto]

Hey @stijlist , I am happy that you've found that thread. The gist is,

• you need to create a link to the wrapper with the same name as the cross compiler (arm-none-eabi-gcc)
• and create a config file that enables this compiler to be recognized (for the compilation database generation.)

It works for the regular gcc, because that's built into the tool. But cross compilers are not.