Date: Fri, 21 Oct 2022 23:09:53 -0700 From: Mark Millard <marklmi@yahoo.com> To: Konstantin Belousov <kostikbel@gmail.com>, dev-commits-src-main@freebsd.org Subject: Re: git: 9cabef3d146e - main - ldd: use direct exec mode unconditionally Message-ID: <0D5A9F6F-C19B-487D-BD61-F40F02E38873@yahoo.com> References: <0D5A9F6F-C19B-487D-BD61-F40F02E38873.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Konstantin Belousov <kostikbel_at_gmail.com> wrote on
Date: Sat, 22 Oct 2022 01:13:49 UTC :
> . . .
> Please try something along this lines:
>=20
> diff --git a/sys/arm64/include/elf.h b/sys/arm64/include/elf.h
> index 3f7c3964d428..22e968c632bf 100644
> --- a/sys/arm64/include/elf.h
> +++ b/sys/arm64/include/elf.h
> @@ -86,7 +86,7 @@ __ElfType(Auxinfo);
> #endif
> =20
> #if __ELF_WORD_SIZE =3D=3D 32
> -#define ET_DYN_LOAD_ADDR 0x12000
> +#define ET_DYN_LOAD_ADDR 0x01001000
> #else
> #define ET_DYN_LOAD_ADDR 0x100000
> #endif
[Summary: that made it work.]
First I did some as-is testing . . .
Testing for the problem is easy on the Cortex-A72 system . . .
# ~/do-chroot-main-CA7.sh
# ldd /bin/date
/bin/date:
ld-elf.so.1: /bin/date: mmap of entire address space failed: Cannot =
allocate memory
/bin/date: exit status 1
# ldd -a /bin/date
ld-elf.so.1: /bin/date: mmap of entire address space failed: Cannot =
allocate memory
/bin/date: exit status 1
By contrast, on a 2 GiByte RAM Cortex-A7 (armv7)
Orange Pi Plus 2 Ed, the result is different:
# ldd /bin/date
/bin/date:
libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x2056e000)
libc.so.7 =3D> /lib/libc.so.7 (0x205a8000)
# ldd -a /bin/date
/bin/date:
libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x2056e000)
libc.so.7 =3D> /lib/libc.so.7 (0x205a8000)
/lib/libgcc_s.so.1:
libc.so.7 =3D> /lib/libc.so.7 (0x205a8000)
For reference (long output line split for readability):
# uname -apKU
FreeBSD OPiP2E_RPI2v1p1 14.0-CURRENT FreeBSD 14.0-CURRENT #49
main-n258610-ba7319e9091b-dirty: Fri Oct 14 18:27:46 PDT 2022
=
root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a=
rmv7/sys/GENERIC-NODBG-CA7
arm armv7 1400072 1400072
(It was installed from the same buildworld buildkernel as
tree used to set up the chroot tree on the Cortex-A72 system.)
Same boot media, but booting a 1 GiByte RAM Cortex-A7 (armv7)
RPi2B v1.1:
# ldd /bin/date
/bin/date:
libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x2056e000)
libc.so.7 =3D> /lib/libc.so.7 (0x205a8000)
# ldd -a /bin/date
/bin/date:
libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x2056e000)
libc.so.7 =3D> /lib/libc.so.7 (0x205a8000)
/lib/libgcc_s.so.1:
libc.so.7 =3D> /lib/libc.so.7 (0x205a8000)
In case it matters, these Cortex-A7's have LPAE
(RPi2B v1.1 shown):
CPU Features:=20
Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, =
VMSAv7,
PXN, LPAE, Coherent Walk
So only the aarch64 context that allows armv7 shows the
problem.
Then I did the requested aarch64 test with the patch . . .
So, for that aarch64 context, the patch test requested:
# git -C /usr/main-src/ diff /usr/main-src/sys/arm64/include/
diff --git a/sys/arm64/include/elf.h b/sys/arm64/include/elf.h
index 3f7c3964d428..22e968c632bf 100644
--- a/sys/arm64/include/elf.h
+++ b/sys/arm64/include/elf.h
@@ -86,7 +86,7 @@ __ElfType(Auxinfo);
#endif
=20
#if __ELF_WORD_SIZE =3D=3D 32
-#define ET_DYN_LOAD_ADDR 0x12000
+#define ET_DYN_LOAD_ADDR 0x01001000
#else
#define ET_DYN_LOAD_ADDR 0x100000
#endif
Then: builworld buildkernel installkernel installworld reboot
login. The results in that new context were:
# ~/do-chroot-main-CA7.sh
# ldd /bin/date
/bin/date:
libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x4106f000)
libc.so.7 =3D> /lib/libc.so.7 (0x410a9000)
# ldd -a /bin/date
/bin/date:
libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x4106f000)
libc.so.7 =3D> /lib/libc.so.7 (0x410a9000)
/lib/libgcc_s.so.1:
libc.so.7 =3D> /lib/libc.so.7 (0x410a9000)
So: works.
NOTES:
I do not have any armv6, i386, or 32-bit powerpc contexts
set up to test, not that the specific patch targets the
i386 or targets any powerpc's. (armv6 requires adjusting
the kernel to instead not target armv7 chroot/jail support.
Long ago I helped someone work out having an alternate
kernel to boot for such armv6 chroot/jail use, not that I
remember any detail at this point. The detail should be in
my E-mail archive and/or in comments for a bugzilla
submittal that the person had used to report the lack of
armv6 chroot/jail support.)
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D5A9F6F-C19B-487D-BD61-F40F02E38873>