Date: Fri, 05 Oct 2018 19:57:06 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230857] loading carp module panic i386 kernel (VIMAGE related) Message-ID: <bug-230857-29464-p8yxEL5GjP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-230857-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-230857-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230857 Bjoern A. Zeeb <bz@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress --- Comment #4 from Bjoern A. Zeeb <bz@FreeBSD.org> --- Ok, so the short explanation is that having a non-simple-type at the end of= the dpcpu or vnet linker sets and an intelligent compiler/linker combination can result in the last symbol not being relocated. In the case of i386/carp th= is was the PCPU stats glebius introduced which is an array of 16 pointers. I've spent a day to think of possible work around and the only one was to a= dd padding to the end of the section; with the help of arichardson managed to work my way around linker scripts and with an extra 8 hours I have a dual-s= tage linker-script solution which will only adjust the kernel modules which actu= ally do have a vnet_set or pcpu_set section and not create one in every module w= ith the size of 1 byte. I'll write the entire details up including sample code and the hacked up prototype solution and post it all here and in phab sometime the next days (possibly after the weekend). TODO: investigate which other architectures but i386 are possibly affected = by this as well. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-230857-29464-p8yxEL5GjP>