Hello, I would like to work on this issue

Nice!
Basically, the test should check that there's no call to my_func in the generated asm, meaning that there was inlining between different crates.
If you have any questions, don't hesitate to ask.

I am trying to build with LTO using

EMBED_LTO_BITCODE=1 CHANNEL="debug" ./y.sh cargo build --manifest-path tests/hello-world/Cargo.toml

However after building, i checked the binary with objdump -dj .text target/debug/hello_world. I can see the asm for call present

00000000000efab1 <_ZN11hello_world4main17h248b5759c97214e8E>:
   efab1:	55                   	push   %rbp
   efab2:	48 89 e5             	mov    %rsp,%rbp
   efab5:	48 83 ec 60          	sub    $0x60,%rsp
   efab9:	be 0a 00 00 00       	mov    $0xa,%esi
   efabe:	bf 05 00 00 00       	mov    $0x5,%edi
   efac3:	e8 2a ff 02 00       	call   11f9f2 <_ZN5mylib7my_func17hb2cbd8e97cd6f643E>

Am I doing something wrong? LTO is not being setup correctly

You might be missing the --release flag to you y.sh cargo build command in order to enable the optimizations that would do the inlining.

I am trying to understand the code a bit more, what exactly is the difference between gcc-13.deb and libgccjit.so? It seems the release.yml uses gcc-13.deb as gcc-path, but the default build systems installs libgccjit instead.
Because if i run the steps

$ ./y.sh prepare
$ ./y.sh build --sysroot
$ EMBED_LTO_BITCODE=1 CHANNEL="debug" ./y.sh cargo build --release --manifest-path tests/hello-world/Cargo.toml

I get the error,

x86_64-pc-linux-gnu-gcc-15.0.0: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found

However I can find the lib in /usr/lib/gcc

$ ls -la /usr/lib/gcc/x86_64-linux-gnu/11/liblto_plugin.so 
-rw-r--r-- 1 root root 89120 May 13  2023 /usr/lib/gcc/x86_64-linux-gnu/11/liblto_plugin.so

Try to comment this line: it might not be necessary anymore as the comment above suggests and will make it easier to use LTO locally (since it won't require having the exact same version of the gcc driver and libgccjit.so, which is usually required for LTO so that they use the same version of the intermediate representation).

It seems that it is not correctly reading the gcc path I think? Since I again get an error

x86_64-pc-linux-gnu-gcc-15.0.0: fatal error: cannot execute ‘lto1’: posix_spawnp: No such file or directory

However, lto1 is also a file present in /usr/lib/gcc

 ls -la /usr/lib/gcc/x86_64-linux-gnu/11/lto1
-rwxr-xr-x 1 root root 24887296 May 13  2023 /usr/lib/gcc/x86_64-linux-gnu/11/lto1

GCC needs to use the same version for both lto and libgccjit so /usr/lib/gcc/x86_64-linux-gnu/11/ is not going to work.

How did you build libgccjit?
If you followed the instructions there, it's missing the lto frontend, so you would need to configure with it --enable-languages=jit,lto.