Date: Fri, 06 Jan 2017 22:43:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-toolchain@FreeBSD.org Subject: [Bug 215821] head -r311147's bootstrapped ld for TARGET_ARCH=powerpc64 produces kernel.full as a "shared object" for -pie instead of as a "executable": booting the produced kernel crashes Message-ID: <bug-215821-29464-pFhPX6F8nj@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-215821-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-215821-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=3D215821 --- Comment #1 from Mark Millard <markmi@dsl-only.net> --- (In reply to Mark Millard from comment #0) Note: It looks like FreeBSD's ld interpretation of -pie is odd but long standing and FreeBSD may be designed to handle the oddity. Some supporting notes from a list reply follow. . . Nathon wrote in https://lists.freebsd.org/pipermail/freebsd-ppc/2015-January/007375.html that: This is the first architecture to have a PIE kernel, however, so I'd=20 like some feedback on the approach. The major immediate difficulty is=20 that PIE kernels are ET_DYN ELF executables. He said "executable", not "shared object" but also said "ET_DYN". I'll note that the flags from the different versions of ld (system binutils vs. devel/*binutils) ends up with different flags (system first, then devel/*binutils) for -pie being specified: architecture: powerpc:common64, flags 0x00000150: HAS_SYMS, DYNAMIC, D_PAGED start address 0x00000000010cf848 The above sort of case also has .branch_lt sections involved. (gcc 4.2.1 and clang, I've not tried xtoolchain mixed with the bootstrapped ld.) architecture: powerpc:common64, flags 0x00000112: EXEC_P, HAS_SYMS, D_PAGED start address 0x000000000108b6c8 The above sort of case does not have .branch_lt sections involved. (clang and xtoolchain, I've not tried gcc 4.2.1 with devel/*binutils based ld.) [They are not the same builds so the address difference is expected. And the start addresses do not match the "<.__start> mfmsr r20" in either case and is not where the kernel code execution starts on the PowerMac G5's.] It appears to me that the system ld and the devel/*binutils ld do not agree for what -pie generates. I would guess that -pie should involve the EXEC_P flag and so be a executable according to the flags and that an executable would not have .branch_lt . In other words: devel/*binutils is correct in that much by my guess. Another wording of that would be: for the system ld "-pie" is "in name only" or has a "special FreeBSD definition" from what I can tell. Another difference is that the EXEC_P examples from devel/*binutils later list: private flags =3D 0x1: [abiv1] at the end of the Dynamic Section but the HAS_SYMS examples do not list such an indication of the abi. But that note from Nathan also had: load_elf.c with: +#if defined(__powerpc__) && __ELF_WORD_SIZE =3D=3D 64 + } else if (ehdr->e_type =3D=3D ET_EXEC || + (ehdr->e_type =3D=3D ET_DYN && ehdr->e_entry !=3D 0)) { +#else } else if (ehdr->e_type =3D=3D ET_EXEC) { +#endif Makefile.powerpc with: +.if ${MACHINE_ARCH} =3D=3D "powerpc64" +CFLAGS+=3D -fPIC +LDFLAGS+=3D -pie +.endif kmod.mk with: +# Don't add a fake entry point to modules +_LDFLAGS+=3D -e 0 [The .meta files show the -pie option that specifies position independent executable. That includes when I use gcc 4.2.1 in the modern context.] load_elf.c suggests trying to handle what the bootstrap ld does with -pie . When I try a bootstrapped gcc 4.2.1 based buildkernel I get a kernel file with: . . . Disassembly of section .text: 0000000000100160 <.__start-0x2350> std r2,40(r1) 0000000000100164 <.__start-0x234c> addis r2,r2,1 0000000000100168 <.__start-0x2348> addi r2,r2,-520 000000000010016c <.__start-0x2344> b 0000000000368d38 <.pci_find_dbsf> 0000000000100170 <.__start-0x2340> std r2,40(r1) . . . 00000000001024b0 <.__start> mfmsr r20 00000000001024b4 <.__start+0x4> li r21,1 00000000001024b8 <.__start+0x8> rldimi r20,r21,63,0 00000000001024bc <.__start+0xc> mtmsrd r20 00000000001024c0 <.__start+0x10> isync Note the "40(r1)" use of an uninitialized r1 if the code starts at 0000000000100160 and the branch to .pci_find_dbsf as well. With this code the execution needs to not start at 0000000000100160 . [Justin: What does your example look like for such?] Later I'll try installing and booting this gcc4.2.1 based kernel but so far it looks like other non-gcc 4.2.1 based ones that used the bootstrapped ld and that actually start at what would be 0000000000100160 in the above example above and quickly fails on the PowerMac G5 so-called "Quad Core" that I currently have access to. If it boots I'll see if I can track down another difference in how things start for kernel execution. But clang mishandles what should be R_PPC64_TOC16_DS with .toc and so the boot \ fails for lack of correct offsets in addressing, such has 0(r2) instead of something like -32760(r2). This alone blocks getting very far for booting based on clang: Both variants of ld get boot failure for clang as stands, just with some different details in how/when/where it fails. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-215821-29464-pFhPX6F8nj>