From owner-freebsd-toolchain@freebsd.org Mon Dec 12 21:11:58 2016 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 165A6C739A2; Mon, 12 Dec 2016 21:11:58 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 9D4221F29; Mon, 12 Dec 2016 21:11:57 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id D58E5A35642; Mon, 12 Dec 2016 22:09:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1481576962; bh=lqiJ6kDxVcnWgjuN7nB/UaDHEnFcv7pF9TsEzWTth80=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=NWsuVjqS+44Kj9tJh0hVymqTXqSt7W3kNSQb76DizRemIlFo1ngAnRcyxN2zvvu1s 3c0VdhlCm/GF8PUdDww+ZMObqIJ1Xo3cdsGhaRFpDecjEZQY2+aJsAOkttBYoQ/srl eRB6h2a2MBlP2sJU5ggWM6883clAAaakieIjNc0M= Date: Mon, 12 Dec 2016 22:09:22 +0100 From: Roman Divacky To: Mark Millard Cc: FreeBSD Toolchain , Justin Hibbits , FreeBSD PowerPC ML , nwhitehorn@freebsd.org Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-ID: <20161212210922.GA27403@vlakno.cz> References: <20161205161904.GA7889@vlakno.cz> <126E2EDE-9499-4103-A3DB-CC517105DAB2@dsl-only.net> <20161207190057.GA58950@vlakno.cz> <20161208185541.GA33364@vlakno.cz> <20161208221452.GA42380@vlakno.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161208221452.GA42380@vlakno.cz> User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 21:11:58 -0000 Ping.... Can you take a look Nathan? Thanks! Roman On Thu, Dec 08, 2016 at 11:14:52PM +0100, Roman Divacky wrote: > I believe the code comes from sys/powerpc/aim/locore64.S and if you compare > the different values from the disssembly with the .S code you can see > it's __tocbase and TOC_REF(). > > I wonder if the assembly has the -mminimal-toc knowledge hardcoded in somehow. > I am not sure what expectations the locore64.S has about the kernel layout that > we're probably breaking. > > I've CCed Nathan Whitehorn. Nathan, can you take a look please? > > Thanks, Roman > > On Thu, Dec 08, 2016 at 02:03:58PM -0800, Mark Millard wrote: > > [I have dropped the patch related information and just have > > failing-boot related information here.] > > > > On 2016-Dec-8, at 10:55 AM, Roman Divacky wrote: > > > > > Can you try to investigate why it dies? I am not convinced -mminimal-toc > > > would result in a boot failure. I think the kernel would fail to link. > > > > I give information for both devel/powerpc64-binutils based > > and for WITH_BINUTILS_BOOTSTRAP= based. They are different. > > > > For using 2.25.1 of devel/powerpc64-binutils (a cross build): > > (from camera image of screen) > > > > . . . (omitted material) . . . > > Type '?' for a list of commands, 'help' for more detailed help. > > OK unload > > OK boot ker390 > > /boot/ker390/kernel data=0xf851a8+0x42dd98 syms=[0x8+0xd6848+0x8+0xf1137] > > /boot/entropy size=0x1000 > > Booting. . . > > Kernel entry at 0x100160 > > > > Invalid memory access at %SSR0: 00000000.001001b0 %SRR1:90000000.00003030 > > > > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > > . . . (omitted material) . . . > > ok > > 0 > > > > > The only options at this point are: > > > > mac-boot > > shut-down > > > > > > From objdump for the above failing boot > > but with notes added: > > (Note: booting xtoolchain kernel starts at > > 0000000000100120 instead; relative > > offsets are unchanged and the code > > is mostly the same.) > > > > Disassembly of section .text: > > 0000000000100160 <.__start> mfmsr r20 > > 0000000000100164 <.__start+0x4> li r21,1 > > 0000000000100168 <.__start+0x8> rldimi r20,r21,63,0 > > 000000000010016c <.__start+0xc> mtmsrd r20 > > 0000000000100170 <.__start+0x10> isync > > 0000000000100174 <.__start+0x14> nop > > 0000000000100178 <.__start+0x18> b 0000000000100180 <.__start+0x20> > > 000000000010017c <.__start+0x1c> nop > > 0000000000100180 <.__start+0x20> nop > > 0000000000100184 <.__start+0x24> bl 0000000000100190 <.__start+0x30> > > 0000000000100188 <.__start+0x28> .long 0x0 > > 000000000010018c <.__start+0x2c> .long 0xf8ce78 > > booting xtoolchain based kernel has: 0xfebeb8 above <<<=== note > > 0000000000100190 <.__start+0x30> mflr r2 > > 0000000000100194 <.__start+0x34> ld r1,0(r2) > > 0000000000100198 <.__start+0x38> add r2,r1,r2 > > 000000000010019c <.__start+0x3c> ld r31,-32768(r2) > > 00000000001001a0 <.__start+0x40> subf r31,r31,r2 > > 00000000001001a4 <.__start+0x44> ld r1,0(r2) <<<=== !!!!! > > booting xtoolchain based kernel has: r1,-32760(r2) above <<<=== !!!!! > > 00000000001001a8 <.__start+0x48> addi r1,r1,16288 > > 00000000001001ac <.__start+0x4c> add r1,r1,r31 > > 00000000001001b0 <.__start+0x50> std r3,48(r1) > > SRR0 points at the above instruction > > (I stopped comparing to the booting xtoolchain > > based code after this.) > > 00000000001001b4 <.__start+0x54> std r4,56(r1) > > 00000000001001b8 <.__start+0x58> std r5,64(r1) > > 00000000001001bc <.__start+0x5c> std r6,72(r1) > > 00000000001001c0 <.__start+0x60> bl 00000000001001cc <.__start+0x6c> > > 00000000001001c4 <.__start+0x64> .long 0x0 > > 00000000001001c8 <.__start+0x68> .long 0xf84ed4 > > 00000000001001cc <.__start+0x6c> mflr r3 > > 00000000001001d0 <.__start+0x70> ld r4,0(r3) > > 00000000001001d4 <.__start+0x74> add r3,r4,r3 > > 00000000001001d8 <.__start+0x78> mr r4,r31 > > 00000000001001dc <.__start+0x7c> bl 0000000000b18ebc <.elf_reloc_self> > > 00000000001001e0 <.__start+0x80> nop > > 00000000001001e4 <.__start+0x84> ld r3,48(r1) > > 00000000001001e8 <.__start+0x88> ld r4,56(r1) > > 00000000001001ec <.__start+0x8c> ld r5,64(r1) > > 00000000001001f0 <.__start+0x90> ld r6,72(r1) > > 00000000001001f4 <.__start+0x94> mr r4,r2 > > 00000000001001f8 <.__start+0x98> bl 0000000000b1e980 <.powerpc_init> > > 00000000001001fc <.__start+0x9c> nop > > 0000000000100200 <.__start+0xa0> mr r1,r3 > > 0000000000100204 <.__start+0xa4> li r3,0 > > 0000000000100208 <.__start+0xa8> std r3,0(r1) > > 000000000010020c <.__start+0xac> bl 00000000005c4af8 <.mi_startup> > > 0000000000100210 <.__start+0xb0> nop > > 0000000000100214 <.__start+0xb4> b 0000000000100214 <.__start+0xb4> > > > > > > > > For using WITH_BINUTILS_BOOTSTRAP= based binutils (a cross build): > > (completes for buildkernel; fails for buildworld) > > > > . . . (omitted material) . . . > > Type '?' for a list of commands, 'help' for more detailed help. > > OK unload > > OK boot ker39a > > /boot/ker39a/kernel data=0xfd6318+0x42dda8 syms=[0x8+0xd6860+0x8+0xf1193] > > /boot/entropy size=0x1000 > > Booting. . . > > Kernel entry at 0x100160 > > > > Invalid memory access at %SSR0: 00000000.00000000 %SRR1:10000000.00081000 > > > > Apple PowerMac11,2 5.2.7f1 BootROM builtin on 09/30/005 at 15:31:03 > > . . . (omitted material) . . . > > ok > > 0 > > > > > The only options at this point are: > > > > mac-boot > > shut-down > > > > The problem here is a different code order and a matching > > wrong start address that does not track the difference. > > (From objdump.) Note: the same 0(r2) vs. -32760(r2) oddity > > exists in the start routine as well. > > > > Disassembly of section .text: > > 0000000000100160 <.__start-0x2030> std r2,40(r1) > > 0000000000100164 <.__start-0x202c> addis r2,r2,1 > > 0000000000100168 <.__start-0x2028> addi r2,r2,-8 > > 000000000010016c <.__start-0x2024> b 0000000000b2c8e0 <.cpu_switch> > > 0000000000100170 <.__start-0x2020> std r2,40(r1) > > 0000000000100174 <.__start-0x201c> addis r2,r2,1 > > 0000000000100178 <.__start-0x2018> addi r2,r2,-8 > > 000000000010017c <.__start-0x2014> b 0000000000ade6c8 <.sf_buf_alloc> > > 0000000000100180 <.__start-0x2010> std r2,40(r1) > > 0000000000100184 <.__start-0x200c> addis r2,r2,1 > > 0000000000100188 <.__start-0x2008> addi r2,r2,-8 > > 000000000010018c <.__start-0x2004> b 0000000000a83f78 <.vm_fault_hold> > > 0000000000100190 <.__start-0x2000> std r2,40(r1) > > 0000000000100194 <.__start-0x1ffc> addis r2,r2,1 > > 0000000000100198 <.__start-0x1ff8> addi r2,r2,-8 > > 000000000010019c <.__start-0x1ff4> b 0000000000b1f1e8 <.fill_regs32> > > 00000000001001a0 <.__start-0x1ff0> std r2,40(r1) > > 00000000001001a4 <.__start-0x1fec> addis r2,r2,1 > > 00000000001001a8 <.__start-0x1fe8> addi r2,r2,-8 > > 00000000001001ac <.__start-0x1fe4> b 0000000000b1a7e4 <.casueword32> > > 00000000001001b0 <.__start-0x1fe0> std r2,40(r1) > > 00000000001001b4 <.__start-0x1fdc> addis r2,r2,1 > > 00000000001001b8 <.__start-0x1fd8> addi r2,r2,-8 > > 00000000001001bc <.__start-0x1fd4> b 0000000000a8fa30 <.kmap_free_wakeup> > > . . . > > 0000000000102190 <.__start> mfmsr r20 > > 0000000000102194 <.__start+0x4> li r21,1 > > 0000000000102198 <.__start+0x8> rldimi r20,r21,63,0 > > 000000000010219c <.__start+0xc> mtmsrd r20 > > 00000000001021a0 <.__start+0x10> isync > > 00000000001021a4 <.__start+0x14> nop > > 00000000001021a8 <.__start+0x18> b 00000000001021b0 <.__start+0x20> > > 00000000001021ac <.__start+0x1c> nop > > 00000000001021b0 <.__start+0x20> nop > > 00000000001021b4 <.__start+0x24> bl 00000000001021c0 <.__start+0x30> > > 00000000001021b8 <.__start+0x28> .long 0x0 > > 00000000001021bc <.__start+0x2c> .long 0xfc8e48 > > 00000000001021c0 <.__start+0x30> mflr r2 > > 00000000001021c4 <.__start+0x34> ld r1,0(r2) > > 00000000001021c8 <.__start+0x38> add r2,r1,r2 > > 00000000001021cc <.__start+0x3c> ld r31,-32768(r2) > > 00000000001021d0 <.__start+0x40> subf r31,r31,r2 > > 00000000001021d4 <.__start+0x44> ld r1,0(r2) <<< same 0 vs. -32760 oddity!!! > > 00000000001021d8 <.__start+0x48> addi r1,r1,16288 > > 00000000001021dc <.__start+0x4c> add r1,r1,r31 > > 00000000001021e0 <.__start+0x50> std r3,48(r1) > > 00000000001021e4 <.__start+0x54> std r4,56(r1) > > 00000000001021e8 <.__start+0x58> std r5,64(r1) > > 00000000001021ec <.__start+0x5c> std r6,72(r1) > > 00000000001021f0 <.__start+0x60> bl 00000000001021fc <.__start+0x6c> > > 00000000001021f4 <.__start+0x64> .long 0x0 > > 00000000001021f8 <.__start+0x68> .long 0xfd4014 > > 00000000001021fc <.__start+0x6c> mflr r3 > > 0000000000102200 <.__start+0x70> ld r4,0(r3) > > 0000000000102204 <.__start+0x74> add r3,r4,r3 > > 0000000000102208 <.__start+0x78> mr r4,r31 > > 000000000010220c <.__start+0x7c> bl 0000000000101a20 > > 0000000000102210 <.__start+0x80> ld r2,40(r1) > > 0000000000102214 <.__start+0x84> ld r3,48(r1) > > 0000000000102218 <.__start+0x88> ld r4,56(r1) > > 000000000010221c <.__start+0x8c> ld r5,64(r1) > > 0000000000102220 <.__start+0x90> ld r6,72(r1) > > 0000000000102224 <.__start+0x94> mr r4,r2 > > 0000000000102228 <.__start+0x98> bl 00000000001019a0 > > 000000000010222c <.__start+0x9c> ld r2,40(r1) > > 0000000000102230 <.__start+0xa0> mr r1,r3 > > 0000000000102234 <.__start+0xa4> li r3,0 > > 0000000000102238 <.__start+0xa8> std r3,0(r1) > > 000000000010223c <.__start+0xac> bl 00000000005c6b28 <.mi_startup> > > 0000000000102240 <.__start+0xb0> nop > > 0000000000102244 <.__start+0xb4> b 0000000000102244 <.__start+0xb4> > > > > > > Who is most appropriate to send such information to for powerpc64? > > > > === > > Mark Millard > > markmi at dsl-only.net