8000 I cannot compile with my linux-arm-musl toolchain with lto enabled. by zetier-hg · Pull Request #1146 · frida/frida-core · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

I cannot compile with my linux-arm-musl toolchain with lto enabled. #1146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

I cannot compile with my linux-arm-musl toolchain with lto enabled. #1146

wants to merge 1 commit into from

Conversation

zetier-hg
Copy link

I get:
../arm-linux-musleabihf/bin/ld: DWARF error: can't find .debug_ranges section. /tmp/ccEOssxO.ltrans0.ltrans.o: in function frida_try_load_libc_and_raise': <artificial>:(.text+0x13b4): undefined reference to memcpy' /home/user/dev/blog/frida-musl/cross/install/bin/../lib/gcc/arm-linux-musleabihf/14.2.0/../../../../arm-linux-musleabihf/bin/ld: :(.text+0x14dc): undefined reference to `memcpy'

I tried a few things, and it's strange why there is a ref to memcpy. However excluding lto works. It appears that the footprint is not largely affected. I'll let Ole decide if this is for consideration

I do see that Ole said in another commit that armhf-musl will be included in CI; out of curiosity, which toolchain are you guys using for 32-bit armhf-musl?

@zetier-hg
I cannot compile with my linux-arm-musl toolchain with lto enabled.
f4e8698 
I get:
../arm-linux-musleabihf/bin/ld: DWARF error: can't find .debug_ranges section.
/tmp/ccEOssxO.ltrans0.ltrans.o: in function `frida_try_load_libc_and_raise':
<artificial>:(.text+0x13b4): undefined reference to `memcpy'
/home/user/dev/blog/frida-musl/cross/install/bin/../lib/gcc/arm-linux-musleabihf/14.2.0/../../../../arm-linux-musleabihf/bin/ld: <artificial>:(.text+0x14dc): undefined reference to `memcpy'

I tried a few things, and it's strange why there is a ref to memcpy. However excluding lto works.
It appears that the footprint is not largely affected.
I'll let Ole decide if this is for consideration

I do see that Ole said in another commit that armhf-musl will be included in CI; out of curiosity, which toolchain are you guys using for 32-bit armhf-musl?
@oleavr
Copy link
Member
oleavr commented Mar 21, 2025 •
edited
Loading

Did you rebuild the Frida SDK for armhf-musl using your toolchain? If not you should, to avoid compatibility issues when mixing prebuilt object files with those built by your toolchain.

You can grab our toolchain from the GitHub container registry here. If you want to tweak it/build it yourself, you can use our crosstool-NG config together with our crosstool-ng "fork".

@zetier-hg
Copy link
Author

Thanks for replying.
Yes, I am well-familiar with the SDK and I rebuild from scratch when trying a new toolchain.

However, I somehow totally missed the fact that you have cross-tool repos (lots of repos....). FYI, I have used my own builds with https://github.com/firasuke/mussel and https://github.com/richfelker/musl-cross-make. Since musl is incompatible between 1.1.x and 1.2.x series, I wanted control over which musl version to use, as I target older musl, and I want Frida to be be compatible with system libc.so.
I recently came up with the suspicion that it could have to do with ls vs gold linkers. It appears you are using gold, it might be the difference, not sure.

I will roll my own toolchain using your CT script and see if it works. Currently I target ARMv6, which is another reason for custom build. Also, I will try out if your CT build removes a really annoying hack in the injection stuff, I seem to need (the mmap pivot fails...). If still present, I might circle back to you regarding this.

Thanks!

@zetier-hg
Copy link
Author

Hello Ole,
I built the ct-ng toolchain from source using the config you pointed me to:

$ arm-linux-musleabihf-gcc -v
Using built-in specs.
COLLECT_GCC=arm-linux-musleabihf-gcc
COLLECT_LTO_WRAPPER=/home/user/dev/blog/ct/toolchain/libexec/gcc/arm-linux-musleabihf/7.5.0/lto-wrapper
Target: arm-linux-musleabihf
Configured with: /home/user/dev/blog/ct/build/.build/arm-linux-musleabihf/src/gcc/configure --build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu --target=arm-linux-musleabihf --prefix=/home/user/dev/blog/ct/toolchain --exec_prefix=/home/user/dev/blog/ct/toolchain --with-sysroot=/home/user/dev/blog/ct/toolchain/arm-linux-musleabihf/sysroot --enable-languages=c,c++ --with-float=hard --enable-__cxa_atexit --disable-tm-clone-registry --disable-libmudflap --disable-libgomp --disable-libssp --disable-libquadmath --disable-libquadmath-support --disable-libsanitizer --disable-libmpx --disable-libstdcxx-verbose --with-gmp=/home/user/dev/blog/ct/build/.build/arm-linux-musleabihf/buildtools --with-mpfr=/home/user/dev/blog/ct/build/.build/arm-linux-musleabihf/buildtools --with-mpc=/home/user/dev/blog/ct/build/.build/arm-linux-musleabihf/buildtools --with-isl=/home/user/dev/blog/ct/build/.build/arm-linux-musleabihf/buildtools --enable-lto --without-zstd --enable-threads=posix --enable-target-optspace --enable-plugin --enable-gold --disable-nls --disable-multilib --with-local-prefix=/home/user/dev/blog/ct/toolchain/arm-linux-musleabihf/sysroot --enable-long-long
Thread model: posix
gcc version 7.5.0 (GCC)

I do notice that the default linker is still 'ld'; 'gold' is just built and included should the user want to swap.

However, I ran into the same LTO issue when rebuilding the helpers: the memcpy linkage thing.

In fact, I ran into the other thing in the injector functionality as well; like this

# frida-inject -s hook-simple.js -n uhttpd
Unexpected failure while trying to allocate memory
# frida-trace --decorate -i "read*" uhttpd
Failed to attach: unexpected failure while trying to allocate memory    
Exception ignored in: <function _DeleteDummyThreadOnDel.__del__ at 0xb68122a8>
Traceback (most recent call last):
  File "/root/pack/lib/python3.13/threading.py", line 1383, in __del__
TypeError: 'NoneType' object does not support the context manager protocol
#

My full patch file is below (for 16.6.6). I know that the header file inclusion is already fixed in 'main' branch. The pivot into mmap doesn't work right (on arm or musl?), so I force it to the backup method of overwriting a chunk of code in the target process.
This code seems like a PITA to debug and figure out what's wrong. However, if you are motivated to make it work, I'd be very willing to help (I'd probably need your expertise on the matter to make progress). Anyway please look at the below, with the understanding that the mmap thing is not for upstream and just for me to circumvent.

My arm musl patch as of now:

diff --git a/src/linux/frida-helper-backend.vala b/src/linux/frida-helper-backend.vala
index 9839fbff..6fad340a 100644
--- a/src/linux/frida-helper-backend.vala
+++ b/src/linux/frida-helper-backend.vala
@@ -1096,7 +1096,7 @@ namespace Frida {
 #else
 			bool same_libc = remote_libc != null && remote_libc.identity == local_libc.identity;
 #endif
-			if (same_libc) {
+			if (false) {
 				remote_mmap = remote_libc.base_address + mmap_offset;
 				remote_munmap = remote_libc.base_address + munmap_offset;
 			}
diff --git a/src/linux/frida-syscall.h b/src/linux/frida-syscall.h
index e9dd30d6..24046d95 100644
--- a/src/linux/frida-syscall.h
+++ b/src/linux/frida-syscall.h
@@ -22,6 +22,7 @@
 # define SYS_pidfd_open         434
 # define SYS_pidfd_getfd        438
 #elif defined (HAVE_ARM)
+#include <linux/unistd.h>
 # define SYS_process_vm_readv   (__NR_SYSCALL_BASE + 376)
 # define SYS_process_vm_writev  (__NR_SYSCALL_BASE + 377)
 # define SYS_memfd_create       (__NR_SYSCALL_BASE + 385)
diff --git a/src/linux/helpers/Makefile b/src/linux/helpers/Makefile
index 860ae080..91fc7e44 100644
--- a/src/linux/helpers/Makefile
+++ b/src/linux/helpers/Makefile
@@ -15,7 +15,7 @@ crossfile := $(BUILDDIR)/frida-$(host_machine).txt
 
 build: ext/linux/tools/include/nolibc/nolibc.h
 	rm -rf build
-	$(MESON) setup --cross-file $(crossfile) -Db_lto=true build
+	$(MESON) setup --cross-file $(crossfile) -Db_lto=false build
 	$(MESON) compile -C build
 	cp build/bootstrapper.bin bootstrapper-$(host_arch).bin
 	cp build/loader.bin loader-$(host_arch).bin

@WorksButNotTested
Copy link
Contributor

Dependency on memcpy or memset can often be caused by the compiler generating calls to them to initialize local variables rather than initializing them one field at a time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@zetier-hg @oleavr @WorksButNotTested
0