Message ID | 20190122161509.11014-1-chunkeey@gmail.com |
---|---|
State | RFC |
Delegated to: | Christian Lamparter |
Headers | show |
Series | [OpenWrt-Devel,RFT] toolchain/musl: update to version 1.1.21 | expand |
Hi Christian,
fwiw, I've been using every musl git bump up to this release on my
devices offshore. It has been running on ~65 devices covering multiple
arches. (armv6k-mpcore, armv7, mips24, mips74, x86_64)
Looks really ok to me, and I statistically do see a drop in weird
one-time issues compared to 1.1.20
Concerning the patch itself:
You probably will need to rebase and refresh the musl patches based on
the latest master state. I also created the bump in my staging tree when
1.1.21 it was released, and I have an additional patch refreshed, which
is a delta to yours.
Other than that:
Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
On Wednesday, January 23, 2019 2:26:20 PM CET Koen Vandeputte wrote: > Hi Christian, > > fwiw, I've been using every musl git bump up to this release on my > devices offshore. It has been running on ~65 devices covering multiple > arches. (armv6k-mpcore, armv7, mips24, mips74, x86_64) > > Looks really ok to me, and I statistically do see a drop in weird > one-time issues compared to 1.1.20 > > Concerning the patch itself: > > You probably will need to rebase and refresh the musl patches based on > the latest master state. I also created the bump in my staging tree when > 1.1.21 it was released, and I have an additional patch refreshed, which > is a delta to yours. You are right, I had a version bump in my tree that updated the offsets of 110-read_timezone_from_fs.patch. With it the patches are identical (apart from the commit message). > Other than that: > > Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> I'm a bit worried about: "This release makes improvements with respect to default thread stack size, including increasing the default from 80k to 128k, increasing the default guard size from 4k to 8k, and allowing the default to be increased via ELF headers so that programs that need larger stacks can be build without source-level changes, using just LDFLAGS." and it's impact on LOWMEM devices. Currently, I'm looking into making some "before and after" comparisions before moving on. Regards, Christian
On Wednesday, January 23, 2019 6:54:11 PM CET Christian Lamparter wrote: > On Wednesday, January 23, 2019 2:26:20 PM CET Koen Vandeputte wrote: > > Hi Christian, > > > > fwiw, I've been using every musl git bump up to this release on my > > devices offshore. It has been running on ~65 devices covering multiple > > arches. (armv6k-mpcore, armv7, mips24, mips74, x86_64) > > > > Looks really ok to me, and I statistically do see a drop in weird > > one-time issues compared to 1.1.20 > > > > Concerning the patch itself: > > > > You probably will need to rebase and refresh the musl patches based on > > the latest master state. I also created the bump in my staging tree when > > 1.1.21 it was released, and I have an additional patch refreshed, which > > is a delta to yours. > You are right, I had a version bump in my tree that updated the offsets of > 110-read_timezone_from_fs.patch. With it the patches are identical (apart > from the commit message). > > > Other than that: > > > > Tested-by: Koen Vandeputte <koen.vandeputte@ncentric.com> > > I'm a bit worried about: > "This release makes improvements with respect to default thread stack > size, including increasing the default from 80k to 128k, increasing > the default guard size from 4k to 8k, and allowing the default to be > increased via ELF headers so that programs that need larger stacks can > be build without source-level changes, using just LDFLAGS." and it's > impact on LOWMEM devices. Currently, I'm looking into making some > "before and after" comparisions before moving on. Results are in. On most of my OpenWrt devices (which have 64 MiB and more) there is hardly any change in the memory consumption. So I focused just on my most memory starved device: a WD My Range Extender AR9344/AR7010(ath79) which has a MemTotal (/proc/meminfo) of 26900 KiB. On this device the RAM consumption went up when it was running the proposed musl-1.1.21 by 44 KiB (or about a extra 4 KiB page per process). Whereas the uncompressed squash image size slightly decreased by about a 1 KIB. The RAM changes are almost indistinguishable from the noise and there's a tiny ROM size advantage... But more importantly, there hasn't been any worriesome reports on the ML or updates on musl's git. I do think this is ready, but the question is, should we add it "now" so it will be in 19.01? I know that Hauke's mentioned in his 19.01 plans back in 2018 November: <http://lists.infradead.org/pipermail/openwrt-devel/2018-November/014526.html> That musl could be upgraded to 1.1.21? But back then, musl 1.1.21 was just on the roadmap. Regards, Christian
diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk index 40c6273e63..b52263c43b 100644 --- a/toolchain/musl/common.mk +++ b/toolchain/musl/common.mk @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/target.mk PKG_NAME:=musl -PKG_VERSION:=1.1.20 -PKG_RELEASE:=2 +PKG_VERSION:=1.1.21 +PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) -PKG_SOURCE_VERSION:=0fa1e638e87cf257e9f96b4019b2076afd674a19 -PKG_MIRROR_HASH:=0a49559e845f51aaf006539176a36d6527957affd2838e71fd43275b737e90fe +PKG_SOURCE_VERSION:=1691b23955590d1eb66a11158fdd91c86337e886 +PKG_MIRROR_HASH:=4fa312d0ca020d31603ced84a7103fb328c6ae9508239491a228be17e7807147 PKG_SOURCE_URL:=git://git.musl-libc.org/musl PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz diff --git a/toolchain/musl/patches/200-add_libssp_nonshared.patch b/toolchain/musl/patches/200-add_libssp_nonshared.patch index b8fa7b4b4f..05bd2fe54a 100644 --- a/toolchain/musl/patches/200-add_libssp_nonshared.patch +++ b/toolchain/musl/patches/200-add_libssp_nonshared.patch @@ -24,7 +24,7 @@ Signed-off-by: Steven Barth <steven@midlink.org> +OBJ_DIRS = $(sort $(patsubst %/,%,$(dir $(ALL_LIBS) $(ALL_TOOLS) $(ALL_OBJS) $(GENH) $(GENH_INT))) obj/include obj/libssp_nonshared) $(ALL_LIBS) $(ALL_TOOLS) $(ALL_OBJS) $(ALL_OBJS:%.o=%.lo) $(GENH) $(GENH_INT): | $(OBJ_DIRS) - + @@ -113,6 +113,8 @@ obj/crt/rcrt1.o: $(srcdir)/ldso/dlstart. obj/crt/Scrt1.o obj/crt/rcrt1.o: CFLAGS_ALL += -fPIC @@ -34,7 +34,7 @@ Signed-off-by: Steven Barth <steven@midlink.org> OPTIMIZE_SRCS = $(wildcard $(OPTIMIZE_GLOBS:%=$(srcdir)/src/%)) $(OPTIMIZE_SRCS:$(srcdir)/%.c=obj/%.o) $(OPTIMIZE_SRCS:$(srcdir)/%.c=obj/%.lo): CFLAGS += -O3 -@@ -165,6 +166,11 @@ lib/libc.a: $(AOBJS) +@@ -165,6 +167,11 @@ lib/libc.a: $(AOBJS) $(AR) rc $@ $(AOBJS) $(RANLIB) $@
<https://www.openwall.com/lists/musl/2019/01/21/8> "This release makes improvements with respect to default thread stack size, including increasing the default from 80k to 128k, increasing the default guard size from 4k to 8k, and allowing the default to be increased via ELF headers so that programs that need larger stacks can be build without source-level changes, using just LDFLAGS. Insufficient stack size for AIO threads on kernels that don't honor the constant MINSIGSTKSZ is also fixed. The glob core has been rewritten to fix inability to see past searchable-but-unreadable path components, and to avoid excessive stack usage and unnecessary syscalls. The tsearch AVL tree implementation has also been rewritten for better size and performance. The math library adds more native single-instruction implementations for arm, s390x, powerpc, and x86_64. Various bugs are fixed, including several possible deadlocks, one of which was a new regression in 1.1.20." Signed-off-by: Christian Lamparter <chunkeey@gmail.com> --- toolchain/musl/common.mk | 8 ++++---- toolchain/musl/patches/200-add_libssp_nonshared.patch | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-)