From owner-freebsd-ppc@freebsd.org Sun Feb 28 01:55:05 2016 Return-Path: Delivered-To: freebsd-ppc@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 A7D01AB61BE for ; Sun, 28 Feb 2016 01:55:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B0B21C4C for ; Sun, 28 Feb 2016 01:55:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19029 invoked from network); 28 Feb 2016 01:55:01 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 01:55:01 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 27 Feb 2016 20:55:16 -0500 (EST) Received: (qmail 5319 invoked from network); 28 Feb 2016 01:55:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 01:55:16 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B11781C43D0; Sat, 27 Feb 2016 17:54:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: Date: Sat, 27 Feb 2016 17:55:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> To: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Roman Divacky , Dimitry Andric X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 01:55:05 -0000 I discovered on powerpc that __builtin_dwarf_cfa() for clang 3.8.0 and = g++ do not agree. For powerpc this breaks C++ exception handling (via = the use in libgcc_s's unwind handling), resulting in uncaught exceptions = and SEGV's. objdump -d for the two line source file below shows the low = level differences. > extern void g(void*); > void f() { g(__builtin_dwarf_cfa()); } I've also shown the same issue for powerpc64. The issue is where g's argument value points relative to f's frame and = f's caller's frame (since __builtin_dwarf_cfa() is called by f, not g). And now for armv6 . . . > # clang++ -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf32-littlearm >=20 >=20 > Disassembly of section .text: > 00000000 <_Z1fv> push {fp, lr} > 00000004 <_Z1fv+0x4> mov fp, sp > 00000008 <_Z1fv+0x8> mov r0, fp > 0000000c <_Z1fv+0xc> bl 00000000 <_Z1gPv> > 00000010 <_Z1fv+0x10> pop {fp, pc} vs. > # g++5 -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf32-littlearm >=20 >=20 > Disassembly of section .text: > 00000000 <_Z1fv> push {fp, lr} > 00000004 <_Z1fv+0x4> add fp, sp, #4, 0 > 00000008 <_Z1fv+0x8> add r3, fp, #4, 0 > 0000000c <_Z1fv+0xc> mov r0, r3 > 00000010 <_Z1fv+0x10> bl 00000000 <_Z1gPv> > 00000014 <_Z1fv+0x14> nop ; (mov r0, r0) > 00000018 <_Z1fv+0x18> pop {fp, pc} They do not agree. So any infrastructure based on __builtin_dwarf_cfa() use will be = compiler sensitive for armv6 as well. [It is my understanding that what g++ does is what the normal sort of = .eh_frame infrastructure is designed for: pointing between the caller's = and called's frames.] For reference: powerpc64 and powerpc results. . . > # clang++ -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf64-powerpc-freebsd >=20 >=20 > Disassembly of section .text: > 0000000000000000 <._Z1fv> mflr r0 > 0000000000000004 <._Z1fv+0x4> std r31,-8(r1) > 0000000000000008 <._Z1fv+0x8> std r0,16(r1) > 000000000000000c <._Z1fv+0xc> stdu r1,-128(r1) > 0000000000000010 <._Z1fv+0x10> mr r31,r1 > 0000000000000014 <._Z1fv+0x14> mr r3,r31 > 0000000000000018 <._Z1fv+0x18> bl 0000000000000018 <._Z1fv+0x18> > 000000000000001c <._Z1fv+0x1c> nop > 0000000000000020 <._Z1fv+0x20> addi r1,r1,128 > 0000000000000024 <._Z1fv+0x24> ld r0,16(r1) > 0000000000000028 <._Z1fv+0x28> ld r31,-8(r1) > 000000000000002c <._Z1fv+0x2c> mtlr r0 > 0000000000000030 <._Z1fv+0x30> blr > ... r3 does not point to a boundary with f's caller's stack frame. By contrast for g++49: > # g++49 -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o | = more >=20 > builtin_dwarf_cfa.o: file format elf64-powerpc-freebsd >=20 >=20 > Disassembly of section .text: > 0000000000000000 <._Z1fv> mflr r0 > 0000000000000004 <._Z1fv+0x4> std r0,16(r1) > 0000000000000008 <._Z1fv+0x8> std r31,-8(r1) > 000000000000000c <._Z1fv+0xc> stdu r1,-128(r1) > 0000000000000010 <._Z1fv+0x10> mr r31,r1 > 0000000000000014 <._Z1fv+0x14> addi r9,r31,128 > 0000000000000018 <._Z1fv+0x18> mr r3,r9 > 000000000000001c <._Z1fv+0x1c> bl 000000000000001c <._Z1fv+0x1c> > 0000000000000020 <._Z1fv+0x20> nop > 0000000000000024 <._Z1fv+0x24> addi r1,r31,128 > 0000000000000028 <._Z1fv+0x28> ld r0,16(r1) > 000000000000002c <._Z1fv+0x2c> mtlr r0 > 0000000000000030 <._Z1fv+0x30> ld r31,-8(r1) > 0000000000000034 <._Z1fv+0x34> blr > 0000000000000038 <._Z1fv+0x38> .long 0x0 > 000000000000003c <._Z1fv+0x3c> .long 0x90001 > 0000000000000040 <._Z1fv+0x40> lwz r0,1(r1) r3 does point to a boundary with f's caller's stack frame. For TARGET_ARCH=3Dpowerpc, clang 3.8.0 first: > # clang++ -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf32-powerpc-freebsd >=20 >=20 > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> bl 00000018 <_Z1fv+0x18> > 0000001c <_Z1fv+0x1c> addi r1,r1,16 > 00000020 <_Z1fv+0x20> lwz r0,4(r1) > 00000024 <_Z1fv+0x24> lwz r31,-4(r1) > 00000028 <_Z1fv+0x28> mtlr r0 > 0000002c <_Z1fv+0x2c> blr Then g++5 (5.3): > # g++5 -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf32-powerpc-freebsd >=20 >=20 > Disassembly of section .text: > 00000000 <_Z1fv> stwu r1,-16(r1) > 00000004 <_Z1fv+0x4> mflr r0 > 00000008 <_Z1fv+0x8> stw r0,20(r1) > 0000000c <_Z1fv+0xc> stw r31,12(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> addi r9,r31,16 > 00000018 <_Z1fv+0x18> mr r3,r9 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> nop > 00000024 <_Z1fv+0x24> addi r11,r31,16 > 00000028 <_Z1fv+0x28> lwz r0,4(r11) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> lwz r31,-4(r11) > 00000034 <_Z1fv+0x34> mr r1,r11 > 00000038 <_Z1fv+0x38> blr The historical note below is from before I'd discovered powerpc64 or = armv6 have the same sort of issue. But it gives an example use that is = broken for powerpc and powerpc64. (I do not know if armv6 uses the same = infrastructure.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-27, at 3:31 PM, Mark Millard wrote: >=20 > [Top post for dinging the low level problem that directly breaks c++ = exception handling for TARGET_ARCH=3Dpowerpc for clang 3.8.0 generated = code.] >=20 > I've tracked down the c++ exception problem for TARGET_ARCH=3Dpowerpc = via clang 3.8.0: misbehavior of clang 3.8.0 code generation for = __builtin_dwarf_cfa () as used in: >=20 > #define uw_init_context(CONTEXT) = \ > do = \ > { = \ > /* Do any necessary initialization to access arbitrary stack = frames. \ > On the SPARC, this means flushing the register windows. */ = \ > __builtin_unwind_init (); = \ > uw_init_context_1 (CONTEXT, __builtin_dwarf_cfa (), = \ > __builtin_return_address (0)); = \ > } = \ > while (0) > . . . > 85 _Unwind_Reason_Code > 86 _Unwind_RaiseException(struct _Unwind_Exception *exc) > 87 { > 88 struct _Unwind_Context this_context, cur_context; > 89 _Unwind_Reason_Code code; > 90=09 > 91 /* Set up this_context to describe the current stack frame. = */ > 92 uw_init_context (&this_context); >=20 > In the below r4 ends up with the __builtin_dwarf_cfa () value supplied = to uw_init_context_1: >=20 > Dump of assembler code for function _Unwind_RaiseException: > 0x419a8fd8 <+0>: mflr r0 > 0x419a8fdc <+4>: stw r31,-148(r1) > 0x419a8fe0 <+8>: stw r30,-152(r1) > 0x419a8fe4 <+12>: stw r0,4(r1) > 0x419a8fe8 <+16>: stwu r1,-2992(r1) > 0x419a8fec <+20>: mr r31,r1 > . . . > 0x419a9094 <+188>: mr r4,r31 > 0x419a9098 <+192>: mflr r30 > 0x419a909c <+196>: lwz r5,2996(r31) > 0x419a90a0 <+200>: mr r3,r28 > 0x419a90a4 <+204>: bl 0x419a929c >=20 > That r4 ends up holding the stack pointer value for after it has been = decremented. r4 is not pointing at the boundary with the caller's frame. >=20 > The .eh_frame information and unwind code is set up for pointing at = the boundary with the caller's frame. So the cfa relative addressing is = messed up for what it actually extracts. >=20 > Contrast this with gcc/g++ 5.3's TARGET_ARCH=3Dpowerpc64 code where r4 = is made to be at the boundary with the caller's frame: >=20 > Dump of assembler code for function _Unwind_RaiseException: > 0x00000000501cb810 <+0>: mflr r0 > 0x00000000501cb814 <+4>: stdu r1,-5648(r1) > . . . > 0x00000000501cb8d0 <+192>: addi r4,r1,5648 > 0x00000000501cb8d4 <+196>: stw r12,5656(r1) > 0x00000000501cb8d8 <+200>: mr r28,r3 > 0x00000000501cb8dc <+204>: addi r31,r1,2544 > 0x00000000501cb8e0 <+208>: mr r3,r27 > 0x00000000501cb8e4 <+212>: addi r29,r1,112 > 0x00000000501cb8e8 <+216>: bl 0x501cae60 >=20 >=20 > NOTE: The powerpc (32-bit) issue may in some way be associated with = the clang 3.8.0 powerpc ABI violation in how it handles the stack = pointer for FreeBSD: TARGET_ARCH=3Dpowerpc is currently using a "red = zone", decrementing the stack pointer late, and incrementing the stack = pointer early compared to the FreeBSD ABI rules. (This is similar to the = official FreeBSD ABI for TARGET_ARCH=3Dpowerpc64.) >=20 >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Feb 28 08:41:58 2016 Return-Path: Delivered-To: freebsd-ppc@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 A1747AB7F02; Sun, 28 Feb 2016 08:41: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 32242188C; Sun, 28 Feb 2016 08:41:57 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 49D291E20F9C; Sun, 28 Feb 2016 09:39:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1456648774; bh=kdnu7GPiW5BPapHqf8pxugQ40PsHcIvJJjTTfaaTzX4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=LOZZTVzKU6rfjOclY1Av/Vsu40I0SMXGWL+ZFGWf/hjUpx4mtx8BYF7s2otcocOsp A7Xk96hKfB0qoTKYMSs9Ayd/ahaEvcvPdggdPJr8Knq2SXfe8vHd/YP2YTOgZ0E/Xk mKiPUYuNAdvwhHnIxodZ3wZVYmxob1mxVgp0ZLX4= Date: Sun, 28 Feb 2016 09:39:34 +0100 From: Roman Divacky To: Mark Millard Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Dimitry Andric Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update Message-ID: <20160228083934.GA60222@vlakno.cz> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 08:41:58 -0000 Mark, __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic eh_dwarf_cfa. There's a depth argument (which defaults to 0, saying it's correct for most targets). Then the intrinsic gets lowered in SelectionDAG using PPCTargetLowering::LowerFRAMEADDR() Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that LowerFRAMEADDR() does something sensible? There's a loop depth-times, so I wonder if that makes a difference. Thanks, Roman On Sat, Feb 27, 2016 at 05:55:02PM -0800, Mark Millard wrote: > I discovered on powerpc that __builtin_dwarf_cfa() for clang 3.8.0 and g++ do not agree. For powerpc this breaks C++ exception handling (via the use in libgcc_s's unwind handling), resulting in uncaught exceptions and SEGV's. objdump -d for the two line source file below shows the low level differences. > > > extern void g(void*); > > void f() { g(__builtin_dwarf_cfa()); } > > I've also shown the same issue for powerpc64. > > The issue is where g's argument value points relative to f's frame and f's caller's frame (since __builtin_dwarf_cfa() is called by f, not g). > > And now for armv6 . . . > > > # clang++ -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf32-littlearm > > > > > > Disassembly of section .text: > > 00000000 <_Z1fv> push {fp, lr} > > 00000004 <_Z1fv+0x4> mov fp, sp > > 00000008 <_Z1fv+0x8> mov r0, fp > > 0000000c <_Z1fv+0xc> bl 00000000 <_Z1gPv> > > 00000010 <_Z1fv+0x10> pop {fp, pc} > > vs. > > > # g++5 -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf32-littlearm > > > > > > Disassembly of section .text: > > 00000000 <_Z1fv> push {fp, lr} > > 00000004 <_Z1fv+0x4> add fp, sp, #4, 0 > > 00000008 <_Z1fv+0x8> add r3, fp, #4, 0 > > 0000000c <_Z1fv+0xc> mov r0, r3 > > 00000010 <_Z1fv+0x10> bl 00000000 <_Z1gPv> > > 00000014 <_Z1fv+0x14> nop ; (mov r0, r0) > > 00000018 <_Z1fv+0x18> pop {fp, pc} > > > They do not agree. > > So any infrastructure based on __builtin_dwarf_cfa() use will be compiler sensitive for armv6 as well. > > [It is my understanding that what g++ does is what the normal sort of .eh_frame infrastructure is designed for: pointing between the caller's and called's frames.] > > > For reference: powerpc64 and powerpc results. . . > > > # clang++ -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf64-powerpc-freebsd > > > > > > Disassembly of section .text: > > 0000000000000000 <._Z1fv> mflr r0 > > 0000000000000004 <._Z1fv+0x4> std r31,-8(r1) > > 0000000000000008 <._Z1fv+0x8> std r0,16(r1) > > 000000000000000c <._Z1fv+0xc> stdu r1,-128(r1) > > 0000000000000010 <._Z1fv+0x10> mr r31,r1 > > 0000000000000014 <._Z1fv+0x14> mr r3,r31 > > 0000000000000018 <._Z1fv+0x18> bl 0000000000000018 <._Z1fv+0x18> > > 000000000000001c <._Z1fv+0x1c> nop > > 0000000000000020 <._Z1fv+0x20> addi r1,r1,128 > > 0000000000000024 <._Z1fv+0x24> ld r0,16(r1) > > 0000000000000028 <._Z1fv+0x28> ld r31,-8(r1) > > 000000000000002c <._Z1fv+0x2c> mtlr r0 > > 0000000000000030 <._Z1fv+0x30> blr > > ... > > r3 does not point to a boundary with f's caller's stack frame. > > By contrast for g++49: > > > # g++49 -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o | more > > > > builtin_dwarf_cfa.o: file format elf64-powerpc-freebsd > > > > > > Disassembly of section .text: > > 0000000000000000 <._Z1fv> mflr r0 > > 0000000000000004 <._Z1fv+0x4> std r0,16(r1) > > 0000000000000008 <._Z1fv+0x8> std r31,-8(r1) > > 000000000000000c <._Z1fv+0xc> stdu r1,-128(r1) > > 0000000000000010 <._Z1fv+0x10> mr r31,r1 > > 0000000000000014 <._Z1fv+0x14> addi r9,r31,128 > > 0000000000000018 <._Z1fv+0x18> mr r3,r9 > > 000000000000001c <._Z1fv+0x1c> bl 000000000000001c <._Z1fv+0x1c> > > 0000000000000020 <._Z1fv+0x20> nop > > 0000000000000024 <._Z1fv+0x24> addi r1,r31,128 > > 0000000000000028 <._Z1fv+0x28> ld r0,16(r1) > > 000000000000002c <._Z1fv+0x2c> mtlr r0 > > 0000000000000030 <._Z1fv+0x30> ld r31,-8(r1) > > 0000000000000034 <._Z1fv+0x34> blr > > 0000000000000038 <._Z1fv+0x38> .long 0x0 > > 000000000000003c <._Z1fv+0x3c> .long 0x90001 > > 0000000000000040 <._Z1fv+0x40> lwz r0,1(r1) > > r3 does point to a boundary with f's caller's stack frame. > > For TARGET_ARCH=powerpc, clang 3.8.0 first: > > > # clang++ -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf32-powerpc-freebsd > > > > > > Disassembly of section .text: > > 00000000 <_Z1fv> mflr r0 > > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > > 00000008 <_Z1fv+0x8> stw r0,4(r1) > > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > > 00000010 <_Z1fv+0x10> mr r31,r1 > > 00000014 <_Z1fv+0x14> mr r3,r31 > > 00000018 <_Z1fv+0x18> bl 00000018 <_Z1fv+0x18> > > 0000001c <_Z1fv+0x1c> addi r1,r1,16 > > 00000020 <_Z1fv+0x20> lwz r0,4(r1) > > 00000024 <_Z1fv+0x24> lwz r31,-4(r1) > > 00000028 <_Z1fv+0x28> mtlr r0 > > 0000002c <_Z1fv+0x2c> blr > > Then g++5 (5.3): > > > # g++5 -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf32-powerpc-freebsd > > > > > > Disassembly of section .text: > > 00000000 <_Z1fv> stwu r1,-16(r1) > > 00000004 <_Z1fv+0x4> mflr r0 > > 00000008 <_Z1fv+0x8> stw r0,20(r1) > > 0000000c <_Z1fv+0xc> stw r31,12(r1) > > 00000010 <_Z1fv+0x10> mr r31,r1 > > 00000014 <_Z1fv+0x14> addi r9,r31,16 > > 00000018 <_Z1fv+0x18> mr r3,r9 > > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > > 00000020 <_Z1fv+0x20> nop > > 00000024 <_Z1fv+0x24> addi r11,r31,16 > > 00000028 <_Z1fv+0x28> lwz r0,4(r11) > > 0000002c <_Z1fv+0x2c> mtlr r0 > > 00000030 <_Z1fv+0x30> lwz r31,-4(r11) > > 00000034 <_Z1fv+0x34> mr r1,r11 > > 00000038 <_Z1fv+0x38> blr > > > The historical note below is from before I'd discovered powerpc64 or armv6 have the same sort of issue. But it gives an example use that is broken for powerpc and powerpc64. (I do not know if armv6 uses the same infrastructure.) > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Feb-27, at 3:31 PM, Mark Millard wrote: > > > > [Top post for dinging the low level problem that directly breaks c++ exception handling for TARGET_ARCH=powerpc for clang 3.8.0 generated code.] > > > > I've tracked down the c++ exception problem for TARGET_ARCH=powerpc via clang 3.8.0: misbehavior of clang 3.8.0 code generation for __builtin_dwarf_cfa () as used in: > > > > #define uw_init_context(CONTEXT) \ > > do \ > > { \ > > /* Do any necessary initialization to access arbitrary stack frames. \ > > On the SPARC, this means flushing the register windows. */ \ > > __builtin_unwind_init (); \ > > uw_init_context_1 (CONTEXT, __builtin_dwarf_cfa (), \ > > __builtin_return_address (0)); \ > > } \ > > while (0) > > . . . > > 85 _Unwind_Reason_Code > > 86 _Unwind_RaiseException(struct _Unwind_Exception *exc) > > 87 { > > 88 struct _Unwind_Context this_context, cur_context; > > 89 _Unwind_Reason_Code code; > > 90 > > 91 /* Set up this_context to describe the current stack frame. */ > > 92 uw_init_context (&this_context); > > > > In the below r4 ends up with the __builtin_dwarf_cfa () value supplied to uw_init_context_1: > > > > Dump of assembler code for function _Unwind_RaiseException: > > 0x419a8fd8 <+0>: mflr r0 > > 0x419a8fdc <+4>: stw r31,-148(r1) > > 0x419a8fe0 <+8>: stw r30,-152(r1) > > 0x419a8fe4 <+12>: stw r0,4(r1) > > 0x419a8fe8 <+16>: stwu r1,-2992(r1) > > 0x419a8fec <+20>: mr r31,r1 > > . . . > > 0x419a9094 <+188>: mr r4,r31 > > 0x419a9098 <+192>: mflr r30 > > 0x419a909c <+196>: lwz r5,2996(r31) > > 0x419a90a0 <+200>: mr r3,r28 > > 0x419a90a4 <+204>: bl 0x419a929c > > > > That r4 ends up holding the stack pointer value for after it has been decremented. r4 is not pointing at the boundary with the caller's frame. > > > > The .eh_frame information and unwind code is set up for pointing at the boundary with the caller's frame. So the cfa relative addressing is messed up for what it actually extracts. > > > > Contrast this with gcc/g++ 5.3's TARGET_ARCH=powerpc64 code where r4 is made to be at the boundary with the caller's frame: > > > > Dump of assembler code for function _Unwind_RaiseException: > > 0x00000000501cb810 <+0>: mflr r0 > > 0x00000000501cb814 <+4>: stdu r1,-5648(r1) > > . . . > > 0x00000000501cb8d0 <+192>: addi r4,r1,5648 > > 0x00000000501cb8d4 <+196>: stw r12,5656(r1) > > 0x00000000501cb8d8 <+200>: mr r28,r3 > > 0x00000000501cb8dc <+204>: addi r31,r1,2544 > > 0x00000000501cb8e0 <+208>: mr r3,r27 > > 0x00000000501cb8e4 <+212>: addi r29,r1,112 > > 0x00000000501cb8e8 <+216>: bl 0x501cae60 > > > > > > NOTE: The powerpc (32-bit) issue may in some way be associated with the clang 3.8.0 powerpc ABI violation in how it handles the stack pointer for FreeBSD: TARGET_ARCH=powerpc is currently using a "red zone", decrementing the stack pointer late, and incrementing the stack pointer early compared to the FreeBSD ABI rules. (This is similar to the official FreeBSD ABI for TARGET_ARCH=powerpc64.) > > > > > > > > > > === > > Mark Millard > > markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Feb 28 10:46:30 2016 Return-Path: Delivered-To: freebsd-ppc@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 1F8DFAB679D for ; Sun, 28 Feb 2016 10:46:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-155.reflexion.net [208.70.211.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D85E9129F for ; Sun, 28 Feb 2016 10:46:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29444 invoked from network); 28 Feb 2016 10:46:44 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 10:46:44 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 28 Feb 2016 05:46:20 -0500 (EST) Received: (qmail 26052 invoked from network); 28 Feb 2016 10:46:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 10:46:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D21271C43C6; Sun, 28 Feb 2016 02:46:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <20160228083934.GA60222@vlakno.cz> Date: Sun, 28 Feb 2016 02:46:26 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 10:46:30 -0000 On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Feb 28 22:10:08 2016 Return-Path: Delivered-To: freebsd-ppc@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 81E01AB6C2D for ; Sun, 28 Feb 2016 22:10:08 +0000 (UTC) (envelope-from tinkr@openmailbox.org) Received: from smtp2.openmailbox.org (smtp2.openmailbox.org [62.4.1.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4A8B317AB for ; Sun, 28 Feb 2016 22:10:08 +0000 (UTC) (envelope-from tinkr@openmailbox.org) Received: by mail2.openmailbox.org (Postfix, from userid 1004) id 61BB52AC68B2; Sun, 28 Feb 2016 18:23:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1456680182; bh=OvS/VSyjyGuwBd5fDgo93WEDlaAk2zhr9ENZHp1ivb0=; h=Date:From:To:Subject:From; b=01iJSOcx/OH1C89ODyRVXxjYdD+EWG3y+QC7QQgrb2MDU5FsMGy/GaWM719fE+Dam x1r2Mq2bgq0I7cUJ4cAQhkvVC2vm90vm9Ahd6N8BgH528+uYa2MlkZKI5quli/L9iT Ra1L+Bq6/bFsVVxjOJB/eBqwA5n9Fqpc/QPpfaBo= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on openmailbox-b2 X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=ALL_TRUSTED,BAYES_50, DKIM_ADSP_ALL autolearn=no autolearn_force=no version=3.4.0 Received: from www.openmailbox.org (openmailbox-b1 [10.91.69.218]) by mail2.openmailbox.org (Postfix) with ESMTP id 5EB402AC68FE for ; Sun, 28 Feb 2016 18:22:54 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 29 Feb 2016 00:22:54 +0700 From: Tinker To: freebsd-ppc@freebsd.org Subject: What is the status of POWER8 and POWER7 in FreeBSD now, are they ready for production =?UTF-8?Q?use=3F?= Message-ID: <2dd8c5f8f42f7574b3f513ed8608840c@openmailbox.org> X-Sender: tinkr@openmailbox.org User-Agent: Roundcube Webmail/1.0.6 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 22:10:08 -0000 Hi! What is the status of IBM POWER8 and POWER7 support in FreeBSD now, are they ready for production use? POWER8 would be Tyan BP012 http://www.tyan.com/solutions/tyan_openpower_system.html . POWER7 would be IBM "P730" Power7 730 Express. Thanks, Tinker From owner-freebsd-ppc@freebsd.org Sun Feb 28 22:20:36 2016 Return-Path: Delivered-To: freebsd-ppc@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 3C07AAB7281 for ; Sun, 28 Feb 2016 22:20:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0174D1100 for ; Sun, 28 Feb 2016 22:20:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 17665 invoked from network); 28 Feb 2016 22:20:35 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 22:20:35 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 28 Feb 2016 17:20:47 -0500 (EST) Received: (qmail 4711 invoked from network); 28 Feb 2016 22:20:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 22:20:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 779A1B1E001; Sun, 28 Feb 2016 14:20:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> Date: Sun, 28 Feb 2016 14:20:32 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 22:20:36 -0000 In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most = targets. > int32_t Offset =3D 0; > =20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, = Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > =20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); > =20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; > =20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; > =20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, = DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, = false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most = targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Feb 29 01:41:07 2016 Return-Path: Delivered-To: freebsd-ppc@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 82D84AAD5D4 for ; Mon, 29 Feb 2016 01:41:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-155.reflexion.net [208.70.211.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45E41196 for ; Mon, 29 Feb 2016 01:41:07 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 11299 invoked from network); 29 Feb 2016 01:41:16 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 01:41:16 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 28 Feb 2016 20:40:53 -0500 (EST) Received: (qmail 21805 invoked from network); 29 Feb 2016 01:40:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 01:40:52 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 05472B1E001; Sun, 28 Feb 2016 17:40:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> Date: Sun, 28 Feb 2016 17:40:58 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 01:41:07 -0000 Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most = targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, = Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, = DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, = false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most = targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Feb 29 04:49:42 2016 Return-Path: Delivered-To: freebsd-ppc@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 320A4AB8587 for ; Mon, 29 Feb 2016 04:49:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7916126B for ; Mon, 29 Feb 2016 04:49:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29507 invoked from network); 29 Feb 2016 04:49:40 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 04:49:40 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 28 Feb 2016 23:49:53 -0500 (EST) Received: (qmail 16577 invoked from network); 29 Feb 2016 04:49:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 04:49:53 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1E0D0B1E001; Sun, 28 Feb 2016 20:49:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> Date: Sun, 28 Feb 2016 20:49:38 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 04:49:42 -0000 Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, = false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Feb 29 06:14:00 2016 Return-Path: Delivered-To: freebsd-ppc@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 66863AB816A for ; Mon, 29 Feb 2016 06:14:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AFAA1E60 for ; Mon, 29 Feb 2016 06:14:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 1969 invoked from network); 29 Feb 2016 06:14:15 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 06:14:15 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 29 Feb 2016 01:13:51 -0500 (EST) Received: (qmail 31036 invoked from network); 29 Feb 2016 06:13:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 06:13:50 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E470DB1E001; Sun, 28 Feb 2016 22:13:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> Date: Sun, 28 Feb 2016 22:13:56 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 06:14:00 -0000 Back to the "case Builtin::BI__builtin_dwarf_cfa" and = "PPCTargetLowering::LowerFRAMEADDR" context: I made the wrong change and need to retry. The detail. . . Passing a 1 through instead of zero did not do what I expected to the = code generated. Instead it added one instruction: addi r3,r3,1 resulting in (objdump -d --prefix-addresses on the .o): > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> addi r3,r3,1 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> addi r1,r1,16 > 00000024 <_Z1fv+0x24> lwz r0,4(r1) > 00000028 <_Z1fv+0x28> lwz r31,-4(r1) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> blr In other words: it added the 1 as a byte offset like the comments that I = thought were wrong said. Since it does not appear that PPCTargetLowering::LowerFRAMEADDR would do = that with a 1 I conclude that PPCTargetLowering::LowerFRAMEADDR is not = involved with that figure. So looking around. . . /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp = has: > case Intrinsic::eh_dwarf_cfa: { > SDValue CfaArg =3D = DAG.getSExtOrTrunc(getValue(I.getArgOperand(0)), sdl, > = TLI.getPointerTy(DAG.getDataLayout())); > SDValue Offset =3D DAG.getNode(ISD::ADD, sdl, > CfaArg.getValueType(), > = DAG.getNode(ISD::FRAME_TO_ARGS_OFFSET, sdl, > CfaArg.getValueType()), > CfaArg); > SDValue FA =3D DAG.getNode( > ISD::FRAMEADDR, sdl, TLI.getPointerTy(DAG.getDataLayout()), > DAG.getConstant(0, sdl, = TLI.getPointerTy(DAG.getDataLayout()))); > setValue(&I, DAG.getNode(ISD::ADD, sdl, FA.getValueType(), > FA, Offset)); > return nullptr; And so sure enough the argument is an offset as used by this code. And what I call the frame depth is plugged in as 0 here via = "DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))". The = offset is applied after getting the frame address. So I get to revert my change and try again changing the above call to = use a 1 instead. It does not look like this changes the time frames in my history notes: = it has been using frame depth zero since V2.7 when "case = Builtin::BI__builtin_dwarf_cfa" appeared. In general my overall questions about the target triple controlling = which value to use (in DAG.getConstant hrere) still apply: It is not = obvious that something that has been using frame depth 0 since V2.7 can = be immediately changed to frame depth 1 for all contexts. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 8:49 PM, Mark Millard wrote: Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, = false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Feb 29 11:20:51 2016 Return-Path: Delivered-To: freebsd-ppc@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 E9EBCAB8269 for ; Mon, 29 Feb 2016 11:20:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA71CC28 for ; Mon, 29 Feb 2016 11:20:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 29822 invoked from network); 29 Feb 2016 11:20:51 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 11:20:51 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 29 Feb 2016 06:20:43 -0500 (EST) Received: (qmail 22058 invoked from network); 29 Feb 2016 11:20:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 11:20:43 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 51895B1E001; Mon, 29 Feb 2016 03:20:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> Date: Mon, 29 Feb 2016 03:20:48 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 11:20:52 -0000 TARGET_ARCH=3Dpowerpc: Using Frame Depth 1 in "case = Intrinsic::eh_dwarf_cfa" (and Offset 0 in "case = Builtin::BI__builtin_dwarf_cfa") for PPCTargetLowering::LowerFRAMEADDR = related use has allowed getting into _Unwind_RaiseException_Phase2 and = __cxxabiv1::__gxx_personality_v0. The example is the 8 line example = compiled under g++ 4.2.1 but then used under a buildworld that was built = with clang 3.8.0: # ldd exception_test.g++421.powerpc=20 exception_test.g++421.powerpc: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x41840000) libm.so.5 =3D> /lib/libm.so.5 (0x4196a000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x419a1000) libc.so.7 =3D> /lib/libc.so.7 (0x419c0000) _Unwind_RaiseException_Phase2 is well past the point of the failure and = crash from having Frame Depth 0 instead. It is getting a SEGV during the _Unwind_SetGR called via: 710 /* For targets with pointers smaller than the word size, we = must extend the 711 pointer, and this extension is target dependent. */ 712 _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), 713 __builtin_extend_pointer (ue_header)); for: _Unwind_SetGR (context=3D0xffffd570, index=3D3, val=3D1105272896) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 context->reg[3] is 0x0 and so its use in the following gets the SEGV. 217 ptr =3D context->reg[index]; 218=09 219 if (size =3D=3D sizeof(_Unwind_Ptr)) 220 * (_Unwind_Ptr *) ptr =3D val; I'm not going to try to analyze the source of this before getting some = sleep. For the 8 line program being compiled by clang++ 3.8.0 instead the = results are different than the above and than the original behavior: The = program does not crash abnormally but also does not find the catch = clause that it should. The std::terminate gets its normal SIGABRT = instead of an earlier SEGV. Again I'm not going to try to analyze the details before getting some = sleep. But I will mention that I've also already submitted a report that = libgcc_s does not completely implement DW_CFA_remember_state and = DW_CFA_restore_state and that the code generated on powerpc64 touches = the defect and so ends up with misbehavior. These might be similar. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 10:13 PM, Mark Millard = wrote: Back to the "case Builtin::BI__builtin_dwarf_cfa" and = "PPCTargetLowering::LowerFRAMEADDR" context: I made the wrong change and need to retry. The detail. . . Passing a 1 through instead of zero did not do what I expected to the = code generated. Instead it added one instruction: addi r3,r3,1 resulting in (objdump -d --prefix-addresses on the .o): > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> addi r3,r3,1 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> addi r1,r1,16 > 00000024 <_Z1fv+0x24> lwz r0,4(r1) > 00000028 <_Z1fv+0x28> lwz r31,-4(r1) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> blr In other words: it added the 1 as a byte offset like the comments that I = thought were wrong said. Since it does not appear that PPCTargetLowering::LowerFRAMEADDR would do = that with a 1 I conclude that PPCTargetLowering::LowerFRAMEADDR is not = involved with that figure. So looking around. . . /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp = has: > case Intrinsic::eh_dwarf_cfa: { > SDValue CfaArg =3D DAG.getSExtOrTrunc(getValue(I.getArgOperand(0)), = sdl, > = TLI.getPointerTy(DAG.getDataLayout())); > SDValue Offset =3D DAG.getNode(ISD::ADD, sdl, > CfaArg.getValueType(), > DAG.getNode(ISD::FRAME_TO_ARGS_OFFSET, = sdl, > CfaArg.getValueType()), > CfaArg); > SDValue FA =3D DAG.getNode( > ISD::FRAMEADDR, sdl, TLI.getPointerTy(DAG.getDataLayout()), > DAG.getConstant(0, sdl, = TLI.getPointerTy(DAG.getDataLayout()))); > setValue(&I, DAG.getNode(ISD::ADD, sdl, FA.getValueType(), > FA, Offset)); > return nullptr; And so sure enough the argument is an offset as used by this code. And what I call the frame depth is plugged in as 0 here via = "DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))". The = offset is applied after getting the frame address. So I get to revert my change and try again changing the above call to = use a 1 instead. It does not look like this changes the time frames in my history notes: = it has been using frame depth zero since V2.7 when "case = Builtin::BI__builtin_dwarf_cfa" appeared. In general my overall questions about the target triple controlling = which value to use (in DAG.getConstant hrere) still apply: It is not = obvious that something that has been using frame depth 0 since V2.7 can = be immediately changed to frame depth 1 for all contexts. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 8:49 PM, Mark Millard wrote: Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Mar 1 07:11:06 2016 Return-Path: Delivered-To: freebsd-ppc@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 229F1ABBE93 for ; Tue, 1 Mar 2016 07:11:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-155.reflexion.net [208.70.211.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA1E71ED8 for ; Tue, 1 Mar 2016 07:11:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14683 invoked from network); 1 Mar 2016 07:11:14 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Mar 2016 07:11:14 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 01 Mar 2016 02:10:50 -0500 (EST) Received: (qmail 32433 invoked from network); 1 Mar 2016 07:10:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Mar 2016 07:10:50 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 460761C43C4; Mon, 29 Feb 2016 23:10:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: Date: Mon, 29 Feb 2016 23:10:56 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 07:11:06 -0000 [TARGET_ARCH=3Dpowerpc context for all the evidence.] I found another clang++ 3.8.0 vs. g++ 4.2.1 difference where the system = libgcc_s depends on how it works for g++ 4.2.1 when clang 3.8.0 does not = work the same way: _Unwind_RaiseException is special in a way that makes it save and = restore lots of registers it does not directly use. (I'm not sure what = triggers having so many registers saved/restored.) But gcc/g++ 4.2.1 saves and restores more registers than clang/clang++ = 3.8.0 does. That in turn leaves .eh_frame information for more registers = for _Unwind_RaiseException for the gcc/g++ 4.2.1 context. _Unwind_RaiseException from a clang++ 3.8.0 build of libgcc_s does not = have save/restore for r3, r4, r5, r6, "r70" (from mfcr, dwarfdump = notation). The C++ exception handling library code in libgcc_s depends = on r3 (as one example). The pointer for r3 ends up being 0x0 and that = causes a crash in examples that get that far using the system's = libgcc_s. _Unwind_RaiseException from a g++ 4.2.1 build of libgcc_s has = save/restore for r3, r4, r5, r6, "r70" (from mfcr). Later below I list one form of the specific evidence for the = differences. It may be that this and the __builtin_dwarf_cfa() "fix" covers all the = problems for when libstdc++/libsupc++ are involved with the system = libgcc_s instead of libc++/libcxxrt being involved. In my view the registers to save/restore in routines like = _Unwind_RaiseException should be considered as part of the overall ABI = criteria. Under the rule "the TARGET_ARCH=3Dpowerpc ABI is always such = that it is gcc/g++ 4.2.1 compatible", I take it that clang 3.8.0 is = wrong for FreeBSD TARGET_ARCH=3Dpowerpc here: Another ABI violation. TARGET_ARCH=3Dpowerpc64 and possibly others could have the same sort of = issue. I've never gotten a clang/clang++ based TARGET_ARCH=3Dpowerpc64 = as far as a complete buildworld. And for now I'm more interested in = finding new types of errors for TARGET_ARCH=3Dpowerpc rather then what = range of TARGET_ARCH's get a specific clang 3.8.0 problem. Separately from the above I've shown that copying the following 3 files = to a gcc 4.2.1 buildworld/buildkernel TARGET_ARCH=3Dpowerpc context = allows exception_test.clang++380.powerpc to run just fine: > exception_test.clang++380.powerpc > /usr/lib/libc++.so.1 > /lib/libcxxrt.so.1 (debug files for the libraries also copied) That leaves the following libraries listed by ldd as being from the gcc = 4.2.1 buildworld: > /lib/libm.so.5 > /lib/libc.so.7 > /lib/libgcc_s.so.1 > # ldd exception_test.clang++380.powerpc > exception_test.clang++380.powerpc: > libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x4183e000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x41917000) > libm.so.5 =3D> /lib/libm.so.5 (0x41942000) > libc.so.7 =3D> /lib/libc.so.7 (0x41979000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x41b1d000) exception_test.clang++380.powerpc used with the clang 3.8.0 buildworld = and its libgcc_s shows different behavior not likely to be explained by = the _Unwind_RaiseException register save/restore differences. (The lack = of some saves/restores would still be a problem if I get = exception_test.clang++380.powerpc to get that far before doing something = odd.) I'm still trying to get evidence of the specific low-level problem for = exception_test.clang++380.powerpc. It may be some time before I figure = out anything useful. Using some dwarfdump -v -v -F output for the evidence of register = save/restore differences. . . _Unwind_RaiseException from a g++ 4.2.1 build of libgcc_s has r3, r4, = r5, r6, r70 (from mfcr). The library depends on r3 (as one example). > fde section offset 1104 0x00000450 cie offset for fde: 1108 = 0x00000454 > 0 DW_CFA_advance_loc 8 (8 * 1) > 1 DW_CFA_def_cfa_offset 3024 > 4 DW_CFA_advance_loc1 156 > 6 DW_CFA_offset r4 -232 (58 * -4) > 8 DW_CFA_offset r3 -236 (59 * -4) > 10 DW_CFA_offset r28 -160 (40 * -4) > 12 DW_CFA_offset r27 -164 (41 * -4) > 14 DW_CFA_offset r26 -168 (42 * -4) > 16 DW_CFA_offset r25 -172 (43 * -4) > 18 DW_CFA_offset r24 -176 (44 * -4) > 20 DW_CFA_offset r23 -180 (45 * -4) > 22 DW_CFA_offset r22 -184 (46 * -4) > 24 DW_CFA_offset r21 -188 (47 * -4) > 26 DW_CFA_offset r20 -192 (48 * -4) > 28 DW_CFA_offset r19 -196 (49 * -4) > 30 DW_CFA_offset r18 -200 (50 * -4) > 32 DW_CFA_offset r17 -204 (51 * -4) > 34 DW_CFA_offset r16 -208 (52 * -4) > 36 DW_CFA_offset r15 -212 (53 * -4) > 38 DW_CFA_offset r14 -216 (54 * -4) > 40 DW_CFA_offset r63 -8 (2 * -4) > 42 DW_CFA_offset r62 -16 (4 * -4) > 44 DW_CFA_offset r61 -24 (6 * -4) > 46 DW_CFA_offset r60 -32 (8 * -4) > 48 DW_CFA_offset r59 -40 (10 * -4) > 50 DW_CFA_offset r58 -48 (12 * -4) > 52 DW_CFA_offset r57 -56 (14 * -4) > 54 DW_CFA_offset r56 -64 (16 * -4) > 56 DW_CFA_offset r55 -72 (18 * -4) > 58 DW_CFA_offset r54 -80 (20 * -4) > 60 DW_CFA_offset r53 -88 (22 * -4) > 62 DW_CFA_offset r52 -96 (24 * -4) > 64 DW_CFA_offset r51 -104 (26 * -4) > 66 DW_CFA_offset r50 -112 (28 * -4) > 68 DW_CFA_offset r49 -120 (30 * -4) > 70 DW_CFA_offset r48 -128 (32 * -4) > 72 DW_CFA_offset r47 -136 (34 * -4) > 74 DW_CFA_offset r46 -144 (36 * -4) > 76 DW_CFA_register r70 =3D r12 > 79 DW_CFA_offset_extended_sf r65 4 (-1 * -4) > 82 DW_CFA_advance_loc 32 (32 * 1) > 83 DW_CFA_offset r5 -228 (57 * -4) > 85 DW_CFA_offset r31 -148 (37 * -4) > 87 DW_CFA_offset r30 -152 (38 * -4) > 89 DW_CFA_offset r29 -156 (39 * -4) > 91 DW_CFA_offset_extended r70 -220 (55 * -4) > 94 DW_CFA_offset r6 -224 (56 * -4) > 96 DW_CFA_nop > 97 DW_CFA_nop > 98 DW_CFA_nop _Unwind_RaiseException from clang++ 3.8.0 build of libgcc_s does not = have has r3, r4, r5, r6, r70 (from mfcr). The library depends on r3 (as = one example). > fde section offset 692 0x000002b4 cie offset for fde: 696 0x000002b8 > 0 DW_CFA_advance_loc 20 (5 * 4) > 1 DW_CFA_def_cfa_offset 2992 > 4 DW_CFA_offset r31 -148 (37 * -4) > 6 DW_CFA_offset r30 -152 (38 * -4) > 8 DW_CFA_offset_extended_sf r65 4 (-1 * -4) > 11 DW_CFA_advance_loc 4 (1 * 4) > 12 DW_CFA_def_cfa_register r31 > 14 DW_CFA_offset r14 -216 (54 * -4) > 16 DW_CFA_offset r15 -212 (53 * -4) > 18 DW_CFA_offset r16 -208 (52 * -4) > 20 DW_CFA_offset r17 -204 (51 * -4) > 22 DW_CFA_offset r18 -200 (50 * -4) > 24 DW_CFA_offset r19 -196 (49 * -4) > 26 DW_CFA_offset r20 -192 (48 * -4) > 28 DW_CFA_offset r21 -188 (47 * -4) > 30 DW_CFA_offset r22 -184 (46 * -4) > 32 DW_CFA_offset r23 -180 (45 * -4) > 34 DW_CFA_offset r24 -176 (44 * -4) > 36 DW_CFA_offset r25 -172 (43 * -4) > 38 DW_CFA_offset r26 -168 (42 * -4) > 40 DW_CFA_offset r27 -164 (41 * -4) > 42 DW_CFA_offset r28 -160 (40 * -4) > 44 DW_CFA_offset r29 -156 (39 * -4) > 46 DW_CFA_offset r30 -152 (38 * -4) > 48 DW_CFA_offset r31 -148 (37 * -4) > 50 DW_CFA_offset r46 -144 (36 * -4) > 52 DW_CFA_offset r47 -136 (34 * -4) > 54 DW_CFA_offset r48 -128 (32 * -4) > 56 DW_CFA_offset r49 -120 (30 * -4) > 58 DW_CFA_offset r50 -112 (28 * -4) > 60 DW_CFA_offset r51 -104 (26 * -4) > 62 DW_CFA_offset r52 -96 (24 * -4) > 64 DW_CFA_offset r53 -88 (22 * -4) > 66 DW_CFA_offset r54 -80 (20 * -4) > 68 DW_CFA_offset r55 -72 (18 * -4) > 70 DW_CFA_offset r56 -64 (16 * -4) > 72 DW_CFA_offset r57 -56 (14 * -4) > 74 DW_CFA_offset r58 -48 (12 * -4) > 76 DW_CFA_offset r59 -40 (10 * -4) > 78 DW_CFA_offset r60 -32 (8 * -4) > 80 DW_CFA_offset r61 -24 (6 * -4) > 82 DW_CFA_offset r62 -16 (4 * -4) > 84 DW_CFA_offset r63 -8 (2 * -4) > 86 DW_CFA_nop =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-29, at 3:20 AM, Mark Millard wrote: TARGET_ARCH=3Dpowerpc: Using Frame Depth 1 in "case = Intrinsic::eh_dwarf_cfa" (and Offset 0 in "case = Builtin::BI__builtin_dwarf_cfa") for PPCTargetLowering::LowerFRAMEADDR = related use has allowed getting into _Unwind_RaiseException_Phase2 and = __cxxabiv1::__gxx_personality_v0. The example is the 8 line example = compiled under g++ 4.2.1 but then used under a buildworld that was built = with clang 3.8.0: # ldd exception_test.g++421.powerpc=20 exception_test.g++421.powerpc: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x41840000) libm.so.5 =3D> /lib/libm.so.5 (0x4196a000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x419a1000) libc.so.7 =3D> /lib/libc.so.7 (0x419c0000) _Unwind_RaiseException_Phase2 is well past the point of the failure and = crash from having Frame Depth 0 instead. It is getting a SEGV during the _Unwind_SetGR called via: 710 /* For targets with pointers smaller than the word size, we = must extend the 711 pointer, and this extension is target dependent. */ 712 _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), 713 __builtin_extend_pointer (ue_header)); for: _Unwind_SetGR (context=3D0xffffd570, index=3D3, val=3D1105272896) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 context->reg[3] is 0x0 and so its use in the following gets the SEGV. 217 ptr =3D context->reg[index]; 218=09 219 if (size =3D=3D sizeof(_Unwind_Ptr)) 220 * (_Unwind_Ptr *) ptr =3D val; I'm not going to try to analyze the source of this before getting some = sleep. For the 8 line program being compiled by clang++ 3.8.0 instead the = results are different than the above and than the original behavior: The = program does not crash abnormally but also does not find the catch = clause that it should. The std::terminate gets its normal SIGABRT = instead of an earlier SEGV. Again I'm not going to try to analyze the details before getting some = sleep. But I will mention that I've also already submitted a report that = libgcc_s does not completely implement DW_CFA_remember_state and = DW_CFA_restore_state and that the code generated on powerpc64 touches = the defect and so ends up with misbehavior. These might be similar. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 10:13 PM, Mark Millard = wrote: Back to the "case Builtin::BI__builtin_dwarf_cfa" and = "PPCTargetLowering::LowerFRAMEADDR" context: I made the wrong change and need to retry. The detail. . . Passing a 1 through instead of zero did not do what I expected to the = code generated. Instead it added one instruction: addi r3,r3,1 resulting in (objdump -d --prefix-addresses on the .o): > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> addi r3,r3,1 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> addi r1,r1,16 > 00000024 <_Z1fv+0x24> lwz r0,4(r1) > 00000028 <_Z1fv+0x28> lwz r31,-4(r1) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> blr In other words: it added the 1 as a byte offset like the comments that I = thought were wrong said. Since it does not appear that PPCTargetLowering::LowerFRAMEADDR would do = that with a 1 I conclude that PPCTargetLowering::LowerFRAMEADDR is not = involved with that figure. So looking around. . . /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp = has: > case Intrinsic::eh_dwarf_cfa: { > SDValue CfaArg =3D DAG.getSExtOrTrunc(getValue(I.getArgOperand(0)), = sdl, > = TLI.getPointerTy(DAG.getDataLayout())); > SDValue Offset =3D DAG.getNode(ISD::ADD, sdl, > CfaArg.getValueType(), > DAG.getNode(ISD::FRAME_TO_ARGS_OFFSET, = sdl, > CfaArg.getValueType()), > CfaArg); > SDValue FA =3D DAG.getNode( > ISD::FRAMEADDR, sdl, TLI.getPointerTy(DAG.getDataLayout()), > DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))); > setValue(&I, DAG.getNode(ISD::ADD, sdl, FA.getValueType(), > FA, Offset)); > return nullptr; And so sure enough the argument is an offset as used by this code. And what I call the frame depth is plugged in as 0 here via = "DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))". The = offset is applied after getting the frame address. So I get to revert my change and try again changing the above call to = use a 1 instead. It does not look like this changes the time frames in my history notes: = it has been using frame depth zero since V2.7 when "case = Builtin::BI__builtin_dwarf_cfa" appeared. In general my overall questions about the target triple controlling = which value to use (in DAG.getConstant hrere) still apply: It is not = obvious that something that has been using frame depth 0 since V2.7 can = be immediately changed to frame depth 1 for all contexts. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 8:49 PM, Mark Millard wrote: Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Tue Mar 1 14:18:10 2016 Return-Path: Delivered-To: freebsd-ppc@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 23766ABFC5D for ; Tue, 1 Mar 2016 14:18:10 +0000 (UTC) (envelope-from luciano@vespaperitivo.it) Received: from baobab.bilink.net (baobab.bilink.net [212.45.144.44]) by mx1.freebsd.org (Postfix) with ESMTP id DDF29103A for ; Tue, 1 Mar 2016 14:18:09 +0000 (UTC) (envelope-from luciano@vespaperitivo.it) Received: from localhost (localhost [127.0.0.1]) by baobab.bilink.it (Postfix) with ESMTP id 3qF0t52fH6z1cXL3 for ; Tue, 1 Mar 2016 15:18:05 +0100 (CET) X-Virus-Scanned: amavisd-new at mcs.it Received: from baobab.bilink.net ([127.0.0.1]) by localhost (baobab.mcs.it [127.0.0.1]) (amavisd-new, port 11027) with ESMTP id Z2tT89d8niN0 for ; Tue, 1 Mar 2016 15:18:05 +0100 (CET) Received: from hermes.mcs.it (hermes.mcs.it [192.168.132.21]) by baobab.bilink.it (Postfix) with ESMTP id 3qF0t51zMJz1cXKx for ; Tue, 1 Mar 2016 15:18:05 +0100 (CET) Received: from mordeus (unknown [192.168.45.6]) by hermes.mcs.it (Postfix) with ESMTP id 1116C99B37 for ; Tue, 1 Mar 2016 15:18:02 +0100 (CET) Date: Tue, 1 Mar 2016 15:18:01 +0100 From: Luciano Mannucci To: FreeBSD PowerPC ML Subject: PPC boot0 X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) X-Face: 4qPv4GNcD; h<7Q/sK>+GqF4=CR@KmnPkSmwd+#%\F`4yjKO3"C]p'z=(oWRnsYBQGM\5g:4skqQY0NnV'dM:Mm:^/_+I@a"; [-s=ogufdF"9ggQ'=y MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <3qF0t51zMJz1cXKx@baobab.bilink.it> X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:18:10 -0000 I'm still unable to install 11.0 CURRENT under IBM KVM. It does install but it doesnt boot. I'm trying to install /boot0 manually but I can't find it on the ISO DVD. Maybe I can extract it via dd from the iso file, if only I knew the precise size and offset. Where may I find this info? Thanks to everyone, Luciano. -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL / E-MAIL: posthamster@sublink.sublink.ORG / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ From owner-freebsd-ppc@freebsd.org Tue Mar 1 14:29:58 2016 Return-Path: Delivered-To: freebsd-ppc@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 AADAFABD04C for ; Tue, 1 Mar 2016 14:29:58 +0000 (UTC) (envelope-from mma@semihalf.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6A9151725 for ; Tue, 1 Mar 2016 14:29:58 +0000 (UTC) (envelope-from mma@semihalf.com) Received: by mail-ig0-x236.google.com with SMTP id y8so21216167igp.0 for ; Tue, 01 Mar 2016 06:29:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=cbcuSsw4UagCb94PwVtYkWrGmECTWQpWuzxswFmB58w=; b=GBIrLdc5FxqpRmNXDKlh20R96bFuOzR5h1Z0j2BhRweSbgBS8Zl3cHAkzluBFDbsam eyHVU/6opCKqzEBjagV6kqBBt1bLXO2RGNaVAFzD9Edr+9j6lCCF4nCDtFbG/5sjULLu ri2bAF/hvHiJxMgj1GBcoRZqd44JslkdBXatIt/YYbNx8I6Q+ZlNIZiXsCb6NlZW5DVd vs2pYh5tA5645zPuabhCZnt2MJkaKbG2rk6L0ClLxf1BdDqilxuTa6FZODND/QyQiaY5 ekPAS7V5iwxNtETengbyB3tvywimGmt9eWJdpjxi3Rtf7oLPgT26g+w+j/AE1WTh7DT7 rcSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=cbcuSsw4UagCb94PwVtYkWrGmECTWQpWuzxswFmB58w=; b=XaLkbfgKchCwsDhf73n1SaUMfXa0CT9aN8qdHB64AtxQJChvn6CU9+LWb2fJL5J2xk gCmCXcYqMf7UpOe9dxbp/KETDZBPM+tA97VG2pjp2o5bSJKqHZakd8jgU56hGrzA+eF6 bCPHWspcsGrxNk8DxXKiXN+kxgn+CMt3LhLU8uKvgulnYwy2ZXTj9CitMKhxmkl1hSMa IskNuIp4kC7XOm283wr16TNTX7BLUQuLzwm7I5Qpwier/MgsCFu6bbDPDSoVtnKO6QyB waBxbZ7n0H7OIF9oMO1cNJAlQBolkAG4QLA7/A4qwYCdHKC2qjv8yROdaa7v6OQCv7Kv GKug== X-Gm-Message-State: AD7BkJK+LnZ1p0SenyO5DFiSL6/kmnjhSFlmsdUPZvaA/IzhZWMK98BYMBqLwt44Nlw02TRSVi6L6s6ggXUgYA== MIME-Version: 1.0 X-Received: by 10.50.20.98 with SMTP id m2mr4014181ige.9.1456842597666; Tue, 01 Mar 2016 06:29:57 -0800 (PST) Received: by 10.107.4.8 with HTTP; Tue, 1 Mar 2016 06:29:57 -0800 (PST) Date: Tue, 1 Mar 2016 15:29:57 +0100 Message-ID: Subject: Testing an importing OF PCI implementations patch From: Marcin Mazurek To: freebsd-ppc@freebsd.org, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Content-Type: multipart/mixed; boundary=047d7bd76bea87df0b052cfd99e4 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:29:58 -0000 --047d7bd76bea87df0b052cfd99e4 Content-Type: text/plain; charset=UTF-8 Hello, I am looking for a testers for a patch to import portions of the PowerPC and Sparc64 OF PCI implementations. This extracts common code from PPC's and Sparc64's ofw_pci and moves that to general dev/ofw_pci files. It is currently building successfully on every architecture. I tested it on my arm machine and checked it worked. Unfortunately I do not have any powerpc and sparc hardware to test it on. I tried to use it inside qemu, however I could not run the FBSD on Sparc64 and PPC (I used a "qemu recipes" from the freebsd wiki page). I would like it if this could be tested on these platforms using this code to check if it does not break them. This is very essential patch for me, because it is blocking my other pending commits and I would be very grateful for testing it. Review of this code is here: https://reviews.freebsd.org/D4879 Any comments and feedback are welcome. Thanks, Marcin --047d7bd76bea87df0b052cfd99e4 Content-Type: text/plain; charset=US-ASCII; name="ofw_extract_code.diff" Content-Disposition: attachment; filename="ofw_extract_code.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_il9i6ngp0 ZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLmFybSBiL3N5cy9jb25mL2ZpbGVzLmFybQppbmRl eCAyNDA3NjE2Li4wNzcwMjYxIDEwMDY0NAotLS0gYS9zeXMvY29uZi9maWxlcy5hcm0KKysrIGIv c3lzL2NvbmYvZmlsZXMuYXJtCkBAIC0xMDMsNiArMTAzLDcgQEAgZGV2L2h3cG1jL2h3cG1jX2Fy bS5jCQlvcHRpb25hbAlod3BtYwogZGV2L2h3cG1jL2h3cG1jX2FybXY3LmMJCW9wdGlvbmFsCWh3 cG1jIGFybXY2CiBkZXYvaWljYnVzL3R3c2kvdHdzaS5jCQlvcHRpb25hbAl0d3NpCiBkZXYvb2Z3 L29md19jcHUuYwkJb3B0aW9uYWwJZmR0CitkZXYvb2Z3L29md19wY2kuYwkJb3B0aW9uYWwgCXBj aSBmZHQKIGRldi9wc2NpL3BzY2kuYwkJCW9wdGlvbmFsCXBzY2kKIGRldi9wc2NpL3BzY2lfYXJt LlMJCW9wdGlvbmFsCXBzY2kKIGRldi9zeXNjb25zL3NjZ2Zicm5kci5jCQlvcHRpb25hbAlzYwpk aWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmlsZXMuYXJtNjQgYi9zeXMvY29uZi9maWxlcy5hcm02NApp bmRleCA4ZjVmMTBhLi5hMzJmNjA5IDEwMDY0NAotLS0gYS9zeXMvY29uZi9maWxlcy5hcm02NAor KysgYi9zeXMvY29uZi9maWxlcy5hcm02NApAQCAtNjYsNiArNjYsNyBAQCBkZXYvaHdwbWMvaHdw bWNfYXJtNjRfbWQuYwlvcHRpb25hbAlod3BtYwogZGV2L21tYy9ob3N0L2R3bW1jLmMJCW9wdGlv bmFsCWR3bW1jCiBkZXYvbW1jL2hvc3QvZHdtbWNfaGlzaS5jCW9wdGlvbmFsCWR3bW1jIHNvY19o aXNpX2hpNjIyMAogZGV2L29mdy9vZndfY3B1LmMJCW9wdGlvbmFsCWZkdAorZGV2L29mdy9vZndf cGNpLmMJCW9wdGlvbmFsCXBjaSBmZHQKIGRldi9wY2kvcGNpX2hvc3RfZ2VuZXJpYy5jCW9wdGlv bmFsCXBjaSBmZHQKIGRldi9wc2NpL3BzY2kuYwkJCW9wdGlvbmFsCXBzY2kKIGRldi9wc2NpL3Bz Y2lfYXJtNjQuUwkJb3B0aW9uYWwJcHNjaQpkaWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmlsZXMuaTM4 NiBiL3N5cy9jb25mL2ZpbGVzLmkzODYKaW5kZXggYjA2NTE2NS4uNTdiYmY1NyAxMDA2NDQKLS0t IGEvc3lzL2NvbmYvZmlsZXMuaTM4NgorKysgYi9zeXMvY29uZi9maWxlcy5pMzg2CkBAIC0yODUs NiArMjg1LDcgQEAgZGV2L252bWUvbnZtZV9zeXNjdGwuYwkJb3B0aW9uYWwgbnZtZQogZGV2L252 bWUvbnZtZV90ZXN0LmMJCW9wdGlvbmFsIG52bWUKIGRldi9udm1lL252bWVfdXRpbC5jCQlvcHRp b25hbCBudm1lCiBkZXYvbnZyYW0vbnZyYW0uYwkJb3B0aW9uYWwgbnZyYW0gaXNhCitkZXYvb2Z3 L29md19wY2kuYwkJb3B0aW9uYWwgcGNpIGZkdAogZGV2L3BjZi9wY2ZfaXNhLmMJCW9wdGlvbmFs IHBjZgogZGV2L3JhbmRvbS9pdnkuYwkJb3B0aW9uYWwgcmRyYW5kX3JuZwogZGV2L3JhbmRvbS9u ZWhlbWlhaC5jCQlvcHRpb25hbCBwYWRsb2NrX3JuZwpkaWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmls ZXMubWlwcyBiL3N5cy9jb25mL2ZpbGVzLm1pcHMKaW5kZXggOTFkNTNhYS4uNjczMzA4MCAxMDA2 NDQKLS0tIGEvc3lzL2NvbmYvZmlsZXMubWlwcworKysgYi9zeXMvY29uZi9maWxlcy5taXBzCkBA IC05MiwzICs5Miw2IEBAIGRldi9udnJhbTJlbnYvbnZyYW0yZW52LmMJCW9wdGlvbmFsCW52cmFt MmVudgogZGV2L2h3cG1jL2h3cG1jX21pcHMuYwkJCW9wdGlvbmFsCWh3cG1jCiBkZXYvaHdwbWMv aHdwbWNfbWlwczI0ay5jCQlvcHRpb25hbAlod3BtY19taXBzMjRrCiBkZXYvaHdwbWMvaHdwbWNf bWlwczc0ay5jCQlvcHRpb25hbAlod3BtY19taXBzNzRrCisKKyMgb2Z3IHN1cHBvcnQKK2Rldi9v Zncvb2Z3X3BjaS5jCQkJb3B0aW9uYWwgCXBjaSBmZHQKZGlmZiAtLWdpdCBhL3N5cy9jb25mL2Zp bGVzLnBvd2VycGMgYi9zeXMvY29uZi9maWxlcy5wb3dlcnBjCmluZGV4IDBhMWU3YzEuLmJkZTQ4 YTMgMTAwNjQ0Ci0tLSBhL3N5cy9jb25mL2ZpbGVzLnBvd2VycGMKKysrIGIvc3lzL2NvbmYvZmls ZXMucG93ZXJwYwpAQCAtNTcsNiArNTcsNyBAQCBkZXYvb2Z3L29md19jb25zb2xlLmMJCW9wdGlv bmFsCWFpbQogZGV2L29mdy9vZndfZGlzay5jCQlvcHRpb25hbAlvZndkIGFpbQogZGV2L29mdy9v ZndfaWljYnVzLmMJCW9wdGlvbmFsCWlpY2J1cyBhaW0KIGRldi9vZncvb2Z3YnVzLmMJCW9wdGlv bmFsCWFpbSB8IGZkdAorZGV2L29mdy9vZndfcGNpLmMJCW9wdGlvbmFsIAlwY2kgZmR0CiBkZXYv b2Z3L29md19zdGFuZGFyZC5jCQlvcHRpb25hbAlhaW0gcG93ZXJwYwogZGV2L29mdy9vZndfc3Vi ci5jCQlvcHRpb25hbAlhaW0gcG93ZXJwYwogZGV2L3Bvd2VybWFjX252cmFtL3Bvd2VybWFjX252 cmFtLmMgb3B0aW9uYWwJcG93ZXJtYWNfbnZyYW0gcG93ZXJtYWMKQEAgLTE0NSw3ICsxNDYsNiBA QCBwb3dlcnBjL21wYzg1eHgvcGNpX21wYzg1eHguYwlvcHRpb25hbAlwY2kgbXBjODV4eCB8IHBj aSBxb3JpcV9kcGFhCiBwb3dlcnBjL21wYzg1eHgvcGNpX21wYzg1eHhfcGNpYi5jCW9wdGlvbmFs CXBjaSBtcGM4NXh4IHwgcGNpIHFvcmlxX2RwYWEKIHBvd2VycGMvbXBjODV4eC9xb3JpcV9ncGlv LmMJb3B0aW9uYWwJbXBjODV4eCBncGlvIHwgcW9yaXFfZHBhYSBncGlvCiBwb3dlcnBjL29mdy9v ZndfbWFjaGRlcC5jCXN0YW5kYXJkCi1wb3dlcnBjL29mdy9vZndfcGNpLmMJCW9wdGlvbmFsCXBj aQogcG93ZXJwYy9vZncvb2Z3X3BjaWJ1cy5jCW9wdGlvbmFsCXBjaQogcG93ZXJwYy9vZncvb2Z3 X3BjaWJfcGNpLmMJb3B0aW9uYWwJcGNpCiBwb3dlcnBjL29mdy9vZndfcmVhbC5jCQlvcHRpb25h bAlhaW0KZGlmZiAtLWdpdCBhL3N5cy9jb25mL2ZpbGVzLnNwYXJjNjQgYi9zeXMvY29uZi9maWxl cy5zcGFyYzY0CmluZGV4IDg0ZjIzZmYuLmM3YzEzOGEgMTAwNjQ0Ci0tLSBhL3N5cy9jb25mL2Zp bGVzLnNwYXJjNjQKKysrIGIvc3lzL2NvbmYvZmlsZXMuc3BhcmM2NApAQCAtNDcsNiArNDcsNyBA QCBkZXYvb2Z3L29md19idXNfaWYubQkJc3RhbmRhcmQKIGRldi9vZncvb2Z3X2J1c19zdWJyLmMJ CXN0YW5kYXJkCiBkZXYvb2Z3L29md19jb25zb2xlLmMJCW9wdGlvbmFsCW9md19jb25zb2xlCiBk ZXYvb2Z3L29md19pZi5tCQlzdGFuZGFyZAorZGV2L29mdy9vZndfcGNpLmMJCW9wdGlvbmFsCXBj aQogZGV2L29mdy9vZndfc3RhbmRhcmQuYwkJc3RhbmRhcmQKIGRldi9vZncvb3BlbmZpcm0uYwkJ c3RhbmRhcmQKIGRldi9vZncvb3BlbmZpcm1pby5jCQlzdGFuZGFyZApAQCAtODIsNyArODMsNyBA QCBzcGFyYzY0L2lzYS9pc2FfZG1hLmMJCW9wdGlvbmFsCWlzYQogc3BhcmM2NC9pc2Evb2Z3X2lz YS5jCQlvcHRpb25hbAllYnVzIHwgaXNhCiBzcGFyYzY0L3BjaS9hcGIuYwkJb3B0aW9uYWwJcGNp CiBzcGFyYzY0L3BjaS9maXJlLmMJCW9wdGlvbmFsCXBjaQotc3BhcmM2NC9wY2kvb2Z3X3BjaS5j CQlvcHRpb25hbAlwY2kKK3NwYXJjNjQvcGNpL3NwYXJjNjRfb2Z3X3BjaS5jCW9wdGlvbmFsCXBj aQogc3BhcmM2NC9wY2kvb2Z3X3BjaWIuYwkJb3B0aW9uYWwJcGNpCiBzcGFyYzY0L3BjaS9vZndf cGNpYl9zdWJyLmMJb3B0aW9uYWwJcGNpCiBzcGFyYzY0L3BjaS9vZndfcGNpYnVzLmMJb3B0aW9u YWwJcGNpCmRpZmYgLS1naXQgYS9zeXMvZGV2L29mdy9vZndfcGNpLmMgYi9zeXMvZGV2L29mdy9v ZndfcGNpLmMKbmV3IGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMDAwMDAwMC4uODg1MmNkNwotLS0g L2Rldi9udWxsCisrKyBiL3N5cy9kZXYvb2Z3L29md19wY2kuYwpAQCAtMCwwICsxLDYzNSBAQAor LyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTEgTmF0aGFuIFdoaXRlaG9ybgorICogQWxsIHJpZ2h0 cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQg YmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoK KyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJv dmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5 IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0 aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRo ZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdp dGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZ IFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVT UyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBU SEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5U IFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBE SVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNF UVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9D VVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0Us IERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIg Q0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFD VCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9S IE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElT IFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNI IERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVC U0QkIik7CisjaW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+Cisj aW5jbHVkZSA8c3lzL21vZHVsZS5oPgorI2luY2x1ZGUgPHN5cy9idXMuaD4KKyNpbmNsdWRlIDxz eXMvY29uZi5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxzeXMvcm1hbi5o PgorCisjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3 X2J1cy5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2 L29mdy9vZndfcGNpLmg+CisKKyNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5oPgorI2luY2x1ZGUg PGRldi9wY2kvcGNpcmVnLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgorI2luY2x1ZGUg PG1hY2hpbmUvbWRfdmFyLmg+CisjaW5jbHVkZSA8bWFjaGluZS9yZXNvdXJjZS5oPgorCisjaW5j bHVkZSA8dm0vdm0uaD4KKyNpbmNsdWRlIDx2bS9wbWFwLmg+CisKKyNpbmNsdWRlICJwY2liX2lm LmgiCisKKy8qCisgKiBJZiBpdCBpcyBuZWNlc3NhcnkgdG8gc2V0IGFub3RoZXIgdmFsdWUgb2Yg dGhpcyBmb3IKKyAqIHNvbWUgcGxhdGZvcm1zIGl0IHNob3VsZCBiZSBzZXQgYXQgZmR0LmggZmls ZQorICovCisjaWZuZGVmIFBDSV9NQVBfSU5UUgorI2RlZmluZQlQQ0lfTUFQX0lOVFIJNAorI2Vu ZGlmCisKKyNkZWZpbmUJUENJX0lOVFJfUElOUwk0CisKKy8qCisgKiBidXMgaW50ZXJmYWNlLgor ICovCitzdGF0aWMgaW50IG9md19wY2lfYWN0aXZhdGVfcmVzb3VyY2UoZGV2aWNlX3QsIGRldmlj ZV90LCBpbnQsIGludCwKKyAgICBzdHJ1Y3QgcmVzb3VyY2UgKik7CitzdGF0aWMgaW50IG9md19w Y2lfcmVsZWFzZV9yZXNvdXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwgaW50LAorICAgIHN0 cnVjdCByZXNvdXJjZSAqKTsKK3N0YXRpYyBpbnQgb2Z3X3BjaV9kZWFjdGl2YXRlX3Jlc291cmNl KGRldmljZV90LCBkZXZpY2VfdCwgaW50LCBpbnQsCisgICAgc3RydWN0IHJlc291cmNlICopOwor CisjaWZkZWYgX19wb3dlcnBjX18KK3N0YXRpYyBidXNfc3BhY2VfdGFnX3Qgb2Z3X3BjaV9idXNf Z2V0X2J1c190YWcoZGV2aWNlX3QsIGRldmljZV90KTsKKyNlbmRpZgorCisvKgorICogcGNpYiBp bnRlcmZhY2UKKyAqLworc3RhdGljIGludCBvZndfcGNpX21heHNsb3RzKGRldmljZV90KTsKKwor LyoKKyAqIERyaXZlciBtZXRob2RzLgorICovCitzdGF0aWMgZGV2aWNlX21ldGhvZF90CW9md19w Y2lfbWV0aG9kc1tdID0geworCisJLyogRGV2aWNlIGludGVyZmFjZSAqLworCURFVk1FVEhPRChk ZXZpY2VfYXR0YWNoLAlvZndfcGNpX2F0dGFjaCksCisKKwkvKiBCdXMgaW50ZXJmYWNlICovCisJ REVWTUVUSE9EKGJ1c19wcmludF9jaGlsZCwJYnVzX2dlbmVyaWNfcHJpbnRfY2hpbGQpLAorCURF Vk1FVEhPRChidXNfcmVhZF9pdmFyLAlvZndfcGNpX3JlYWRfaXZhciksCisJREVWTUVUSE9EKGJ1 c193cml0ZV9pdmFyLAlvZndfcGNpX3dyaXRlX2l2YXIpLAorCURFVk1FVEhPRChidXNfc2V0dXBf aW50ciwJYnVzX2dlbmVyaWNfc2V0dXBfaW50ciksCisJREVWTUVUSE9EKGJ1c190ZWFyZG93bl9p bnRyLAlidXNfZ2VuZXJpY190ZWFyZG93bl9pbnRyKSwKKwlERVZNRVRIT0QoYnVzX2FsbG9jX3Jl c291cmNlLAlvZndfcGNpX2FsbG9jX3Jlc291cmNlKSwKKwlERVZNRVRIT0QoYnVzX3JlbGVhc2Vf cmVzb3VyY2UsCW9md19wY2lfcmVsZWFzZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19hY3Rp dmF0ZV9yZXNvdXJjZSwJb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1 c19kZWFjdGl2YXRlX3Jlc291cmNlLAlvZndfcGNpX2RlYWN0aXZhdGVfcmVzb3VyY2UpLAorCURF Vk1FVEhPRChidXNfYWRqdXN0X3Jlc291cmNlLAlvZndfcGNpX2FkanVzdF9yZXNvdXJjZSksCisj aWZkZWYgX19wb3dlcnBjX18KKwlERVZNRVRIT0QoYnVzX2dldF9idXNfdGFnLAlvZndfcGNpX2J1 c19nZXRfYnVzX3RhZyksCisjZW5kaWYKKworCS8qIHBjaWIgaW50ZXJmYWNlICovCisJREVWTUVU SE9EKHBjaWJfbWF4c2xvdHMsCW9md19wY2lfbWF4c2xvdHMpLAorCURFVk1FVEhPRChwY2liX3Jv dXRlX2ludGVycnVwdCwJb2Z3X3BjaV9yb3V0ZV9pbnRlcnJ1cHQpLAorCisJLyogb2Z3X2J1cyBp bnRlcmZhY2UgKi8KKwlERVZNRVRIT0Qob2Z3X2J1c19nZXRfbm9kZSwJb2Z3X3BjaV9nZXRfbm9k ZSksCisKKwlERVZNRVRIT0RfRU5ECit9OworCitERUZJTkVfQ0xBU1NfMChvZndfcGNpLCBvZndf cGNpX2RyaXZlciwgb2Z3X3BjaV9tZXRob2RzLCBzaXplb2Yoc3RydWN0IG9md19wY2lfc29mdGMp KTsKKworaW50CitvZndfcGNpX2luaXQoZGV2aWNlX3QgZGV2KQoreworCXN0cnVjdCBvZndfcGNp X3NvZnRjICpzYzsKKwlwaGFuZGxlX3Qgbm9kZTsKKwl1X2ludDMyX3QgYnVzcmFuZ2VbMl07CisJ c3RydWN0IG9md19wY2lfcmFuZ2UgKnJwOworCWludCBlcnJvcjsKKwlzdHJ1Y3Qgb2Z3X3BjaV9j ZWxsX2luZm8gKmNlbGxfaW5mbzsKKworCW5vZGUgPSBvZndfYnVzX2dldF9ub2RlKGRldik7CisJ c2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7CisJc2MtPnNjX2luaXRpYWxpemVkID0gMTsKKwlz Yy0+c2NfcmFuZ2UgPSBOVUxMOworCisJY2VsbF9pbmZvID0gKHN0cnVjdCBvZndfcGNpX2NlbGxf aW5mbyAqKW1hbGxvYyhzaXplb2YoKmNlbGxfaW5mbyksCisJICAgIE1fREVWQlVGLCBNX1dBSVRP SyB8IE1fWkVSTyk7CisKKwlzYy0+c2NfY2VsbF9pbmZvID0gY2VsbF9pbmZvOworCisJaWYgKE9G X2dldGVuY3Byb3Aobm9kZSwgImJ1cy1yYW5nZSIsIGJ1c3JhbmdlLCBzaXplb2YoYnVzcmFuZ2Up KSAhPSA4KQorCQlidXNyYW5nZVswXSA9IDA7CisKKwlzYy0+c2NfZGV2ID0gZGV2OworCXNjLT5z Y19ub2RlID0gbm9kZTsKKwlzYy0+c2NfYnVzID0gYnVzcmFuZ2VbMF07CisKKwlpZiAoc2MtPnNj X3F1aXJrcyAmIE9GV19QQ0lfUVVJUktfUkFOR0VTX09OX0NISUxEUkVOKSB7CisJCXBoYW5kbGVf dCBjOworCQlpbnQgbiwgaTsKKworCQlzYy0+c2NfbnJhbmdlID0gMDsKKwkJZm9yIChjID0gT0Zf Y2hpbGQobm9kZSk7IGMgIT0gMDsgYyA9IE9GX3BlZXIoYykpIHsKKwkJCW4gPSBvZndfcGNpX25y YW5nZXMoYywgY2VsbF9pbmZvKTsKKwkJCWlmIChuID4gMCkKKwkJCQlzYy0+c2NfbnJhbmdlICs9 IG47CisJCX0KKwkJaWYgKHNjLT5zY19ucmFuZ2UgPT0gMCkgeworCQkJZXJyb3IgPSBFTlhJTzsK KwkJCWdvdG8gb3V0OworCQl9CisJCXNjLT5zY19yYW5nZSA9IG1hbGxvYyhzYy0+c2NfbnJhbmdl ICogc2l6ZW9mKHNjLT5zY19yYW5nZVswXSksCisJCSAgICBNX0RFVkJVRiwgTV9XQUlUT0spOwor CQlpID0gMDsKKwkJZm9yIChjID0gT0ZfY2hpbGQobm9kZSk7IGMgIT0gMDsgYyA9IE9GX3BlZXIo YykpIHsKKwkJCW4gPSBvZndfcGNpX2ZpbGxfcmFuZ2VzKGMsICZzYy0+c2NfcmFuZ2VbaV0pOwor CQkJaWYgKG4gPiAwKQorCQkJCWkgKz0gbjsKKwkJfQorCQlLQVNTRVJUKGkgPT0gc2MtPnNjX25y YW5nZSwgKCJyYW5nZSBjb3VudCBtaXNtYXRjaCIpKTsKKwl9IGVsc2UgeworCQlzYy0+c2NfbnJh bmdlID0gb2Z3X3BjaV9ucmFuZ2VzKG5vZGUsIGNlbGxfaW5mbyk7CisJCWlmIChzYy0+c2NfbnJh bmdlIDw9IDApIHsKKwkJCWRldmljZV9wcmludGYoZGV2LCAiY291bGQgbm90IGdldHJhbmdlc1xu Iik7CisJCQllcnJvciA9IEVOWElPOworCQkJZ290byBvdXQ7CisJCX0KKwkJc2MtPnNjX3Jhbmdl ID0gbWFsbG9jKHNjLT5zY19ucmFuZ2UgKiBzaXplb2Yoc2MtPnNjX3JhbmdlWzBdKSwKKwkJICAg IE1fREVWQlVGLCBNX1dBSVRPSyk7CisJCW9md19wY2lfZmlsbF9yYW5nZXMobm9kZSwgc2MtPnNj X3JhbmdlKTsKKwl9CisKKwlzYy0+c2NfaW9fcm1hbi5ybV90eXBlID0gUk1BTl9BUlJBWTsKKwlz Yy0+c2NfaW9fcm1hbi5ybV9kZXNjciA9ICJQQ0kgSS9PIFBvcnRzIjsKKwllcnJvciA9IHJtYW5f aW5pdCgmc2MtPnNjX2lvX3JtYW4pOworCWlmIChlcnJvcikgeworCQlkZXZpY2VfcHJpbnRmKGRl diwgInJtYW5faW5pdCgpIGZhaWxlZC4gZXJyb3IgPSAlZFxuIiwgZXJyb3IpOworCQlnb3RvIG91 dDsKKwl9CisKKwlzYy0+c2NfbWVtX3JtYW4ucm1fdHlwZSA9IFJNQU5fQVJSQVk7CisJc2MtPnNj X21lbV9ybWFuLnJtX2Rlc2NyID0gIlBDSSBNZW1vcnkiOworCWVycm9yID0gcm1hbl9pbml0KCZz Yy0+c2NfbWVtX3JtYW4pOworCWlmIChlcnJvcikgeworCQlkZXZpY2VfcHJpbnRmKGRldiwgInJt YW5faW5pdCgpIGZhaWxlZC4gZXJyb3IgPSAlZFxuIiwgZXJyb3IpOworCQlnb3RvIG91dDsKKwl9 CisKKwlmb3IgKHJwID0gc2MtPnNjX3JhbmdlOyBycCA8IHNjLT5zY19yYW5nZSArIHNjLT5zY19u cmFuZ2UgJiYKKwkgICAgcnAtPnBjaV9oaSAhPSAwOyBycCsrKSB7CisJCWVycm9yID0gMDsKKwor CQlzd2l0Y2ggKHJwLT5wY2lfaGkgJiBPRldfUENJX1BIWVNfSElfU1BBQ0VNQVNLKSB7CisJCWNh c2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNFX0NPTkZJRzoKKwkJCWJyZWFrOworCQljYXNlIE9GV19Q Q0lfUEhZU19ISV9TUEFDRV9JTzoKKwkJCWVycm9yID0gcm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+ c2NfaW9fcm1hbiwgcnAtPnBjaSwKKwkJCSAgICBycC0+cGNpICsgcnAtPnNpemUgLSAxKTsKKwkJ CWJyZWFrOworCQljYXNlIE9GV19QQ0lfUEhZU19ISV9TUEFDRV9NRU0zMjoKKwkJY2FzZSBPRldf UENJX1BIWVNfSElfU1BBQ0VfTUVNNjQ6CisJCQllcnJvciA9IHJtYW5fbWFuYWdlX3JlZ2lvbigm c2MtPnNjX21lbV9ybWFuLCBycC0+cGNpLAorCQkJICAgIHJwLT5wY2kgKyBycC0+c2l6ZSAtIDEp OworCQkJYnJlYWs7CisJCX0KKworCQlpZiAoZXJyb3IpIHsKKwkJCWRldmljZV9wcmludGYoZGV2 LAorCQkJICAgICJybWFuX21hbmFnZV9yZWdpb24oJXgsICUjangsICUjangpIGZhaWxlZC4gIgor CQkJICAgICJlcnJvciA9ICVkXG4iLCBycC0+cGNpX2hpICYKKwkJCSAgICBPRldfUENJX1BIWVNf SElfU1BBQ0VNQVNLLCBycC0+cGNpLAorCQkJICAgIHJwLT5wY2kgKyBycC0+c2l6ZSAtIDEsIGVy cm9yKTsKKwkJCWdvdG8gb3V0OworCQl9CisJfQorCisJb2Z3X2J1c19zZXR1cF9paW5mbyhub2Rl LCAmc2MtPnNjX3BjaV9paW5mbywgc2l6ZW9mKGNlbGxfdCkpOworCitvdXQ6CisJZnJlZShjZWxs X2luZm8sIE1fREVWQlVGKTsKKwlmcmVlKHNjLT5zY19yYW5nZSwgTV9ERVZCVUYpOworCXJtYW5f ZmluaSgmc2MtPnNjX2lvX3JtYW4pOworCXJtYW5fZmluaSgmc2MtPnNjX21lbV9ybWFuKTsKKwor CXJldHVybiAoZXJyb3IpOworfQorCitpbnQKK29md19wY2lfYXR0YWNoKGRldmljZV90IGRldikK K3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7CisJaW50IGVycm9yOworCisJc2MgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7CisJaWYgKCFzYy0+c2NfaW5pdGlhbGl6ZWQpIHsKKwkJZXJyb3Ig PSBvZndfcGNpX2luaXQoZGV2KTsKKwkJaWYgKGVycm9yKQorCQkJcmV0dXJuIChlcnJvcik7CisJ fQorCisJZGV2aWNlX2FkZF9jaGlsZChkZXYsICJwY2kiLCAtMSk7CisJcmV0dXJuIChidXNfZ2Vu ZXJpY19hdHRhY2goZGV2KSk7Cit9CisKK3N0YXRpYyBpbnQKK29md19wY2lfbWF4c2xvdHMoZGV2 aWNlX3QgZGV2KQoreworCisJcmV0dXJuIChQQ0lfU0xPVE1BWCk7Cit9CisKK2ludAorb2Z3X3Bj aV9yb3V0ZV9pbnRlcnJ1cHQoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBkZXYsIGludCBwaW4pCit7 CisJc3RydWN0IG9md19wY2lfc29mdGMgKnNjOworCXN0cnVjdCBvZndfcGNpX3JlZ2lzdGVyIHJl ZzsKKwl1aW50MzJfdCBwaW50ciwgbWludHJbUENJX01BUF9JTlRSXTsKKwlpbnQgaW50cmNlbGxz OworCXBoYW5kbGVfdCBpcGFyZW50OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1cyk7CisJ cGludHIgPSBwaW47CisKKwkvKiBGYWJyaWNhdGUgaW1hcCBpbmZvcm1hdGlvbiBpbiBjYXNlIHRo aXMgaXNuJ3QgYW4gT0ZXIGRldmljZSAqLworCWJ6ZXJvKCZyZWcsIHNpemVvZihyZWcpKTsKKwly ZWcucGh5c19oaSA9IChwY2lfZ2V0X2J1cyhkZXYpIDw8IE9GV19QQ0lfUEhZU19ISV9CVVNTSElG VCkgfAorCSAgICAocGNpX2dldF9zbG90KGRldikgPDwgT0ZXX1BDSV9QSFlTX0hJX0RFVklDRVNI SUZUKSB8CisJICAgIChwY2lfZ2V0X2Z1bmN0aW9uKGRldikgPDwgT0ZXX1BDSV9QSFlTX0hJX0ZV TkNUSU9OU0hJRlQpOworCisJaW50cmNlbGxzID0gb2Z3X2J1c19sb29rdXBfaW1hcChvZndfYnVz X2dldF9ub2RlKGRldiksCisJICAgICZzYy0+c2NfcGNpX2lpbmZvLCAmcmVnLCBzaXplb2YocmVn KSwgJnBpbnRyLCBzaXplb2YocGludHIpLAorCSAgICBtaW50ciwgc2l6ZW9mKG1pbnRyKSwgJmlw YXJlbnQpOworCWlmIChpbnRyY2VsbHMgIT0gMCkgeworCQlwaW50ciA9IG9md19idXNfbWFwX2lu dHIoZGV2LCBpcGFyZW50LCBpbnRyY2VsbHMsIG1pbnRyKTsKKwkJcmV0dXJuIChwaW50cik7CisJ fQorCisJLyoKKwkgKiBNYXliZSBpdCdzIGEgcmVhbCBpbnRlcnJ1cHQsIG5vdCBhbiBpbnRwaW4K KwkgKi8KKwlpZiAocGluID4gUENJX0lOVFJfUElOUykKKwkJcmV0dXJuIChwaW4pOworCisJZGV2 aWNlX3ByaW50ZihidXMsICJjb3VsZCBub3Qgcm91dGUgcGluICVkIGZvciBkZXZpY2UgJWQuJWRc biIsCisJICAgIHBpbiwgcGNpX2dldF9zbG90KGRldiksIHBjaV9nZXRfZnVuY3Rpb24oZGV2KSk7 CisJcmV0dXJuIChQQ0lfSU5WQUxJRF9JUlEpOworfQorCitpbnQKK29md19wY2lfcmVhZF9pdmFy KGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB3aGljaCwgdWludHB0cl90ICpyZXN1 bHQpCit7CisJc3RydWN0IG9md19wY2lfc29mdGMgKnNjOworCisJc2MgPSBkZXZpY2VfZ2V0X3Nv ZnRjKGRldik7CisKKwlzd2l0Y2ggKHdoaWNoKSB7CisJY2FzZSBQQ0lCX0lWQVJfRE9NQUlOOgor CQkqcmVzdWx0ID0gZGV2aWNlX2dldF91bml0KGRldik7CisJCXJldHVybiAoMCk7CisJY2FzZSBQ Q0lCX0lWQVJfQlVTOgorCQkqcmVzdWx0ID0gc2MtPnNjX2J1czsKKwkJcmV0dXJuICgwKTsKKwlk ZWZhdWx0OgorCQlicmVhazsKKwl9CisKKwlyZXR1cm4gKEVOT0VOVCk7Cit9CisKK2ludAorb2Z3 X3BjaV93cml0ZV9pdmFyKGRldmljZV90IGRldiwgZGV2aWNlX3QgY2hpbGQsIGludCB3aGljaCwg dWludHB0cl90IHZhbHVlKQoreworCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKKworCXNjID0g ZGV2aWNlX2dldF9zb2Z0YyhkZXYpOworCisJc3dpdGNoICh3aGljaCkgeworCWNhc2UgUENJQl9J VkFSX0JVUzoKKwkJc2MtPnNjX2J1cyA9IHZhbHVlOworCQlyZXR1cm4gKDApOworCWRlZmF1bHQ6 CisJCWJyZWFrOworCX0KKworCXJldHVybiAoRU5PRU5UKTsKK30KKworaW50CitvZndfcGNpX25y YW5nZXMocGhhbmRsZV90IG5vZGUsIHN0cnVjdCBvZndfcGNpX2NlbGxfaW5mbyAqaW5mbykKK3sK Kwlzc2l6ZV90IG5iYXNlX3JhbmdlczsKKworCWlmIChpbmZvID09IE5VTEwpCisJCXJldHVybiAo LTEpOworCisJaW5mby0+aG9zdF9hZGRyZXNzX2NlbGxzID0gMTsKKwlpbmZvLT5zaXplX2NlbGxz ID0gMjsKKwlpbmZvLT5wY2lfYWRkcmVzc19jZWxsID0gMzsKKworCU9GX2dldGVuY3Byb3AoT0Zf cGFyZW50KG5vZGUpLCAiI2FkZHJlc3MtY2VsbHMiLAorCSAgICAmKGluZm8tPmhvc3RfYWRkcmVz c19jZWxscyksIHNpemVvZihpbmZvLT5ob3N0X2FkZHJlc3NfY2VsbHMpKTsKKwlPRl9nZXRlbmNw cm9wKG5vZGUsICIjYWRkcmVzcy1jZWxscyIsCisJICAgICYoaW5mby0+cGNpX2FkZHJlc3NfY2Vs bCksIHNpemVvZihpbmZvLT5wY2lfYWRkcmVzc19jZWxsKSk7CisJT0ZfZ2V0ZW5jcHJvcChub2Rl LCAiI3NpemUtY2VsbHMiLCAmKGluZm8tPnNpemVfY2VsbHMpLAorCSAgICBzaXplb2YoaW5mby0+ c2l6ZV9jZWxscykpOworCisJbmJhc2VfcmFuZ2VzID0gT0ZfZ2V0cHJvcGxlbihub2RlLCAicmFu Z2VzIik7CisJaWYgKG5iYXNlX3JhbmdlcyA8PSAwKQorCQlyZXR1cm4gKC0xKTsKKworCXJldHVy biAobmJhc2VfcmFuZ2VzIC8gc2l6ZW9mKGNlbGxfdCkgLworCSAgICAoaW5mby0+cGNpX2FkZHJl c3NfY2VsbCArIGluZm8tPmhvc3RfYWRkcmVzc19jZWxscyArCisJICAgIGluZm8tPnNpemVfY2Vs bHMpKTsKK30KKworc3RydWN0IHJlc291cmNlICoKK29md19wY2lfYWxsb2NfcmVzb3VyY2UoZGV2 aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLAorICAgIHJtYW5f cmVzX3Qgc3RhcnQsIHJtYW5fcmVzX3QgZW5kLCBybWFuX3Jlc190IGNvdW50LCB1X2ludCBmbGFn cykKK3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7CisJc3RydWN0IHJlc291cmNlICpydjsK KwlzdHJ1Y3Qgcm1hbiAqcm07CisJaW50IG5lZWRhY3RpdmF0ZTsKKworCW5lZWRhY3RpdmF0ZSA9 IGZsYWdzICYgUkZfQUNUSVZFOworCWZsYWdzICY9IH5SRl9BQ1RJVkU7CisKKwlzYyA9IGRldmlj ZV9nZXRfc29mdGMoYnVzKTsKKworCXN3aXRjaCAodHlwZSkgeworCWNhc2UgU1lTX1JFU19NRU1P Ulk6CisJCXJtID0gJnNjLT5zY19tZW1fcm1hbjsKKwkJYnJlYWs7CisKKwljYXNlIFNZU19SRVNf SU9QT1JUOgorCQlybSA9ICZzYy0+c2NfaW9fcm1hbjsKKwkJYnJlYWs7CisKKwljYXNlIFNZU19S RVNfSVJROgorCisjaWZkZWYgX19zcGFyYzY0X18KKwkJaWYgKHN0YXJ0ICE9IGVuZCkKKwkJCXBh bmljKCIlczogWFhYOiBpbnRlcnJ1cHQgcmFuZ2UiLCBfX2Z1bmNfXyk7CisJCXJldHVybiAoYnVz X2dlbmVyaWNfYWxsb2NfcmVzb3VyY2UoYnVzLCBjaGlsZCwgdHlwZSwgcmlkLCBzdGFydCwKKwkJ ICAgIGVuZCwgY291bnQsIGZsYWdzKSk7CisjZWxzZQorCQlyZXR1cm4gKGJ1c19hbGxvY19yZXNv dXJjZShidXMsIHR5cGUsIHJpZCwgc3RhcnQsIGVuZCwgY291bnQsCisJCSAgICBmbGFncykpOwor I2VuZGlmCisKKwlkZWZhdWx0OgorCQlkZXZpY2VfcHJpbnRmKGJ1cywgInVua25vd24gcmVzb3Vy Y2UgcmVxdWVzdCBmcm9tICVzXG4iLAorCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZCkp OworCQlyZXR1cm4gKE5VTEwpOworCX0KKworCXJ2ID0gcm1hbl9yZXNlcnZlX3Jlc291cmNlKHJt LCBzdGFydCwgZW5kLCBjb3VudCwgZmxhZ3MsIGNoaWxkKTsKKwlpZiAocnYgPT0gTlVMTCkgewor CQlkZXZpY2VfcHJpbnRmKGJ1cywgImZhaWxlZCB0byByZXNlcnZlIHJlc291cmNlIGZvciAlc1xu IiwKKwkJICAgIGRldmljZV9nZXRfbmFtZXVuaXQoY2hpbGQpKTsKKwkJcmV0dXJuIChOVUxMKTsK Kwl9CisKKwlybWFuX3NldF9yaWQocnYsICpyaWQpOworCisJaWYgKG5lZWRhY3RpdmF0ZSkgewor CQlpZiAoYnVzX2FjdGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBlLCAqcmlkLCBydikgIT0gMCkg eworCQkJZGV2aWNlX3ByaW50ZihidXMsCisJCQkgICAgImZhaWxlZCB0byBhY3RpdmF0ZSByZXNv dXJjZSBmb3IgJXNcbiIsCisJCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZCkpOworCQkJ cm1hbl9yZWxlYXNlX3Jlc291cmNlKHJ2KTsKKwkJCXJldHVybiAoTlVMTCk7CisJCX0KKwl9CisK KwlyZXR1cm4gKHJ2KTsKK30KKworc3RhdGljIGludAorb2Z3X3BjaV9yZWxlYXNlX3Jlc291cmNl KGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAorICAgIHN0 cnVjdCByZXNvdXJjZSAqcmVzKQoreworCisJaWYgKHJtYW5fZ2V0X2ZsYWdzKHJlcykgJiBSRl9B Q1RJVkUpIHsKKwkJaW50IGVycm9yID0gYnVzX2RlYWN0aXZhdGVfcmVzb3VyY2UoY2hpbGQsIHR5 cGUsIHJpZCwgcmVzKTsKKwkJaWYgKGVycm9yKQorCQkJcmV0dXJuIGVycm9yOworCX0KKworCXJl dHVybiAocm1hbl9yZWxlYXNlX3Jlc291cmNlKHJlcykpOworfQorCitzdGF0aWMgaW50CitvZndf cGNpX2FjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0 eXBlLCBpbnQgcmlkLAorICAgIHN0cnVjdCByZXNvdXJjZSAqcmVzKQoreworCXN0cnVjdCBvZndf cGNpX3NvZnRjICpzYzsKKwlidXNfc3BhY2VfaGFuZGxlX3QgaGFuZGxlOworCWJ1c19zcGFjZV90 YWdfdCB0YWc7CisJaW50IHJ2OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1cyk7CisKKwlp ZiAodHlwZSA9PSBTWVNfUkVTX0lSUSkgeworCQlyZXR1cm4gKGJ1c19hY3RpdmF0ZV9yZXNvdXJj ZShidXMsIHR5cGUsIHJpZCwgcmVzKSk7CisJfQorCWlmICh0eXBlID09IFNZU19SRVNfTUVNT1JZ IHx8IHR5cGUgPT0gU1lTX1JFU19JT1BPUlQpIHsKKwkJc3RydWN0IG9md19wY2lfcmFuZ2UgKnJw OworCQl2bV9vZmZzZXRfdCBzdGFydDsKKwkJaW50IHNwYWNlOworCisJCXN0YXJ0ID0gKHZtX29m ZnNldF90KXJtYW5fZ2V0X3N0YXJ0KHJlcyk7CisKKwkJLyoKKwkJICogTWFwIHRoaXMgdGhyb3Vn aCB0aGUgcmFuZ2VzIGxpc3QKKwkJICovCisJCWZvciAocnAgPSBzYy0+c2NfcmFuZ2U7IHJwIDwg c2MtPnNjX3JhbmdlICsgc2MtPnNjX25yYW5nZSAmJgorCQkgICAgcnAtPnBjaV9oaSAhPSAwOyBy cCsrKSB7CisJCQlpZiAoc3RhcnQgPCBycC0+cGNpIHx8IHN0YXJ0ID49IHJwLT5wY2kgKyBycC0+ c2l6ZSkKKwkJCQljb250aW51ZTsKKworCQkJc3dpdGNoIChycC0+cGNpX2hpICYgT0ZXX1BDSV9Q SFlTX0hJX1NQQUNFTUFTSykgeworCQkJY2FzZSBPRldfUENJX1BIWVNfSElfU1BBQ0VfSU86CisJ CQkJc3BhY2UgPSBTWVNfUkVTX0lPUE9SVDsKKwkJCQlicmVhazsKKwkJCWNhc2UgT0ZXX1BDSV9Q SFlTX0hJX1NQQUNFX01FTTMyOgorCQkJY2FzZSBPRldfUENJX1BIWVNfSElfU1BBQ0VfTUVNNjQ6 CisJCQkJc3BhY2UgPSBTWVNfUkVTX01FTU9SWTsKKwkJCQlicmVhazsKKwkJCWRlZmF1bHQ6CisJ CQkJc3BhY2UgPSAtMTsKKwkJCX0KKworCQkJaWYgKHR5cGUgPT0gc3BhY2UpIHsKKwkJCQlzdGFy dCArPSAocnAtPmhvc3QgLSBycC0+cGNpKTsKKwkJCQlicmVhazsKKwkJCX0KKwkJfQorCisJCWlm IChib290dmVyYm9zZSkKKwkJCXByaW50Zigib2Z3X3BjaSBtYXBkZXY6IHN0YXJ0ICV6eCwgbGVu ICVsZFxuIiwgc3RhcnQsCisJCQkgICAgcm1hbl9nZXRfc2l6ZShyZXMpKTsKKworCQl0YWcgPSBC VVNfR0VUX0JVU19UQUcoY2hpbGQsIGNoaWxkKTsKKwkJaWYgKHRhZyA9PSBOVUxMKQorCQkJcmV0 dXJuIChFTk9NRU0pOworCisJCXJtYW5fc2V0X2J1c3RhZyhyZXMsIHRhZyk7CisJCXJ2ID0gYnVz X3NwYWNlX21hcCh0YWcsIHN0YXJ0LAorCQkgICAgcm1hbl9nZXRfc2l6ZShyZXMpLCAwLCAmaGFu ZGxlKTsKKwkJaWYgKHJ2ICE9IDApCisJCQlyZXR1cm4gKEVOT01FTSk7CisKKwkJcm1hbl9zZXRf YnVzaGFuZGxlKHJlcywgaGFuZGxlKTsKKwkJcm1hbl9zZXRfdmlydHVhbChyZXMsICh2b2lkICop aGFuZGxlKTsgLyogWFhYICBmb3IgcG93ZXJwYyBvbmx5ID8gKi8KKwl9CisKKwlyZXR1cm4gKHJt YW5fYWN0aXZhdGVfcmVzb3VyY2UocmVzKSk7Cit9CisKKyNpZmRlZiBfX3Bvd2VycGNfXworc3Rh dGljIGJ1c19zcGFjZV90YWdfdAorb2Z3X3BjaV9idXNfZ2V0X2J1c190YWcoZGV2aWNlX3QgYnVz LCBkZXZpY2VfdCBjaGlsZCkKK3sKKworCXJldHVybiAoJmJzX2xlX3RhZyk7Cit9CisjZW5kaWYK Kworc3RhdGljIGludAorb2Z3X3BjaV9kZWFjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywg ZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAorICAgIHN0cnVjdCByZXNvdXJjZSAq cmVzKQoreworCisJLyoKKwkgKiBJZiB0aGlzIGlzIGEgbWVtb3J5IHJlc291cmNlLCB1bm1hcCBp dC4KKwkgKi8KKwlpZiAoKHR5cGUgPT0gU1lTX1JFU19NRU1PUlkpIHx8ICh0eXBlID09IFNZU19S RVNfSU9QT1JUKSkgeworCQl1X2ludDMyX3QgcHNpemU7CisKKwkJcHNpemUgPSBybWFuX2dldF9z aXplKHJlcyk7CisKKwkJLyoKKwkJICogWFhYOiBUaGUgaW1wbGVtZW50YXRpb24gaXMgbWFjaGlu ZS1kZXBlbmRlbnQgYW5kCisJCSAqIHNwYXJjNjQgdXNlcyBhIGRpZmZlcmVudCBmdW5jdGlvbiBz aWduYXR1cmUgYXMgd2VsbC4KKwkJICovCisjaWZuZGVmIF9fc3BhcmM2NF9fCisJCXBtYXBfdW5t YXBkZXYoKHZtX29mZnNldF90KXJtYW5fZ2V0X3ZpcnR1YWwocmVzKSwgcHNpemUpOworI2VuZGlm CisJfQorCisJcmV0dXJuIChybWFuX2RlYWN0aXZhdGVfcmVzb3VyY2UocmVzKSk7Cit9CisKK2lu dAorb2Z3X3BjaV9hZGp1c3RfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwg aW50IHR5cGUsCisgICAgc3RydWN0IHJlc291cmNlICpyZXMsIHJtYW5fcmVzX3Qgc3RhcnQsIHJt YW5fcmVzX3QgZW5kKQoreworCXN0cnVjdCBybWFuICpybSA9IE5VTEw7CisJc3RydWN0IG9md19w Y2lfc29mdGMgKnNjID0gZGV2aWNlX2dldF9zb2Z0YyhidXMpOworCisJS0FTU0VSVCghKHJtYW5f Z2V0X2ZsYWdzKHJlcykgJiBSRl9BQ1RJVkUpLAorCSAgICAoImFjdGl2ZSByZXNvdXJjZXMgY2Fu bm90IGJlIGFkanVzdGVkIikpOworCWlmIChybWFuX2dldF9mbGFncyhyZXMpICYgUkZfQUNUSVZF KQorCQlyZXR1cm4gKEVJTlZBTCk7CisKKwlzd2l0Y2ggKHR5cGUpIHsKKwljYXNlIFNZU19SRVNf TUVNT1JZOgorCQlybSA9ICZzYy0+c2NfbWVtX3JtYW47CisJCWJyZWFrOworCWNhc2UgU1lTX1JF U19JT1BPUlQ6CisJCXJtID0gJnNjLT5zY19pb19ybWFuOworCQlicmVhazsKKwljYXNlIFNZU19S RVNfSVJROgorCQlyZXR1cm4gKGJ1c19nZW5lcmljX2FkanVzdF9yZXNvdXJjZShidXMsIGNoaWxk LCB0eXBlLCByZXMsCisJCSAgICBzdGFydCwgZW5kKSk7CisJZGVmYXVsdDoKKwkJcmV0dXJuIChF TlhJTyk7CisJfQorCisJaWYgKCFybWFuX2lzX3JlZ2lvbl9tYW5hZ2VyKHJlcywgcm0pKQorCQly ZXR1cm4gKEVJTlZBTCk7CisKKwlyZXR1cm4gKHJtYW5fYWRqdXN0X3Jlc291cmNlKHJlcywgc3Rh cnQsIGVuZCkpOworfQorCitwaGFuZGxlX3QKK29md19wY2lfZ2V0X25vZGUoZGV2aWNlX3QgYnVz LCBkZXZpY2VfdCBkZXYpCit7CisJc3RydWN0IG9md19wY2lfc29mdGMgKnNjOworCisJc2MgPSBk ZXZpY2VfZ2V0X3NvZnRjKGJ1cyk7CisJLyogV2Ugb25seSBoYXZlIG9uZSBjaGlsZCwgdGhlIFBD SSBidXMsIHdoaWNoIG5lZWRzIG91ciBvd24gbm9kZS4gKi8KKworCXJldHVybiAoc2MtPnNjX25v ZGUpOworfQorCitidXNfZG1hX3RhZ190CitvZndfcGNpX2dldF9kbWFfdGFnKGRldmljZV90IGJ1 cywgZGV2aWNlX3QgY2hpbGQgX191bnVzZWQpCit7CisJc3RydWN0IG9md19wY2lfc29mdGMgKnNj OworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1cyk7CisJcmV0dXJuIChzYy0+c2NfZG1hdCk7 Cit9CisKK2ludAorb2Z3X3BjaV9maWxsX3JhbmdlcyhwaGFuZGxlX3Qgbm9kZSwgc3RydWN0IG9m d19wY2lfcmFuZ2UgKnJhbmdlcykKK3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9jZWxsX2luZm8gKmNlbGxf aW5mbzsKKwlwY2VsbF90ICpiYXNlX3JhbmdlczsKKwlzc2l6ZV90IG5iYXNlX3JhbmdlczsKKwlp bnQgbnJhbmdlczsKKwlpbnQgaSwgaiwgazsKKworCWNlbGxfaW5mbyA9IChzdHJ1Y3Qgb2Z3X3Bj aV9jZWxsX2luZm8gKiltYWxsb2Moc2l6ZW9mKCpjZWxsX2luZm8pLAorCSAgICBNX0RFVkJVRiwg TV9XQUlUT0sgfCBNX1pFUk8pOworCisJbnJhbmdlcyA9IG9md19wY2lfbnJhbmdlcyhub2RlLCBj ZWxsX2luZm8pOworCisJbmJhc2VfcmFuZ2VzID0gT0ZfZ2V0cHJvcGxlbihub2RlLCAicmFuZ2Vz Iik7CisJaWYgKG5iYXNlX3JhbmdlcyA8PSAwKQorCQlyZXR1cm4gKC0xKTsKKwliYXNlX3Jhbmdl cyA9IG1hbGxvYyhuYmFzZV9yYW5nZXMsIE1fREVWQlVGLCBNX1dBSVRPSyk7CisJT0ZfZ2V0ZW5j cHJvcChub2RlLCAicmFuZ2VzIiwgYmFzZV9yYW5nZXMsIG5iYXNlX3Jhbmdlcyk7CisKKwlmb3Ig KGkgPSAwLCBqID0gMDsgaSA8IG5yYW5nZXM7IGkrKykgeworCQlyYW5nZXNbaV0ucGNpX2hpID0g YmFzZV9yYW5nZXNbaisrXTsKKwkJcmFuZ2VzW2ldLnBjaSA9IDA7CisJCWZvciAoayA9IDA7IGsg PCBjZWxsX2luZm8tPnBjaV9hZGRyZXNzX2NlbGwgLSAxOyBrKyspIHsKKwkJCXJhbmdlc1tpXS5w Y2kgPDw9IDMyOworCQkJcmFuZ2VzW2ldLnBjaSB8PSBiYXNlX3Jhbmdlc1tqKytdOworCQl9CisJ CXJhbmdlc1tpXS5ob3N0ID0gMDsKKwkJZm9yIChrID0gMDsgayA8IGNlbGxfaW5mby0+aG9zdF9h ZGRyZXNzX2NlbGxzOyBrKyspIHsKKwkJCXJhbmdlc1tpXS5ob3N0IDw8PSAzMjsKKwkJCXJhbmdl c1tpXS5ob3N0IHw9IGJhc2VfcmFuZ2VzW2orK107CisJCX0KKwkJcmFuZ2VzW2ldLnNpemUgPSAw OworCQlmb3IgKGsgPSAwOyBrIDwgY2VsbF9pbmZvLT5zaXplX2NlbGxzOyBrKyspIHsKKwkJCXJh bmdlc1tpXS5zaXplIDw8PSAzMjsKKwkJCXJhbmdlc1tpXS5zaXplIHw9IGJhc2VfcmFuZ2VzW2or K107CisJCX0KKwl9CisKKwlmcmVlKGJhc2VfcmFuZ2VzLCBNX0RFVkJVRik7CisJcmV0dXJuIChu cmFuZ2VzKTsKK30KZGlmZiAtLWdpdCBhL3N5cy9kZXYvb2Z3L29md19wY2kuaCBiL3N5cy9kZXYv b2Z3L29md19wY2kuaAppbmRleCBlYjYwYzViLi43NDM1NWQyIDEwMDY0NAotLS0gYS9zeXMvZGV2 L29mdy9vZndfcGNpLmgKKysrIGIvc3lzL2Rldi9vZncvb2Z3X3BjaS5oCkBAIC04OSw2ICs4OSw0 NyBAQAogI2RlZmluZSBPRldfUENJX1BIWVNfSElfRlVOQ1RJT04oaGkpIFwKIAkoKChoaSkgJiBP RldfUENJX1BIWVNfSElfRlVOQ1RJT05NQVNLKSA+PiBPRldfUENJX1BIWVNfSElfRlVOQ1RJT05T SElGVCkKIAorI2RlZmluZQlPRldfUENJX1NQQUNFX05VTQkJNAorCisvKgorICogRXhwb3J0IGNs YXNzIGRlZmluaXRpb24gZm9yIGluaGVyaXRhbmNlIHB1cnBvc2VzCisgKi8KK0RFQ0xBUkVfQ0xB U1Mob2Z3X3BjaV9kcml2ZXIpOworCit0eXBlZGVmIHVpbnQzMl90IG9md19wY2lfaW50cl90Owor CisvKiBPRlcgZGV2aWNlIHR5cGVzICovCisjZGVmaW5lCU9GV19UWVBFX1BDSQkJInBjaSIKKyNk ZWZpbmUJT0ZXX1RZUEVfUENJRQkJInBjaWV4IgorCitzdHJ1Y3Qgb2Z3X3BjaV9tc2lfYWRkcl9y YW5nZXMgeworCXVpbnQzMl90CWFkZHIzMl9oaTsKKwl1aW50MzJfdAlhZGRyMzJfbG87CisJdWlu dDMyX3QJYWRkcjMyX3N6OworCXVpbnQzMl90CWFkZHI2NF9oaTsKKwl1aW50MzJfdAlhZGRyNjRf bG87CisJdWludDMyX3QJYWRkcjY0X3N6OworfTsKKworI2RlZmluZQlPRldfUENJX01TSV9BRERS X1JBTkdFXzMyKHIpIFwKKwkoKCh1aW50NjRfdCkociktPmFkZHIzMl9oaSA8PCAzMikgfCAodWlu dDY0X3QpKHIpLT5hZGRyMzJfbG8pCisjZGVmaW5lCU9GV19QQ0lfTVNJX0FERFJfUkFOR0VfNjQo cikgXAorCSgoKHVpbnQ2NF90KShyKS0+YWRkcjY0X2hpIDw8IDMyKSB8ICh1aW50NjRfdCkocikt PmFkZHI2NF9sbykKKworc3RydWN0IG9md19wY2lfbXNpX2VxX3RvX2RldmlubyB7CisJdWludDMy X3QJZXFfZmlyc3Q7CisJdWludDMyX3QJZXFfY291bnQ7CisJdWludDMyX3QJZGV2aW5vX2ZpcnN0 OworfTsKKworc3RydWN0IG9md19wY2lfbXNpX3JhbmdlcyB7CisJdWludDMyX3QJZmlyc3Q7CisJ dWludDMyX3QJY291bnQ7Cit9OworCisvKiBkZWZhdWx0IHZhbHVlcyAqLworI2RlZmluZQlPRldf UENJX0xBVEVOQ1kJNjQKKwogLyoKICAqIFRoaXMgaGFzIHRoZSAzIDMyYml0IGNlbGwgdmFsdWVz LCBwbHVzIDIgbW9yZSB0byBtYWtlIHVwIGEgNjQtYml0IHNpemUuCiAgKi8KQEAgLTEwMCw0ICsx NDEsODcgQEAgc3RydWN0IG9md19wY2lfcmVnaXN0ZXIgewogCXVfaW50MzJfdAlzaXplX2xvOwog fTsKIAorc3RydWN0IG9md19wY2lfY2VsbF9pbmZvIHsKKwlwY2VsbF90IGhvc3RfYWRkcmVzc19j ZWxsczsKKwlwY2VsbF90IHBjaV9hZGRyZXNzX2NlbGw7CisJcGNlbGxfdCBzaXplX2NlbGxzOwor IH07CisKK3N0cnVjdCBvZndfcGNpX3JhbmdlIHsKKwl1aW50MzJfdAlwY2lfaGk7CisJdWludDY0 X3QJcGNpOworCXVpbnQ2NF90CWhvc3Q7CisJdWludDY0X3QJc2l6ZTsKK307CisKKy8qCisgKiBR dWlya3MgZm9yIHNvbWUgYWRhcHRlcnMKKyAqLworZW51bSB7CisJT0ZXX1BDSV9RVUlSS19SQU5H RVNfT05fQ0hJTERSRU4gPSAxLAorfTsKKworLyoKKyAqIEluZGV4IGludG8gdGhlIHNjX2JoW10g YXJyYXksIGl0IGlzCisgKiBjb3JyZXNwb25kaW5nIHRvIHRoZSBQQ0kgc3BhY2UgcmFuZ2VzIHR5 cGUKKyAqLworZW51bSBvZndfcGNpX3Jhbmdlc190eXBlIHsKKwlPRldfUENJX0NPTkZJRyA9IDAs CisJT0ZXX1BDSV9JTywKKwlPRldfUENJX01FTTMyLAorCU9GV19QQ0lfTUVNNjQKK307CisKK3N0 cnVjdCBvZndfcGNpX3NvZnRjIHsKKwlkZXZpY2VfdAlzY19kZXY7CisJcGhhbmRsZV90CXNjX25v ZGU7CisJaW50CQlzY19idXM7CisJaW50CQlzY19pbml0aWFsaXplZDsKKwlpbnQJCXNjX3F1aXJr czsKKwl1aW50OF90CQlzY19zZWNidXM7CisJdWludDhfdAkJc2Nfc3ViYnVzOworCisJc3RydWN0 IG9md19wY2lfcmFuZ2UJCSpzY19yYW5nZTsKKwlpbnQJCQkJc2NfbnJhbmdlOworCXN0cnVjdCBv ZndfcGNpX2NlbGxfaW5mbwkqc2NfY2VsbF9pbmZvOworCisJc3RydWN0IHJtYW4JCQlzY19pb19y bWFuOworCXN0cnVjdCBybWFuCQkJc2NfbWVtX3JtYW47CisJYnVzX3NwYWNlX3RhZ190CQkJc2Nf bWVtdDsKKwlidXNfc3BhY2VfdGFnX3QJCQlzY19jZmd0OworCWJ1c19zcGFjZV90YWdfdAkJCXNj X2lvdDsKKwlidXNfZG1hX3RhZ190CQkJc2NfZG1hdDsKKwlidXNfc3BhY2VfaGFuZGxlX3QJCXNj X2JoW09GV19QQ0lfU1BBQ0VfTlVNXTsKKworCXN0cnVjdCBvZndfYnVzX2lpbmZvCQlzY19wY2lf aWluZm87Cit9OworCitpbnQgb2Z3X3BjaV9pbml0KGRldmljZV90KTsKK2ludCBvZndfcGNpX2F0 dGFjaChkZXZpY2VfdCk7CitpbnQgb2Z3X3BjaV9yZWFkX2l2YXIoZGV2aWNlX3QsIGRldmljZV90 LCBpbnQsIHVpbnRwdHJfdCAqKTsKK2ludCBvZndfcGNpX3dyaXRlX2l2YXIoZGV2aWNlX3QsIGRl dmljZV90LCBpbnQsIHVpbnRwdHJfdCk7CitpbnQgb2Z3X3BjaV9yb3V0ZV9pbnRlcnJ1cHQoZGV2 aWNlX3QsIGRldmljZV90LCBpbnQpOworaW50IG9md19wY2lfbnJhbmdlcyhwaGFuZGxlX3QsIHN0 cnVjdCBvZndfcGNpX2NlbGxfaW5mbyAqKTsKK2ludCBvZndfcGNpX2ZpbGxfcmFuZ2VzKHBoYW5k bGVfdCwgc3RydWN0IG9md19wY2lfcmFuZ2UgKik7CisKK2ludCBvZndfcGNpX2FkanVzdF9yZXNv dXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwKKyAgICBzdHJ1Y3QgcmVzb3VyY2UgKiwgdV9s b25nLCB1X2xvbmcpOworc3RydWN0IHJlc291cmNlICogb2Z3X3BjaV9hbGxvY19yZXNvdXJjZShk ZXZpY2VfdCwgZGV2aWNlX3QsCisgICAgaW50LCBpbnQgKiwgdV9sb25nLCB1X2xvbmcsIHVfbG9u ZywgdV9pbnQpOworaW50IHNwYXJjNjRfb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZShkZXZpY2Vf dCwgZGV2aWNlX3QsIGludCwgaW50LAorICAgIHN0cnVjdCByZXNvdXJjZSAqKTsKK2ludCBzcGFy YzY0X29md19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZShkZXZpY2VfdCwgZGV2aWNlX3QsIGludCwg aW50LAorICAgIHN0cnVjdCByZXNvdXJjZSAqKTsKKworaW50IG9md19wY2lfYXR0YWNoX2NvbW1v bihkZXZpY2VfdCwgYnVzX2RtYV90YWdfdCwgdV9sb25nLCB1X2xvbmcpOwordWludDMyX3Qgb2Z3 X3BjaV9yZWFkX2NvbmZpZ19jb21tb24oZGV2aWNlX3QsIHVfaW50LCB1X2xvbmcsIHVfaW50LCB1 X2ludCwKKyAgICB1X2ludCwgdV9pbnQsIGludCk7Cit2b2lkIG9md19wY2lfd3JpdGVfY29uZmln X2NvbW1vbihkZXZpY2VfdCwgdV9pbnQsIHVfbG9uZywgdV9pbnQsIHVfaW50LAorICAgIHVfaW50 LCB1X2ludCwgdWludDMyX3QsIGludCk7CitvZndfcGNpX2ludHJfdCBvZndfcGNpX3JvdXRlX2lu dGVycnVwdF9jb21tb24oZGV2aWNlX3QsIGRldmljZV90LCBpbnQpOwordm9pZCBvZndfcGNpX2Rt YW1hcF9zeW5jX3N0c3Rfb3JkZXJfY29tbW9uKHZvaWQpOworCitvZndfYnVzX2dldF9ub2RlX3Qg b2Z3X3BjaV9nZXRfbm9kZTsKK2J1c19nZXRfZG1hX3RhZ190IG9md19wY2lfZ2V0X2RtYV90YWc7 CisKICNlbmRpZiAvKiBfREVWX09GV19PRldfUENJX0hfICovCmRpZmYgLS1naXQgYS9zeXMvZGV2 L29mdy9vZndfc3Vici5jIGIvc3lzL2Rldi9vZncvb2Z3X3N1YnIuYwppbmRleCA0ZDE0ZGI3Li5l OWI2NmMyIDEwMDY0NAotLS0gYS9zeXMvZGV2L29mdy9vZndfc3Vici5jCisrKyBiL3N5cy9kZXYv b2Z3L29md19zdWJyLmMKQEAgLTM5LDggKzM5LDkgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwog I2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+ Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfc3Vi ci5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29m dy9vZndfcGNpLmg+CiAKIHN0YXRpYyB2b2lkCiBnZXRfYWRkcl9wcm9wcyhwaGFuZGxlX3Qgbm9k ZSwgdWludDMyX3QgKmFkZHJwLCB1aW50MzJfdCAqc2l6ZXAsIGludCAqcGNpcCkKZGlmZiAtLWdp dCBhL3N5cy9kZXYvdnQvaHcvb2Z3ZmIvb2Z3ZmIuYyBiL3N5cy9kZXYvdnQvaHcvb2Z3ZmIvb2Z3 ZmIuYwppbmRleCAwNzc2YThlLi5mZjQ2N2ZhIDEwMDY0NAotLS0gYS9zeXMvZGV2L3Z0L2h3L29m d2ZiL29md2ZiLmMKKysrIGIvc3lzL2Rldi92dC9ody9vZndmYi9vZndmYi5jCkBAIC0zMSw2ICsz MSw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiAj aW5jbHVkZSA8c3lzL3N5c3RtLmg+CiAjaW5jbHVkZSA8c3lzL2ZiaW8uaD4KKyNpbmNsdWRlIDxz eXMvcm1hbi5oPgogCiAjaW5jbHVkZSA8ZGV2L3Z0L3Z0Lmg+CiAjaW5jbHVkZSA8ZGV2L3Z0L2h3 L2ZiL3Z0X2ZiLmg+CkBAIC00Niw2ICs0Nyw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKIAog I2luY2x1ZGUgPGRldi9vZncvb3BlbmZpcm0uaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMu aD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogI2luY2x1ZGUgPGRldi9vZncv b2Z3X3BjaS5oPgogCiBzdHJ1Y3Qgb2Z3ZmJfc29mdGMgewpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2Vy cGMvbXBjODV4eC9wY2lfbXBjODV4eC5jIGIvc3lzL3Bvd2VycGMvbXBjODV4eC9wY2lfbXBjODV4 eC5jCmluZGV4IDQzOTdhYzAuLmRlNTVhZmMgMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL21wYzg1 eHgvcGNpX21wYzg1eHguYworKysgYi9zeXMvcG93ZXJwYy9tcGM4NXh4L3BjaV9tcGM4NXh4LmMK QEAgLTU1LDE1ICs1NSwxMyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8dm0v dm0uaD4KICNpbmNsdWRlIDx2bS9wbWFwLmg+CiAKLSNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2ku aD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19i dXNfc3Vici5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X3BjaS5oPgogI2luY2x1ZGUgPGRldi9w Y2kvcGNpdmFyLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KICNpbmNsdWRlIDxkZXYv cGNpL3BjaWJfcHJpdmF0ZS5oPgogCi0jaW5jbHVkZSA8cG93ZXJwYy9vZncvb2Z3X3BjaS5oPgot CiAjaW5jbHVkZSAib2Z3X2J1c19pZi5oIgogI2luY2x1ZGUgInBjaWJfaWYuaCIKIApkaWZmIC0t Z2l0IGEvc3lzL3Bvd2VycGMvb2Z3L29md19tYWNoZGVwLmMgYi9zeXMvcG93ZXJwYy9vZncvb2Z3 X21hY2hkZXAuYwppbmRleCAzMDUxZWIzLi40MDkyMjg4IDEwMDY0NAotLS0gYS9zeXMvcG93ZXJw Yy9vZncvb2Z3X21hY2hkZXAuYworKysgYi9zeXMvcG93ZXJwYy9vZncvb2Z3X21hY2hkZXAuYwpA QCAtNTAsNiArNTAsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxkZXYv ZmR0L2ZkdF9jb21tb24uaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVk ZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4K ICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19zdWJy Lmg+CmRpZmYgLS1naXQgYS9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaS5jIGIvc3lzL3Bvd2VycGMv b2Z3L29md19wY2kuYwpkZWxldGVkIGZpbGUgbW9kZSAxMDA2NDQKaW5kZXggMGNhNWJjMC4uMDAw MDAwMAotLS0gYS9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaS5jCisrKyAvZGV2L251bGwKQEAgLTEs NTU4ICswLDAgQEAKLS8qLQotICogQ29weXJpZ2h0IChjKSAyMDExIE5hdGhhbiBXaGl0ZWhvcm4K LSAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCi0gKgotICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBp biBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Ci0gKiBtb2RpZmljYXRp b24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMK LSAqIGFyZSBtZXQ6Ci0gKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCBy ZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAotICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29u ZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgotICogMi4gUmVkaXN0cmlidXRp b25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKLSAq ICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlz Y2xhaW1lciBpbiB0aGUKLSAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFs cyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCi0gKgotICogVEhJUyBTT0ZUV0FSRSBJ UyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAot ICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgVEhFCi0gKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZ IEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQotICogQVJFIERJU0NMQUlNRUQu ICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUK LSAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBM QVJZLCBPUiBDT05TRVFVRU5USUFMCi0gKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUwotICogT1IgU0VSVklDRVM7 IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04p Ci0gKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRI RVIgSU4gQ09OVFJBQ1QsIFNUUklDVAotICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcg TkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQotICogT1VUIE9GIFRI RSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElU WSBPRgotICogU1VDSCBEQU1BR0UuCi0gKi8KLQotI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgotX19G QlNESUQoIiRGcmVlQlNEJCIpOwotI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgotI2luY2x1ZGUgPHN5 cy9zeXN0bS5oPgotI2luY2x1ZGUgPHN5cy9tb2R1bGUuaD4KLSNpbmNsdWRlIDxzeXMvYnVzLmg+ Ci0jaW5jbHVkZSA8c3lzL2NvbmYuaD4KLSNpbmNsdWRlIDxzeXMva2VybmVsLmg+Ci0KLSNpbmNs dWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+Ci0j aW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1 YnIuaD4KLQotI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+Ci0jaW5jbHVkZSA8ZGV2L3BjaS9w Y2lyZWcuaD4KLQotI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+Ci0jaW5jbHVkZSA8bWFjaGluZS9p bnRyX21hY2hkZXAuaD4KLSNpbmNsdWRlIDxtYWNoaW5lL21kX3Zhci5oPgotI2luY2x1ZGUgPG1h Y2hpbmUvcGlvLmg+Ci0jaW5jbHVkZSA8bWFjaGluZS9yZXNvdXJjZS5oPgotCi0jaW5jbHVkZSA8 c3lzL3JtYW4uaD4KLQotI2luY2x1ZGUgPHZtL3ZtLmg+Ci0jaW5jbHVkZSA8dm0vcG1hcC5oPgot Ci0jaW5jbHVkZSA8cG93ZXJwYy9vZncvb2Z3X3BjaS5oPgotCi0jaW5jbHVkZSAicGNpYl9pZi5o IgotCi0vKgotICogQnVzIGludGVyZmFjZS4KLSAqLwotc3RhdGljIGludAkJb2Z3X3BjaV9yZWFk X2l2YXIoZGV2aWNlX3QsIGRldmljZV90LCBpbnQsCi0JCQkgICAgdWludHB0cl90ICopOwotc3Rh dGljIHN0cnVjdAkJcmVzb3VyY2UgKiBvZndfcGNpX2FsbG9jX3Jlc291cmNlKGRldmljZV90IGJ1 cywKLQkJCSAgICBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlkLCBybWFuX3Jlc190 IHN0YXJ0LAotCQkJICAgIHJtYW5fcmVzX3QgZW5kLCBybWFuX3Jlc190IGNvdW50LCB1X2ludCBm bGFncyk7Ci1zdGF0aWMgaW50CQlvZndfcGNpX3JlbGVhc2VfcmVzb3VyY2UoZGV2aWNlX3QgYnVz LCBkZXZpY2VfdCBjaGlsZCwKLSAgICAJCQkgICAgaW50IHR5cGUsIGludCByaWQsIHN0cnVjdCBy ZXNvdXJjZSAqcmVzKTsKLXN0YXRpYyBpbnQJCW9md19wY2lfYWN0aXZhdGVfcmVzb3VyY2UoZGV2 aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwKLQkJCSAgICBpbnQgdHlwZSwgaW50IHJpZCwgc3Ry dWN0IHJlc291cmNlICpyZXMpOwotc3RhdGljIGludAkJb2Z3X3BjaV9kZWFjdGl2YXRlX3Jlc291 cmNlKGRldmljZV90IGJ1cywKLSAgICAJCQkgICAgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBp bnQgcmlkLAotICAgIAkJCSAgICBzdHJ1Y3QgcmVzb3VyY2UgKnJlcyk7Ci1zdGF0aWMgaW50CQlv ZndfcGNpX2FkanVzdF9yZXNvdXJjZShkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLAotCQkJ ICAgIGludCB0eXBlLCBzdHJ1Y3QgcmVzb3VyY2UgKnJlcywgcm1hbl9yZXNfdCBzdGFydCwKLQkJ CSAgICBybWFuX3Jlc190IGVuZCk7Ci0KLS8qCi0gKiBwY2liIGludGVyZmFjZS4KLSAqLwotc3Rh dGljIGludAkJb2Z3X3BjaV9tYXhzbG90cyhkZXZpY2VfdCk7Ci1zdGF0aWMgaW50CQlvZndfcGNp X3JvdXRlX2ludGVycnVwdChkZXZpY2VfdCwgZGV2aWNlX3QsIGludCk7Ci0KLS8qCi0gKiBvZndf YnVzIGludGVyZmFjZQotICovCi1zdGF0aWMgcGhhbmRsZV90IG9md19wY2lfZ2V0X25vZGUoZGV2 aWNlX3QgYnVzLCBkZXZpY2VfdCBkZXYpOwotCi0vKgotICogbG9jYWwgbWV0aG9kcwotICovCi0K LXN0YXRpYyBpbnQgb2Z3X3BjaV9ucmFuZ2VzKHBoYW5kbGVfdCBub2RlKTsKLXN0YXRpYyBpbnQg b2Z3X3BjaV9maWxsX3JhbmdlcyhwaGFuZGxlX3Qgbm9kZSwgc3RydWN0IG9md19wY2lfcmFuZ2Ug KnJhbmdlcyk7Ci0KLS8qCi0gKiBEcml2ZXIgbWV0aG9kcy4KLSAqLwotc3RhdGljIGRldmljZV9t ZXRob2RfdAlvZndfcGNpX21ldGhvZHNbXSA9IHsKLQkvKiBEZXZpY2UgaW50ZXJmYWNlICovCi0J REVWTUVUSE9EKGRldmljZV9hdHRhY2gsCW9md19wY2lfYXR0YWNoKSwKLQotCS8qIEJ1cyBpbnRl cmZhY2UgKi8KLQlERVZNRVRIT0QoYnVzX3ByaW50X2NoaWxkLAlidXNfZ2VuZXJpY19wcmludF9j aGlsZCksCi0JREVWTUVUSE9EKGJ1c19yZWFkX2l2YXIsCW9md19wY2lfcmVhZF9pdmFyKSwKLQlE RVZNRVRIT0QoYnVzX3NldHVwX2ludHIsCWJ1c19nZW5lcmljX3NldHVwX2ludHIpLAotCURFVk1F VEhPRChidXNfdGVhcmRvd25faW50ciwJYnVzX2dlbmVyaWNfdGVhcmRvd25faW50ciksCi0JREVW TUVUSE9EKGJ1c19hbGxvY19yZXNvdXJjZSwJb2Z3X3BjaV9hbGxvY19yZXNvdXJjZSksCi0JREVW TUVUSE9EKGJ1c19yZWxlYXNlX3Jlc291cmNlLAlvZndfcGNpX3JlbGVhc2VfcmVzb3VyY2UpLAot CURFVk1FVEhPRChidXNfYWN0aXZhdGVfcmVzb3VyY2UsCW9md19wY2lfYWN0aXZhdGVfcmVzb3Vy Y2UpLAotCURFVk1FVEhPRChidXNfZGVhY3RpdmF0ZV9yZXNvdXJjZSwJb2Z3X3BjaV9kZWFjdGl2 YXRlX3Jlc291cmNlKSwKLQlERVZNRVRIT0QoYnVzX2FkanVzdF9yZXNvdXJjZSwJb2Z3X3BjaV9h ZGp1c3RfcmVzb3VyY2UpLAotCi0JLyogcGNpYiBpbnRlcmZhY2UgKi8KLQlERVZNRVRIT0QocGNp Yl9tYXhzbG90cywJb2Z3X3BjaV9tYXhzbG90cyksCi0JREVWTUVUSE9EKHBjaWJfcm91dGVfaW50 ZXJydXB0LAlvZndfcGNpX3JvdXRlX2ludGVycnVwdCksCi0KLQkvKiBvZndfYnVzIGludGVyZmFj ZSAqLwotCURFVk1FVEhPRChvZndfYnVzX2dldF9ub2RlLCAgICAgb2Z3X3BjaV9nZXRfbm9kZSks Ci0KLQlERVZNRVRIT0RfRU5ECi19OwotCi1ERUZJTkVfQ0xBU1NfMChvZndfcGNpLCBvZndfcGNp X2RyaXZlciwgb2Z3X3BjaV9tZXRob2RzLCAwKTsKLQotaW50Ci1vZndfcGNpX2luaXQoZGV2aWNl X3QgZGV2KQotewotCXN0cnVjdAkJb2Z3X3BjaV9zb2Z0YyAqc2M7Ci0JcGhhbmRsZV90CW5vZGU7 Ci0JdV9pbnQzMl90CWJ1c3JhbmdlWzJdOwotCXN0cnVjdAkJb2Z3X3BjaV9yYW5nZSAqcnA7Ci0J aW50CQllcnJvcjsKLQotCW5vZGUgPSBvZndfYnVzX2dldF9ub2RlKGRldik7Ci0Jc2MgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7Ci0Jc2MtPnNjX2luaXRpYWxpemVkID0gMTsKLQotCWlmIChPRl9n ZXRlbmNwcm9wKG5vZGUsICJidXMtcmFuZ2UiLCBidXNyYW5nZSwgc2l6ZW9mKGJ1c3JhbmdlKSkg IT0gOCkKLQkJYnVzcmFuZ2VbMF0gPSAwOwotCi0Jc2MtPnNjX2RldiA9IGRldjsKLQlzYy0+c2Nf bm9kZSA9IG5vZGU7Ci0Jc2MtPnNjX2J1cyA9IGJ1c3JhbmdlWzBdOwotCi0JaWYgKHNjLT5zY19x dWlya3MgJiBPRldfUENJX1FVSVJLX1JBTkdFU19PTl9DSElMRFJFTikgewotCQlwaGFuZGxlX3Qg YzsKLQkJaW50IG4sIGk7Ci0JCQotCQlzYy0+c2NfbnJhbmdlID0gMDsKLQkJZm9yIChjID0gT0Zf Y2hpbGQobm9kZSk7IGMgIT0gMDsgYyA9IE9GX3BlZXIoYykpIHsKLQkJCW4gPSBvZndfcGNpX25y YW5nZXMoYyk7Ci0JCQlpZiAobiA+IDApCi0JCQkJc2MtPnNjX25yYW5nZSArPSBuOwotCQl9Ci0J CWlmIChzYy0+c2NfbnJhbmdlID09IDApCi0JCQlyZXR1cm4gKEVOWElPKTsKLQkJc2MtPnNjX3Jh bmdlID0gbWFsbG9jKHNjLT5zY19ucmFuZ2UgKiBzaXplb2Yoc2MtPnNjX3JhbmdlWzBdKSwKLQkJ ICAgIE1fREVWQlVGLCBNX1dBSVRPSyk7Ci0JCWkgPSAwOwotCQlmb3IgKGMgPSBPRl9jaGlsZChu b2RlKTsgYyAhPSAwOyBjID0gT0ZfcGVlcihjKSkgewotCQkJbiA9IG9md19wY2lfZmlsbF9yYW5n ZXMoYywgJnNjLT5zY19yYW5nZVtpXSk7Ci0JCQlpZiAobiA+IDApCi0JCQkJaSArPSBuOwotCQl9 Ci0JCUtBU1NFUlQoaSA9PSBzYy0+c2NfbnJhbmdlLCAoInJhbmdlIGNvdW50IG1pc21hdGNoIikp OwotCX0gZWxzZSB7Ci0JCXNjLT5zY19ucmFuZ2UgPSBvZndfcGNpX25yYW5nZXMobm9kZSk7Ci0J CWlmIChzYy0+c2NfbnJhbmdlIDw9IDApIHsKLQkJCWRldmljZV9wcmludGYoZGV2LCAiY291bGQg bm90IGdldCByYW5nZXNcbiIpOwotCQkJcmV0dXJuIChFTlhJTyk7Ci0JCX0KLQkJc2MtPnNjX3Jh bmdlID0gbWFsbG9jKHNjLT5zY19ucmFuZ2UgKiBzaXplb2Yoc2MtPnNjX3JhbmdlWzBdKSwKLQkJ ICAgIE1fREVWQlVGLCBNX1dBSVRPSyk7Ci0JCW9md19wY2lfZmlsbF9yYW5nZXMobm9kZSwgc2Mt PnNjX3JhbmdlKTsKLQl9Ci0JCQotCXNjLT5zY19pb19ybWFuLnJtX3R5cGUgPSBSTUFOX0FSUkFZ OwotCXNjLT5zY19pb19ybWFuLnJtX2Rlc2NyID0gIlBDSSBJL08gUG9ydHMiOwotCWVycm9yID0g cm1hbl9pbml0KCZzYy0+c2NfaW9fcm1hbik7Ci0JaWYgKGVycm9yKSB7Ci0JCWRldmljZV9wcmlu dGYoZGV2LCAicm1hbl9pbml0KCkgZmFpbGVkLiBlcnJvciA9ICVkXG4iLCBlcnJvcik7Ci0JCXJl dHVybiAoZXJyb3IpOwotCX0KLQotCXNjLT5zY19tZW1fcm1hbi5ybV90eXBlID0gUk1BTl9BUlJB WTsKLQlzYy0+c2NfbWVtX3JtYW4ucm1fZGVzY3IgPSAiUENJIE1lbW9yeSI7Ci0JZXJyb3IgPSBy bWFuX2luaXQoJnNjLT5zY19tZW1fcm1hbik7Ci0JaWYgKGVycm9yKSB7Ci0JCWRldmljZV9wcmlu dGYoZGV2LCAicm1hbl9pbml0KCkgZmFpbGVkLiBlcnJvciA9ICVkXG4iLCBlcnJvcik7Ci0JCXJl dHVybiAoZXJyb3IpOwotCX0KLQotCWZvciAocnAgPSBzYy0+c2NfcmFuZ2U7IHJwIDwgc2MtPnNj X3JhbmdlICsgc2MtPnNjX25yYW5nZSAmJgotCSAgICAgICBycC0+cGNpX2hpICE9IDA7IHJwKysp IHsKLQkJZXJyb3IgPSAwOwotCi0JCXN3aXRjaCAocnAtPnBjaV9oaSAmIE9GV19QQ0lfUEhZU19I SV9TUEFDRU1BU0spIHsKLQkJY2FzZSBPRldfUENJX1BIWVNfSElfU1BBQ0VfQ09ORklHOgotCQkJ YnJlYWs7Ci0JCWNhc2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNFX0lPOgotCQkJZXJyb3IgPSBybWFu X21hbmFnZV9yZWdpb24oJnNjLT5zY19pb19ybWFuLCBycC0+cGNpLAotCQkJICAgIHJwLT5wY2kg KyBycC0+c2l6ZSAtIDEpOwotCQkJYnJlYWs7Ci0JCWNhc2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNF X01FTTMyOgotCQljYXNlIE9GV19QQ0lfUEhZU19ISV9TUEFDRV9NRU02NDoKLQkJCWVycm9yID0g cm1hbl9tYW5hZ2VfcmVnaW9uKCZzYy0+c2NfbWVtX3JtYW4sIHJwLT5wY2ksCi0JCQkgICAgcnAt PnBjaSArIHJwLT5zaXplIC0gMSk7Ci0JCQlicmVhazsKLQkJfQotCi0JCWlmIChlcnJvcikgewot CQkJZGV2aWNlX3ByaW50ZihkZXYsIAotCQkJICAgICJybWFuX21hbmFnZV9yZWdpb24oJXgsICUj angsICUjangpIGZhaWxlZC4gIgotCQkJICAgICJlcnJvciA9ICVkXG4iLCBycC0+cGNpX2hpICYK LQkJCSAgICBPRldfUENJX1BIWVNfSElfU1BBQ0VNQVNLLCBycC0+cGNpLAotCQkJICAgIHJwLT5w Y2kgKyBycC0+c2l6ZSAtIDEsIGVycm9yKTsKLQkJCXJldHVybiAoZXJyb3IpOwotCQl9Ci0JfQot Ci0Jb2Z3X2J1c19zZXR1cF9paW5mbyhub2RlLCAmc2MtPnNjX3BjaV9paW5mbywgc2l6ZW9mKGNl bGxfdCkpOwotCi0JcmV0dXJuIChlcnJvcik7Ci19Ci0KLWludAotb2Z3X3BjaV9hdHRhY2goZGV2 aWNlX3QgZGV2KQotewotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKLQlpbnQgZXJyb3I7Ci0K LQlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKLQlpZiAoIXNjLT5zY19pbml0aWFsaXplZCkg ewotCQllcnJvciA9IG9md19wY2lfaW5pdChkZXYpOwotCQlpZiAoZXJyb3IpCi0JCQlyZXR1cm4g KGVycm9yKTsKLQl9Ci0KLQlkZXZpY2VfYWRkX2NoaWxkKGRldiwgInBjaSIsIC0xKTsKLQlyZXR1 cm4gKGJ1c19nZW5lcmljX2F0dGFjaChkZXYpKTsKLX0KLQotc3RhdGljIGludAotb2Z3X3BjaV9t YXhzbG90cyhkZXZpY2VfdCBkZXYpCi17Ci0KLQlyZXR1cm4gKFBDSV9TTE9UTUFYKTsKLX0KLQot c3RhdGljIGludAotb2Z3X3BjaV9yb3V0ZV9pbnRlcnJ1cHQoZGV2aWNlX3QgYnVzLCBkZXZpY2Vf dCBkZXYsIGludCBwaW4pCi17Ci0Jc3RydWN0IG9md19wY2lfc29mdGMgKnNjOwotCXN0cnVjdCBv ZndfcGNpX3JlZ2lzdGVyIHJlZzsKLQl1aW50MzJfdCBwaW50ciwgbWludHJbMl07Ci0JaW50IGlu dHJjZWxsczsKLQlwaGFuZGxlX3QgaXBhcmVudDsKLQotCXNjID0gZGV2aWNlX2dldF9zb2Z0Yyhi dXMpOwotCXBpbnRyID0gcGluOwotCi0JLyogRmFicmljYXRlIGltYXAgaW5mb3JtYXRpb24gaW4g Y2FzZSB0aGlzIGlzbid0IGFuIE9GVyBkZXZpY2UgKi8KLQliemVybygmcmVnLCBzaXplb2YocmVn KSk7Ci0JcmVnLnBoeXNfaGkgPSAocGNpX2dldF9idXMoZGV2KSA8PCBPRldfUENJX1BIWVNfSElf QlVTU0hJRlQpIHwKLQkgICAgKHBjaV9nZXRfc2xvdChkZXYpIDw8IE9GV19QQ0lfUEhZU19ISV9E RVZJQ0VTSElGVCkgfAotCSAgICAocGNpX2dldF9mdW5jdGlvbihkZXYpIDw8IE9GV19QQ0lfUEhZ U19ISV9GVU5DVElPTlNISUZUKTsKLQotCWludHJjZWxscyA9IG9md19idXNfbG9va3VwX2ltYXAo b2Z3X2J1c19nZXRfbm9kZShkZXYpLAotCSAgICAmc2MtPnNjX3BjaV9paW5mbywgJnJlZywgc2l6 ZW9mKHJlZyksICZwaW50ciwgc2l6ZW9mKHBpbnRyKSwKLQkgICAgbWludHIsIHNpemVvZihtaW50 ciksICZpcGFyZW50KTsKLQlpZiAoaW50cmNlbGxzKSB7Ci0JCXBpbnRyID0gb2Z3X2J1c19tYXBf aW50cihkZXYsIGlwYXJlbnQsIGludHJjZWxscywgbWludHIpOwotCQlyZXR1cm4gKHBpbnRyKTsK LQl9Ci0KLQkvKiBNYXliZSBpdCdzIGEgcmVhbCBpbnRlcnJ1cHQsIG5vdCBhbiBpbnRwaW4gKi8K LQlpZiAocGluID4gNCkKLQkJcmV0dXJuIChwaW4pOwotCi0JZGV2aWNlX3ByaW50ZihidXMsICJj b3VsZCBub3Qgcm91dGUgcGluICVkIGZvciBkZXZpY2UgJWQuJWRcbiIsCi0JICAgIHBpbiwgcGNp X2dldF9zbG90KGRldiksIHBjaV9nZXRfZnVuY3Rpb24oZGV2KSk7Ci0JcmV0dXJuIChQQ0lfSU5W QUxJRF9JUlEpOwotfQotCi1zdGF0aWMgaW50Ci1vZndfcGNpX3JlYWRfaXZhcihkZXZpY2VfdCBk ZXYsIGRldmljZV90IGNoaWxkLCBpbnQgd2hpY2gsIHVpbnRwdHJfdCAqcmVzdWx0KQotewotCXN0 cnVjdAlvZndfcGNpX3NvZnRjICpzYzsKLQotCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhkZXYpOwot Ci0Jc3dpdGNoICh3aGljaCkgewotCWNhc2UgUENJQl9JVkFSX0RPTUFJTjoKLQkJKnJlc3VsdCA9 IGRldmljZV9nZXRfdW5pdChkZXYpOwotCQlyZXR1cm4gKDApOwotCWNhc2UgUENJQl9JVkFSX0JV UzoKLQkJKnJlc3VsdCA9IHNjLT5zY19idXM7Ci0JCXJldHVybiAoMCk7Ci0JfQotCi0JcmV0dXJu IChFTk9FTlQpOwotfQotCi1zdGF0aWMgc3RydWN0IHJlc291cmNlICoKLW9md19wY2lfYWxsb2Nf cmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAqcmlk LAotICAgIHJtYW5fcmVzX3Qgc3RhcnQsIHJtYW5fcmVzX3QgZW5kLCBybWFuX3Jlc190IGNvdW50 LCB1X2ludCBmbGFncykKLXsKLQlzdHJ1Y3QJCQlvZndfcGNpX3NvZnRjICpzYzsKLQlzdHJ1Y3QJ CQlyZXNvdXJjZSAqcnY7Ci0Jc3RydWN0CQkJcm1hbiAqcm07Ci0JaW50CQkJbmVlZGFjdGl2YXRl OwotCi0JbmVlZGFjdGl2YXRlID0gZmxhZ3MgJiBSRl9BQ1RJVkU7Ci0JZmxhZ3MgJj0gflJGX0FD VElWRTsKLQotCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhidXMpOwotCi0Jc3dpdGNoICh0eXBlKSB7 Ci0JY2FzZSBTWVNfUkVTX01FTU9SWToKLQkJcm0gPSAmc2MtPnNjX21lbV9ybWFuOwotCQlicmVh azsKLQotCWNhc2UgU1lTX1JFU19JT1BPUlQ6Ci0JCXJtID0gJnNjLT5zY19pb19ybWFuOwotCQli cmVhazsKLQotCWNhc2UgU1lTX1JFU19JUlE6Ci0JCXJldHVybiAoYnVzX2FsbG9jX3Jlc291cmNl KGJ1cywgdHlwZSwgcmlkLCBzdGFydCwgZW5kLCBjb3VudCwKLQkJICAgIGZsYWdzKSk7Ci0KLQlk ZWZhdWx0OgotCQlkZXZpY2VfcHJpbnRmKGJ1cywgInVua25vd24gcmVzb3VyY2UgcmVxdWVzdCBm cm9tICVzXG4iLAotCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZCkpOwotCQlyZXR1cm4g KE5VTEwpOwotCX0KLQotCXJ2ID0gcm1hbl9yZXNlcnZlX3Jlc291cmNlKHJtLCBzdGFydCwgZW5k LCBjb3VudCwgZmxhZ3MsIGNoaWxkKTsKLQlpZiAocnYgPT0gTlVMTCkgewotCQlkZXZpY2VfcHJp bnRmKGJ1cywgImZhaWxlZCB0byByZXNlcnZlIHJlc291cmNlIGZvciAlc1xuIiwKLQkJICAgIGRl dmljZV9nZXRfbmFtZXVuaXQoY2hpbGQpKTsKLQkJcmV0dXJuIChOVUxMKTsKLQl9Ci0KLQlybWFu X3NldF9yaWQocnYsICpyaWQpOwotCi0JaWYgKG5lZWRhY3RpdmF0ZSkgewotCQlpZiAoYnVzX2Fj dGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBlLCAqcmlkLCBydikgIT0gMCkgewotCQkJZGV2aWNl X3ByaW50ZihidXMsCi0JCQkgICAgImZhaWxlZCB0byBhY3RpdmF0ZSByZXNvdXJjZSBmb3IgJXNc biIsCi0JCQkgICAgZGV2aWNlX2dldF9uYW1ldW5pdChjaGlsZCkpOwotCQkJcm1hbl9yZWxlYXNl X3Jlc291cmNlKHJ2KTsKLQkJCXJldHVybiAoTlVMTCk7Ci0JCX0KLQl9Ci0KLQlyZXR1cm4gKHJ2 KTsKLX0KLQotc3RhdGljIGludAotb2Z3X3BjaV9yZWxlYXNlX3Jlc291cmNlKGRldmljZV90IGJ1 cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBpbnQgcmlkLAotICAgIHN0cnVjdCByZXNvdXJj ZSAqcmVzKQotewotCWlmIChybWFuX2dldF9mbGFncyhyZXMpICYgUkZfQUNUSVZFKSB7Ci0JCWlu dCBlcnJvciA9IGJ1c19kZWFjdGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBlLCByaWQsIHJlcyk7 Ci0JCWlmIChlcnJvcikKLQkJCXJldHVybiBlcnJvcjsKLQl9Ci0KLQlyZXR1cm4gKHJtYW5fcmVs ZWFzZV9yZXNvdXJjZShyZXMpKTsKLX0KLQotc3RhdGljIGludAotb2Z3X3BjaV9hY3RpdmF0ZV9y ZXNvdXJjZShkZXZpY2VfdCBidXMsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50IHJpZCwK LSAgICBzdHJ1Y3QgcmVzb3VyY2UgKnJlcykKLXsKLQlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7 Ci0Jdm9pZAkqcDsKLQotCXNjID0gZGV2aWNlX2dldF9zb2Z0YyhidXMpOwotCi0JaWYgKHR5cGUg PT0gU1lTX1JFU19JUlEpIHsKLQkJcmV0dXJuIChidXNfYWN0aXZhdGVfcmVzb3VyY2UoYnVzLCB0 eXBlLCByaWQsIHJlcykpOwotCX0KLQlpZiAodHlwZSA9PSBTWVNfUkVTX01FTU9SWSB8fCB0eXBl ID09IFNZU19SRVNfSU9QT1JUKSB7Ci0JCXN0cnVjdCBvZndfcGNpX3JhbmdlICpycDsKLQkJdm1f b2Zmc2V0X3Qgc3RhcnQ7Ci0JCWludCBzcGFjZTsKLQotCQlzdGFydCA9ICh2bV9vZmZzZXRfdCly bWFuX2dldF9zdGFydChyZXMpOwotCi0JCS8qCi0JCSAqIE1hcCB0aGlzIHRocm91Z2ggdGhlIHJh bmdlcyBsaXN0Ci0JCSAqLwotCQlmb3IgKHJwID0gc2MtPnNjX3JhbmdlOyBycCA8IHNjLT5zY19y YW5nZSArIHNjLT5zY19ucmFuZ2UgJiYKLQkJICAgICAgIHJwLT5wY2lfaGkgIT0gMDsgcnArKykg ewotCQkJaWYgKHN0YXJ0IDwgcnAtPnBjaSB8fCBzdGFydCA+PSBycC0+cGNpICsgcnAtPnNpemUp Ci0JCQkJY29udGludWU7Ci0KLQkJCXN3aXRjaCAocnAtPnBjaV9oaSAmIE9GV19QQ0lfUEhZU19I SV9TUEFDRU1BU0spIHsKLQkJCWNhc2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNFX0lPOgotCQkJCXNw YWNlID0gU1lTX1JFU19JT1BPUlQ7Ci0JCQkJYnJlYWs7Ci0JCQljYXNlIE9GV19QQ0lfUEhZU19I SV9TUEFDRV9NRU0zMjoKLQkJCWNhc2UgT0ZXX1BDSV9QSFlTX0hJX1NQQUNFX01FTTY0OgotCQkJ CXNwYWNlID0gU1lTX1JFU19NRU1PUlk7Ci0JCQkJYnJlYWs7Ci0JCQlkZWZhdWx0OgotCQkJCXNw YWNlID0gLTE7Ci0JCQl9Ci0KLQkJCWlmICh0eXBlID09IHNwYWNlKSB7Ci0JCQkJc3RhcnQgKz0g KHJwLT5ob3N0IC0gcnAtPnBjaSk7Ci0JCQkJYnJlYWs7Ci0JCQl9Ci0JCX0KLQotCQlpZiAoYm9v dHZlcmJvc2UpCi0JCQlwcmludGYoIm9md19wY2kgbWFwZGV2OiBzdGFydCAlengsIGxlbiAlbGRc biIsIHN0YXJ0LAotCQkJICAgIHJtYW5fZ2V0X3NpemUocmVzKSk7Ci0KLQkJcCA9IHBtYXBfbWFw ZGV2KHN0YXJ0LCAodm1fc2l6ZV90KXJtYW5fZ2V0X3NpemUocmVzKSk7Ci0JCWlmIChwID09IE5V TEwpCi0JCQlyZXR1cm4gKEVOT01FTSk7Ci0KLQkJcm1hbl9zZXRfdmlydHVhbChyZXMsIHApOwot CQlybWFuX3NldF9idXN0YWcocmVzLCAmYnNfbGVfdGFnKTsKLQkJcm1hbl9zZXRfYnVzaGFuZGxl KHJlcywgKHVfbG9uZylwKTsKLQl9Ci0KLQlyZXR1cm4gKHJtYW5fYWN0aXZhdGVfcmVzb3VyY2Uo cmVzKSk7Ci19Ci0KLXN0YXRpYyBpbnQKLW9md19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZShkZXZp Y2VfdCBidXMsIGRldmljZV90IGNoaWxkLCBpbnQgdHlwZSwgaW50IHJpZCwKLSAgICBzdHJ1Y3Qg cmVzb3VyY2UgKnJlcykKLXsKLQkvKgotCSAqIElmIHRoaXMgaXMgYSBtZW1vcnkgcmVzb3VyY2Us IHVubWFwIGl0LgotCSAqLwotCWlmICgodHlwZSA9PSBTWVNfUkVTX01FTU9SWSkgfHwgKHR5cGUg PT0gU1lTX1JFU19JT1BPUlQpKSB7Ci0JCXVfaW50MzJfdCBwc2l6ZTsKLQotCQlwc2l6ZSA9IHJt YW5fZ2V0X3NpemUocmVzKTsKLQkJcG1hcF91bm1hcGRldigodm1fb2Zmc2V0X3Qpcm1hbl9nZXRf dmlydHVhbChyZXMpLCBwc2l6ZSk7Ci0JfQotCi0JcmV0dXJuIChybWFuX2RlYWN0aXZhdGVfcmVz b3VyY2UocmVzKSk7Ci19Ci0KLXN0YXRpYyBpbnQKLW9md19wY2lfYWRqdXN0X3Jlc291cmNlKGRl dmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLAotICAgIHN0cnVjdCByZXNvdXJj ZSAqcmVzLCBybWFuX3Jlc190IHN0YXJ0LCBybWFuX3Jlc190IGVuZCkKLXsKLQlzdHJ1Y3Qgcm1h biAqcm0gPSBOVUxMOwotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYyA9IGRldmljZV9nZXRfc29m dGMoYnVzKTsKLQotCUtBU1NFUlQoIShybWFuX2dldF9mbGFncyhyZXMpICYgUkZfQUNUSVZFKSwK LQkgICAgKCJhY3RpdmUgcmVzb3VyY2VzIGNhbm5vdCBiZSBhZGp1c3RlZCIpKTsKLQlpZiAocm1h bl9nZXRfZmxhZ3MocmVzKSAmIFJGX0FDVElWRSkKLQkJcmV0dXJuIChFSU5WQUwpOwotCi0Jc3dp dGNoICh0eXBlKSB7Ci0JY2FzZSBTWVNfUkVTX01FTU9SWToKLQkJcm0gPSAmc2MtPnNjX21lbV9y bWFuOwotCQlicmVhazsKLQljYXNlIFNZU19SRVNfSU9QT1JUOgotCQlybSA9ICZzYy0+c2NfaW9f cm1hbjsKLQkJYnJlYWs7Ci0JZGVmYXVsdDoKLQkJcmV0dXJuIChFTlhJTyk7Ci0JfQotCi0JaWYg KCFybWFuX2lzX3JlZ2lvbl9tYW5hZ2VyKHJlcywgcm0pKQotCQlyZXR1cm4gKEVJTlZBTCk7Ci0K LQlyZXR1cm4gKHJtYW5fYWRqdXN0X3Jlc291cmNlKHJlcywgc3RhcnQsIGVuZCkpOwotfQotCQot Ci1zdGF0aWMgcGhhbmRsZV90Ci1vZndfcGNpX2dldF9ub2RlKGRldmljZV90IGJ1cywgZGV2aWNl X3QgZGV2KQotewotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKLQotCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhidXMpOwotCS8qIFdlIG9ubHkgaGF2ZSBvbmUgY2hpbGQsIHRoZSBQQ0kgYnVzLCB3 aGljaCBuZWVkcyBvdXIgb3duIG5vZGUuICovCi0KLQlyZXR1cm4gKHNjLT5zY19ub2RlKTsKLX0K LQotc3RhdGljIGludAotb2Z3X3BjaV9ucmFuZ2VzKHBoYW5kbGVfdCBub2RlKQotewotCWludCBo b3N0X2FkZHJlc3NfY2VsbHMgPSAxLCBwY2lfYWRkcmVzc19jZWxscyA9IDMsIHNpemVfY2VsbHMg PSAyOwotCXNzaXplX3QgbmJhc2VfcmFuZ2VzOwotCi0JT0ZfZ2V0ZW5jcHJvcChPRl9wYXJlbnQo bm9kZSksICIjYWRkcmVzcy1jZWxscyIsICZob3N0X2FkZHJlc3NfY2VsbHMsCi0JICAgIHNpemVv Zihob3N0X2FkZHJlc3NfY2VsbHMpKTsKLQlPRl9nZXRlbmNwcm9wKG5vZGUsICIjYWRkcmVzcy1j ZWxscyIsICZwY2lfYWRkcmVzc19jZWxscywKLQkgICAgc2l6ZW9mKHBjaV9hZGRyZXNzX2NlbGxz KSk7Ci0JT0ZfZ2V0ZW5jcHJvcChub2RlLCAiI3NpemUtY2VsbHMiLCAmc2l6ZV9jZWxscywgc2l6 ZW9mKHNpemVfY2VsbHMpKTsKLQotCW5iYXNlX3JhbmdlcyA9IE9GX2dldHByb3BsZW4obm9kZSwg InJhbmdlcyIpOwotCWlmIChuYmFzZV9yYW5nZXMgPD0gMCkKLQkJcmV0dXJuICgtMSk7Ci0KLQly ZXR1cm4gKG5iYXNlX3JhbmdlcyAvIHNpemVvZihjZWxsX3QpIC8KLQkgICAgKHBjaV9hZGRyZXNz X2NlbGxzICsgaG9zdF9hZGRyZXNzX2NlbGxzICsgc2l6ZV9jZWxscykpOwotfQotCi1zdGF0aWMg aW50Ci1vZndfcGNpX2ZpbGxfcmFuZ2VzKHBoYW5kbGVfdCBub2RlLCBzdHJ1Y3Qgb2Z3X3BjaV9y YW5nZSAqcmFuZ2VzKQotewotCWludCBob3N0X2FkZHJlc3NfY2VsbHMgPSAxLCBwY2lfYWRkcmVz c19jZWxscyA9IDMsIHNpemVfY2VsbHMgPSAyOwotCWNlbGxfdCAqYmFzZV9yYW5nZXM7Ci0Jc3Np emVfdCBuYmFzZV9yYW5nZXM7Ci0JaW50IG5yYW5nZXM7Ci0JaW50IGksIGosIGs7Ci0KLQlPRl9n ZXRlbmNwcm9wKE9GX3BhcmVudChub2RlKSwgIiNhZGRyZXNzLWNlbGxzIiwgJmhvc3RfYWRkcmVz c19jZWxscywKLQkgICAgc2l6ZW9mKGhvc3RfYWRkcmVzc19jZWxscykpOwotCU9GX2dldGVuY3By b3Aobm9kZSwgIiNhZGRyZXNzLWNlbGxzIiwgJnBjaV9hZGRyZXNzX2NlbGxzLAotCSAgICBzaXpl b2YocGNpX2FkZHJlc3NfY2VsbHMpKTsKLQlPRl9nZXRlbmNwcm9wKG5vZGUsICIjc2l6ZS1jZWxs cyIsICZzaXplX2NlbGxzLCBzaXplb2Yoc2l6ZV9jZWxscykpOwotCi0JbmJhc2VfcmFuZ2VzID0g T0ZfZ2V0cHJvcGxlbihub2RlLCAicmFuZ2VzIik7Ci0JaWYgKG5iYXNlX3JhbmdlcyA8PSAwKQot CQlyZXR1cm4gKC0xKTsKLQlucmFuZ2VzID0gbmJhc2VfcmFuZ2VzIC8gc2l6ZW9mKGNlbGxfdCkg LwotCSAgICAocGNpX2FkZHJlc3NfY2VsbHMgKyBob3N0X2FkZHJlc3NfY2VsbHMgKyBzaXplX2Nl bGxzKTsKLQotCWJhc2VfcmFuZ2VzID0gbWFsbG9jKG5iYXNlX3JhbmdlcywgTV9ERVZCVUYsIE1f V0FJVE9LKTsKLQlPRl9nZXRlbmNwcm9wKG5vZGUsICJyYW5nZXMiLCBiYXNlX3JhbmdlcywgbmJh c2VfcmFuZ2VzKTsKLQotCWZvciAoaSA9IDAsIGogPSAwOyBpIDwgbnJhbmdlczsgaSsrKSB7Ci0J CXJhbmdlc1tpXS5wY2lfaGkgPSBiYXNlX3Jhbmdlc1tqKytdOwotCQlyYW5nZXNbaV0ucGNpID0g MDsKLQkJZm9yIChrID0gMDsgayA8IHBjaV9hZGRyZXNzX2NlbGxzIC0gMTsgaysrKSB7Ci0JCQly YW5nZXNbaV0ucGNpIDw8PSAzMjsKLQkJCXJhbmdlc1tpXS5wY2kgfD0gYmFzZV9yYW5nZXNbaisr XTsKLQkJfQotCQlyYW5nZXNbaV0uaG9zdCA9IDA7Ci0JCWZvciAoayA9IDA7IGsgPCBob3N0X2Fk ZHJlc3NfY2VsbHM7IGsrKykgewotCQkJcmFuZ2VzW2ldLmhvc3QgPDw9IDMyOwotCQkJcmFuZ2Vz W2ldLmhvc3QgfD0gYmFzZV9yYW5nZXNbaisrXTsKLQkJfQotCQlyYW5nZXNbaV0uc2l6ZSA9IDA7 Ci0JCWZvciAoayA9IDA7IGsgPCBzaXplX2NlbGxzOyBrKyspIHsKLQkJCXJhbmdlc1tpXS5zaXpl IDw8PSAzMjsKLQkJCXJhbmdlc1tpXS5zaXplIHw9IGJhc2VfcmFuZ2VzW2orK107Ci0JCX0KLQl9 Ci0KLQlmcmVlKGJhc2VfcmFuZ2VzLCBNX0RFVkJVRik7Ci0JcmV0dXJuIChucmFuZ2VzKTsKLX0K LQpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2VycGMvb2Z3L29md19wY2kuaCBiL3N5cy9wb3dlcnBjL29m dy9vZndfcGNpLmgKZGVsZXRlZCBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IGRiODgzZDQuLjAwMDAw MDAKLS0tIGEvc3lzL3Bvd2VycGMvb2Z3L29md19wY2kuaAorKysgL2Rldi9udWxsCkBAIC0xLDc0 ICswLDAgQEAKLS8qLQotICogQ29weXJpZ2h0IChjKSAyMDExIE5hdGhhbiBXaGl0ZWhvcm4KLSAq IEFsbCByaWdodHMgcmVzZXJ2ZWQuCi0gKgotICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBz b3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRob3V0Ci0gKiBtb2RpZmljYXRpb24s IGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKLSAq IGFyZSBtZXQ6Ci0gKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRh aW4gdGhlIGFib3ZlIGNvcHlyaWdodAotICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0 aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgotICogMi4gUmVkaXN0cmlidXRpb25z IGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKLSAqICAg IG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xh aW1lciBpbiB0aGUKLSAqICAgIGRvY3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBw cm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCi0gKgotICogVEhJUyBTT0ZUV0FSRSBJUyBQ Uk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAotICog QU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElN SVRFRCBUTywgVEhFCi0gKiBJTVBMSUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFO RCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQotICogQVJFIERJU0NMQUlNRUQuICBJ TiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKLSAq IEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZ LCBPUiBDT05TRVFVRU5USUFMCi0gKiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRF RCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09EUwotICogT1IgU0VSVklDRVM7IExP U1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCi0g KiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIg SU4gQ09OVFJBQ1QsIFNUUklDVAotICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVH TElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5ZIFdBWQotICogT1VUIE9GIFRIRSBV U0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBP RgotICogU1VDSCBEQU1BR0UuCi0gKgotICogJEZyZWVCU0QkCi0gKi8KLQotI2lmbmRlZiBQT1dF UlBDX09GV19PRldfUENJX0gKLSNkZWZpbmUgUE9XRVJQQ19PRldfT0ZXX1BDSV9ICi0KLS8qCi0g KiBFeHBvcnQgY2xhc3MgZGVmaW5pdGlvbiBmb3IgaW5oZXJpdGFuY2UgcHVycG9zZXMKLSAqLwot REVDTEFSRV9DTEFTUyhvZndfcGNpX2RyaXZlcik7Ci0KLXN0cnVjdCBvZndfcGNpX3JhbmdlIHsK LQl1aW50MzJfdAlwY2lfaGk7Ci0JdWludDY0X3QJcGNpOwotCXVpbnQ2NF90CWhvc3Q7Ci0JdWlu dDY0X3QJc2l6ZTsKLX07Ci0KLS8qCi0gKiBRdWlya3MgZm9yIHNvbWUgYWRhcHRlcnMKLSAqLwot ZW51bSB7Ci0JT0ZXX1BDSV9RVUlSS19SQU5HRVNfT05fQ0hJTERSRU4gPSAxLAotfTsKLQotc3Ry dWN0IG9md19wY2lfc29mdGMgewotCWRldmljZV90CQlzY19kZXY7Ci0JcGhhbmRsZV90CQlzY19u b2RlOwotCWludAkJCXNjX2J1czsKLQlpbnQJCQlzY19pbml0aWFsaXplZDsKLQotCWludAkJCXNj X3F1aXJrczsKLQotCXN0cnVjdCBvZndfcGNpX3JhbmdlCSpzY19yYW5nZTsKLQlpbnQJCQlzY19u cmFuZ2U7Ci0KLQlzdHJ1Y3Qgcm1hbgkJc2NfaW9fcm1hbjsKLQlzdHJ1Y3Qgcm1hbgkJc2NfbWVt X3JtYW47Ci0JYnVzX3NwYWNlX3RhZ190CQlzY19tZW10OwotCWJ1c19kbWFfdGFnX3QJCXNjX2Rt YXQ7Ci0KLQlzdHJ1Y3Qgb2Z3X2J1c19paW5mbyAgICBzY19wY2lfaWluZm87Ci19OwotCi1pbnQg b2Z3X3BjaV9pbml0KGRldmljZV90IGRldik7Ci1pbnQgb2Z3X3BjaV9hdHRhY2goZGV2aWNlX3Qg ZGV2KTsKLQotI2VuZGlmIC8vIFBPV0VSUENfT0ZXX09GV19QQ0lfSAotCmRpZmYgLS1naXQgYS9z eXMvcG93ZXJwYy9vZncvb2Z3X3BjaWJfcGNpLmMgYi9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaWJf cGNpLmMKaW5kZXggODIzZjdjOS4uMWMxMDVmYiAxMDA2NDQKLS0tIGEvc3lzL3Bvd2VycGMvb2Z3 L29md19wY2liX3BjaS5jCisrKyBiL3N5cy9wb3dlcnBjL29mdy9vZndfcGNpYl9wY2kuYwpAQCAt MzYsOSArMzYsOSBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8c3lzL2tlcm5l bC5oPgogCiAjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgotI2luY2x1ZGUgPGRldi9vZncv b2Z3X3BjaS5oPgogI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgogI2luY2x1ZGUgPGRldi9v Zncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAKICNpbmNs dWRlIDxkZXYvcGNpL3BjaXZhci5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+CmRpZmYg LS1naXQgYS9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaWJ1cy5jIGIvc3lzL3Bvd2VycGMvb2Z3L29m d19wY2lidXMuYwppbmRleCBjZGUzYzc0Li4xMmFhMjI0IDEwMDY0NAotLS0gYS9zeXMvcG93ZXJw Yy9vZncvb2Z3X3BjaWJ1cy5jCisrKyBiL3N5cy9wb3dlcnBjL29mdy9vZndfcGNpYnVzLmMKQEAg LTU0LDggKzU0LDYgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgInBjaWJfaWYu aCIKICNpbmNsdWRlICJwY2lfaWYuaCIKIAotdHlwZWRlZiB1aW50MzJfdCBvZndfcGNpX2ludHJf dDsKLQogLyogTWV0aG9kcyAqLwogc3RhdGljIGRldmljZV9wcm9iZV90IG9md19wY2lidXNfcHJv YmU7CiBzdGF0aWMgZGV2aWNlX2F0dGFjaF90IG9md19wY2lidXNfYXR0YWNoOwpkaWZmIC0tZ2l0 IGEvc3lzL3Bvd2VycGMvb2Z3L29md19wY2lidXMuaCBiL3N5cy9wb3dlcnBjL29mdy9vZndfcGNp YnVzLmgKaW5kZXggYzdiODJkNy4uZmFkNGQ2NiAxMDA2NDQKLS0tIGEvc3lzL3Bvd2VycGMvb2Z3 L29md19wY2lidXMuaAorKysgYi9zeXMvcG93ZXJwYy9vZncvb2Z3X3BjaWJ1cy5oCkBAIC0zMyw2 ICszMyw3IEBACiAjaW5jbHVkZSA8c3lzL3BjaWlvLmg+CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29m d19idXMuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogI2luY2x1ZGUgPGRl di9vZncvb2Z3X3BjaS5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAKZGlmZiAtLWdp dCBhL3N5cy9wb3dlcnBjL29mdy9vZndfc3lzY29ucy5jIGIvc3lzL3Bvd2VycGMvb2Z3L29md19z eXNjb25zLmMKaW5kZXggYjc2NjQ4NS4uYjQyZjE0MiAxMDA2NDQKLS0tIGEvc3lzL3Bvd2VycGMv b2Z3L29md19zeXNjb25zLmMKKysrIGIvc3lzL3Bvd2VycGMvb2Z3L29md19zeXNjb25zLmMKQEAg LTUzLDYgKzUzLDcgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8ZGV2L29m dy9vcGVuZmlybS5oPgogI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgorI2luY2x1ZGUgPGRl di9vZncvb2Z3X2J1c19zdWJyLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAjaW5j bHVkZSA8cG93ZXJwYy9vZncvb2Z3X3N5c2NvbnMuaD4KIApkaWZmIC0tZ2l0IGEvc3lzL3Bvd2Vy cGMvcG93ZXJtYWMvY3BjaHQuYyBiL3N5cy9wb3dlcnBjL3Bvd2VybWFjL2NwY2h0LmMKaW5kZXgg NzY1ZDk0Ni4uNzM3ZTg3MiAxMDA2NDQKLS0tIGEvc3lzL3Bvd2VycGMvcG93ZXJtYWMvY3BjaHQu YworKysgYi9zeXMvcG93ZXJwYy9wb3dlcm1hYy9jcGNodC5jCkBAIC0zNiw3ICszNiw2IEBAIF9f RkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMvcm1hbi5oPgogCiAjaW5jbHVkZSA8 ZGV2L29mdy9vcGVuZmlybS5oPgotI2luY2x1ZGUgPGRldi9vZncvb2Z3X3BjaS5oPgogCiAjaW5j bHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5oPgpAQCAt NTEsNyArNTAsNyBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxkZXYvb2Z3 L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgotI2luY2x1ZGUg PHBvd2VycGMvb2Z3L29md19wY2kuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAog I2luY2x1ZGUgPHZtL3ZtLmg+CiAjaW5jbHVkZSA8dm0vcG1hcC5oPgpkaWZmIC0tZ2l0IGEvc3lz L3Bvd2VycGMvcG93ZXJtYWMvZ3JhY2tsZS5jIGIvc3lzL3Bvd2VycGMvcG93ZXJtYWMvZ3JhY2ts ZS5jCmluZGV4IDk1ZDU5YTEuLmYwOTI4ZjMgMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL3Bvd2Vy bWFjL2dyYWNrbGUuYworKysgYi9zeXMvcG93ZXJwYy9wb3dlcm1hYy9ncmFja2xlLmMKQEAgLTM3 LDkgKzM3LDkgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9wcm9jLmg+ CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndf cGNpLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9v ZndfYnVzX3N1YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUg PGRldi9wY2kvcGNpdmFyLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KQEAgLTUyLDcg KzUyLDYgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8c3lzL3JtYW4uaD4K IAotI2luY2x1ZGUgPHBvd2VycGMvb2Z3L29md19wY2kuaD4KICNpbmNsdWRlIDxwb3dlcnBjL3Bv d2VybWFjL2dyYWNrbGV2YXIuaD4KIAogI2luY2x1ZGUgPHZtL3ZtLmg+CmRpZmYgLS1naXQgYS9z eXMvcG93ZXJwYy9wb3dlcm1hYy91bmlub3J0aC5jIGIvc3lzL3Bvd2VycGMvcG93ZXJtYWMvdW5p bm9ydGguYwppbmRleCBlMzRjOWQ4Li4zNTc5MjRhIDEwMDY0NAotLS0gYS9zeXMvcG93ZXJwYy9w b3dlcm1hYy91bmlub3J0aC5jCisrKyBiL3N5cy9wb3dlcnBjL3Bvd2VybWFjL3VuaW5vcnRoLmMK QEAgLTMzLDkgKzMzLDkgQEAKICNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiAKICNpbmNsdWRlIDxk ZXYvb2Z3L29wZW5maXJtLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAjaW5jbHVk ZSA8ZGV2L29mdy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4K KyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFy Lmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KZGlmZiAtLWdpdCBhL3N5cy9wb3dlcnBj L3Bvd2VybWFjL3VuaW5vcnRocGNpLmMgYi9zeXMvcG93ZXJwYy9wb3dlcm1hYy91bmlub3J0aHBj aS5jCmluZGV4IDlkYTA2ZmYuLjVjYjIxYzEgMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL3Bvd2Vy bWFjL3VuaW5vcnRocGNpLmMKKysrIGIvc3lzL3Bvd2VycGMvcG93ZXJtYWMvdW5pbm9ydGhwY2ku YwpAQCAtMzQsOSArMzQsOSBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8c3lz L2tlcm5lbC5oPgogCiAjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgotI2luY2x1ZGUgPGRl di9vZncvb2Z3X3BjaS5oPgogI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5oPgogI2luY2x1ZGUg PGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAK ICNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+ CkBAIC00OSw3ICs0OSw2IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKIAogI2luY2x1ZGUgPHN5 cy9ybWFuLmg+CiAKLSNpbmNsdWRlIDxwb3dlcnBjL29mdy9vZndfcGNpLmg+CiAjaW5jbHVkZSA8 cG93ZXJwYy9wb3dlcm1hYy91bmlub3J0aHZhci5oPgogCiAjaW5jbHVkZSA8dm0vdm0uaD4KZGlm ZiAtLWdpdCBhL3N5cy9wb3dlcnBjL3Bvd2VybWFjL3VuaW5vcnRodmFyLmggYi9zeXMvcG93ZXJw Yy9wb3dlcm1hYy91bmlub3J0aHZhci5oCmluZGV4IGUwODQ3OGQuLmVmZTE2OWMgMTAwNjQ0Ci0t LSBhL3N5cy9wb3dlcnBjL3Bvd2VybWFjL3VuaW5vcnRodmFyLmgKKysrIGIvc3lzL3Bvd2VycGMv cG93ZXJtYWMvdW5pbm9ydGh2YXIuaApAQCAtMzAsNyArMzAsNiBAQAogCiAjaW5jbHVkZSA8ZGV2 L29mdy9vZndfYnVzX3N1YnIuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KLSNpbmNs dWRlIDxwb3dlcnBjL29mdy9vZndfcGNpLmg+CiAKIHN0cnVjdCB1bmlub3J0aF9zb2Z0YyB7CiAJ c3RydWN0IG9md19wY2lfc29mdGMJcGNpX3NjOwpkaWZmIC0tZ2l0IGEvc3lzL3Bvd2VycGMvcHNl cmllcy9ydGFzX3BjaS5jIGIvc3lzL3Bvd2VycGMvcHNlcmllcy9ydGFzX3BjaS5jCmluZGV4IGJi NzJiNzEuLjEzNDhmYzggMTAwNjQ0Ci0tLSBhL3N5cy9wb3dlcnBjL3BzZXJpZXMvcnRhc19wY2ku YworKysgYi9zeXMvcG93ZXJwYy9wc2VyaWVzL3J0YXNfcGNpLmMKQEAgLTM0LDkgKzM0LDkgQEAg X19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KIAogI2luY2x1 ZGUgPGRldi9vZncvb3BlbmZpcm0uaD4KLSNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KICNp bmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXNfc3Vi ci5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X3BjaS5oPgogCiAjaW5jbHVkZSA8ZGV2L3BjaS9w Y2l2YXIuaD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5oPgpAQCAtNTMsNyArNTMsNiBAQCBf X0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8dm0vdm0uaD4KICNpbmNsdWRlIDx2bS9w bWFwLmg+CiAKLSNpbmNsdWRlIDxwb3dlcnBjL29mdy9vZndfcGNpLmg+CiAjaW5jbHVkZSA8cG93 ZXJwYy9wc2VyaWVzL3BscGFyX2lvbW11Lmg+CiAKICNpbmNsdWRlICJwY2liX2lmLmgiCmRpZmYg LS1naXQgYS9zeXMvc3BhcmM2NC9lYnVzL2VidXMuYyBiL3N5cy9zcGFyYzY0L2VidXMvZWJ1cy5j CmluZGV4IGE1M2IyMGIuLjZmNzA1YWQgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L2VidXMvZWJ1 cy5jCisrKyBiL3N5cy9zcGFyYzY0L2VidXMvZWJ1cy5jCkBAIC03NCw2ICs3NCw3IEBAIF9fRkJT RElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRl IDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogI2luY2x1ZGUgPGRldi9vZncvb3BlbmZpcm0uaD4K KyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+ CiAjaWZuZGVmIFNVTjRWCkBAIC04NSw4ICs4Niw2IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsK ICNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+ CiAKLSNpbmNsdWRlIDxzcGFyYzY0L3BjaS9vZndfcGNpLmg+Ci0KIC8qCiAgKiBUaGUgcmVnaXN0 ZXIsIGludGVycnVwdCBtYXAgYW5kIGZvciB0aGUgUENJIHZhcmlhbnQgYWxzbyB0aGUgcmFuZ2Vz CiAgKiBwcm9wZXJ0aWVzIGFyZSBpZGVudGljYWwgdG8gdGhlIElTQSBvbmVzLgpkaWZmIC0tZ2l0 IGEvc3lzL3NwYXJjNjQvaXNhL2lzYS5jIGIvc3lzL3NwYXJjNjQvaXNhL2lzYS5jCmluZGV4IDc0 NjI3YzUuLmNlY2NiOGEgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L2lzYS9pc2EuYworKysgYi9z eXMvc3BhcmM2NC9pc2EvaXNhLmMKQEAgLTQ0LDEzICs0NCwxNCBAQCBfX0ZCU0RJRCgiJEZyZWVC U0QkIik7CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3 L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KKyNpbmNsdWRl IDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvcmVzb3VyY2UuaD4KIAog I2luY2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4K IAotI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2kuaD4KICNpbmNsdWRlIDxzcGFyYzY0L2lz YS9vZndfaXNhLmg+CiAKIC8qIFRoZXJlIGNhbiBiZSBvbmx5IG9uZSBJU0EgYnVzLCBzbyBpdCBp cyBzYWZlIHRvIHVzZSBnbG9iYWxzLiAqLwpkaWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvaXNhL29m d19pc2EuYyBiL3N5cy9zcGFyYzY0L2lzYS9vZndfaXNhLmMKaW5kZXggZGJlNWQ4YS4uMmJlODk0 ZCAxMDA2NDQKLS0tIGEvc3lzL3NwYXJjNjQvaXNhL29md19pc2EuYworKysgYi9zeXMvc3BhcmM2 NC9pc2Evb2Z3X2lzYS5jCkBAIC02NSwxNCArNjUsMTUgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIp OwogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogI2luY2x1ZGUgPHN5cy9zeXN0bS5oPgogI2luY2x1 ZGUgPHN5cy9idXMuaD4KKyNpbmNsdWRlIDxzeXMvcm1hbi5oPgogCiAjaW5jbHVkZSA8ZGV2L29m dy9vZndfYnVzX3N1YnIuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVk ZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1 ZGUgPG1hY2hpbmUvcmVzb3VyY2UuaD4KIAotI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2ku aD4KICNpbmNsdWRlIDxzcGFyYzY0L2lzYS9vZndfaXNhLmg+CiAKICNpbmNsdWRlICJwY2liX2lm LmgiCkBAIC04Myw5ICs4NCw5IEBAIG9md19pc2FfcmFuZ2VfcmVzdHlwZShzdHJ1Y3QgaXNhX3Jh bmdlcyAqcmFuZ2UpCiAJaW50IHBzID0gSVNBX1JBTkdFX1BTKHJhbmdlKTsKIAogCXN3aXRjaCAo cHMpIHsKLQljYXNlIE9GV19QQ0lfQ1NfSU86CisJY2FzZSBPRldfUENJX0lPOgogCQlyZXR1cm4g KFNZU19SRVNfSU9QT1JUKTsKLQljYXNlIE9GV19QQ0lfQ1NfTUVNMzI6CisJY2FzZSBPRldfUENJ X01FTTMyOgogCQlyZXR1cm4gKFNZU19SRVNfTUVNT1JZKTsKIAlkZWZhdWx0OgogCQlwYW5pYygi b2Z3X2lzYV9yYW5nZV9yZXN0eXBlOiBpbGxlZ2FsIHNwYWNlICV4IiwgcHMpOwpkaWZmIC0tZ2l0 IGEvc3lzL3NwYXJjNjQvcGNpL2FwYi5jIGIvc3lzL3NwYXJjNjQvcGNpL2FwYi5jCmluZGV4IGJh MzY0M2MuLmY3MDllOWEgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L3BjaS9hcGIuYworKysgYi9z eXMvc3BhcmM2NC9wY2kvYXBiLmMKQEAgLTUzLDYgKzUzLDggQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogCiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9v cGVuZmlybS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8 ZGV2L29mdy9vZndfcGNpLmg+CiAKICNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1ZGUg PG1hY2hpbmUvcmVzb3VyY2UuaD4KQEAgLTYzLDcgKzY1LDYgQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogCiAjaW5jbHVkZSAicGNpYl9pZi5oIgogCi0jaW5jbHVkZSA8c3BhcmM2NC9wY2kvb2Z3 X3BjaS5oPgogI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2liX3N1YnIuaD4KIAogLyoKZGlm ZiAtLWdpdCBhL3N5cy9zcGFyYzY0L3BjaS9maXJlLmMgYi9zeXMvc3BhcmM2NC9wY2kvZmlyZS5j CmluZGV4IGUwNmFkNTAuLmJkNzk1ZDIgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L3BjaS9maXJl LmMKKysrIGIvc3lzL3NwYXJjNjQvcGNpL2ZpcmUuYwpAQCAtNjAsNiArNjAsOCBAQCBfX0ZCU0RJ RCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KICNpbmNsdWRl IDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4K KyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPHZtL3ZtLmg+CiAjaW5j bHVkZSA8dm0vcG1hcC5oPgpAQCAtNzQsNyArNzYsNiBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7 CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5o PgogCi0jaW5jbHVkZSA8c3BhcmM2NC9wY2kvb2Z3X3BjaS5oPgogI2luY2x1ZGUgPHNwYXJjNjQv cGNpL2ZpcmVyZWcuaD4KICNpbmNsdWRlIDxzcGFyYzY0L3BjaS9maXJldmFyLmg+CiAKQEAgLTEz Niw4ICsxMzcsOCBAQCBzdGF0aWMgZGV2aWNlX21ldGhvZF90IGZpcmVfbWV0aG9kc1tdID0gewog CURFVk1FVEhPRChidXNfc2V0dXBfaW50ciwJZmlyZV9zZXR1cF9pbnRyKSwKIAlERVZNRVRIT0Qo YnVzX3RlYXJkb3duX2ludHIsCWZpcmVfdGVhcmRvd25faW50ciksCiAJREVWTUVUSE9EKGJ1c19h bGxvY19yZXNvdXJjZSwJZmlyZV9hbGxvY19yZXNvdXJjZSksCi0JREVWTUVUSE9EKGJ1c19hY3Rp dmF0ZV9yZXNvdXJjZSwgb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZSksCi0JREVWTUVUSE9EKGJ1 c19kZWFjdGl2YXRlX3Jlc291cmNlLCBidXNfZ2VuZXJpY19kZWFjdGl2YXRlX3Jlc291cmNlKSwK KwlERVZNRVRIT0QoYnVzX2FjdGl2YXRlX3Jlc291cmNlLCAgIHNwYXJjNjRfb2Z3X3BjaV9hY3Rp dmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19kZWFjdGl2YXRlX3Jlc291cmNlLCBzcGFy YzY0X29md19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZSksCiAJREVWTUVUSE9EKGJ1c19hZGp1c3Rf cmVzb3VyY2UsCW9md19wY2lfYWRqdXN0X3Jlc291cmNlKSwKIAlERVZNRVRIT0QoYnVzX3JlbGVh c2VfcmVzb3VyY2UsCWJ1c19nZW5lcmljX3JlbGVhc2VfcmVzb3VyY2UpLAogCURFVk1FVEhPRChi dXNfZ2V0X2RtYV90YWcsCW9md19wY2lfZ2V0X2RtYV90YWcpLApkaWZmIC0tZ2l0IGEvc3lzL3Nw YXJjNjQvcGNpL29md19wY2kuYyBiL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpLmMKZGVsZXRlZCBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDhiYWJkNDkuLjAwMDAwMDAKLS0tIGEvc3lzL3NwYXJjNjQv cGNpL29md19wY2kuYworKysgL2Rldi9udWxsCkBAIC0xLDQwNiArMCwwIEBACi0vKi0KLSAqIENv cHlyaWdodCAoYykgMTk5OSwgMjAwMCBNYXR0aGV3IFIuIEdyZWVuCi0gKiBDb3B5cmlnaHQgKGMp IDIwMDEgLSAyMDAzIGJ5IFRob21hcyBNb2VzdGwgPHRtbUBGcmVlQlNELm9yZz4KLSAqIENvcHly aWdodCAoYykgMjAwNSAtIDIwMTUgYnkgTWFyaXVzIFN0cm9ibCA8bWFyaXVzQEZyZWVCU0Qub3Jn PgotICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KLSAqCi0gKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNl IGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKLSAqIG1vZGlmaWNh dGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9u cwotICogYXJlIG1ldDoKLSAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0 IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0Ci0gKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBj b25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCi0gKiAyLiBSZWRpc3RyaWJ1 dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAot ICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyIGluIHRoZQotICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJp YWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KLSAqIDMuIFRoZSBuYW1lIG9mIHRo ZSBhdXRob3IgbWF5IG5vdCBiZSB1c2VkIHRvIGVuZG9yc2Ugb3IgcHJvbW90ZSBwcm9kdWN0cwot ICogICAgZGVyaXZlZCBmcm9tIHRoaXMgc29mdHdhcmUgd2l0aG91dCBzcGVjaWZpYyBwcmlvciB3 cml0dGVuIHBlcm1pc3Npb24uCi0gKgotICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBU SEUgQVVUSE9SIGBgQVMgSVMnJyBBTkQgQU5ZIEVYUFJFU1MgT1IKLSAqIElNUExJRUQgV0FSUkFO VElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRSBJTVBMSUVEIFdBUlJBTlRJ RVMKLSAqIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV UlBPU0UgQVJFIERJU0NMQUlNRUQuCi0gKiBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIEJF IExJQUJMRSBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsCi0gKiBJTkNJREVOVEFMLCBTUEVDSUFM LCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwgREFNQUdFUyAoSU5DTFVESU5HLAotICogQlVU IE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTIE9SIFNFUlZJ Q0VTOwotICogTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVS UlVQVElPTikgSE9XRVZFUiBDQVVTRUQKLSAqIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElU WSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUIExJQUJJTElUWSwKLSAqIE9SIFRPUlQgKElO Q0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCi0gKiBP VVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBP U1NJQklMSVRZIE9GCi0gKiBTVUNIIERBTUFHRS4KLSAqCi0gKglmcm9tOiBOZXRCU0Q6IHBzeWNo by5jLHYgMS4zNSAyMDAxLzA5LzEwIDE2OjE3OjA2IGVlaCBFeHAKLSAqLwotCi0jaW5jbHVkZSA8 c3lzL2NkZWZzLmg+Ci1fX0ZCU0RJRCgiJEZyZWVCU0QkIik7Ci0KLSNpbmNsdWRlICJvcHRfb2Z3 X3BjaS5oIgotCi0jaW5jbHVkZSA8c3lzL3BhcmFtLmg+Ci0jaW5jbHVkZSA8c3lzL3N5c3RtLmg+ Ci0jaW5jbHVkZSA8c3lzL2J1cy5oPgotI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KLSNpbmNsdWRl IDxzeXMvcm1hbi5oPgotCi0jaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+Ci0jaW5jbHVkZSA8 ZGV2L29mdy9vZndfcGNpLmg+Ci0jaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgotCi0jaW5j bHVkZSA8ZGV2L3BjaS9wY2lyZWcuaD4KLSNpbmNsdWRlIDxkZXYvcGNpL3BjaXZhci5oPgotCi0j aW5jbHVkZSA8bWFjaGluZS9hc2kuaD4KLSNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgotI2luY2x1 ZGUgPG1hY2hpbmUvYnVzX3ByaXZhdGUuaD4KLSNpbmNsdWRlIDxtYWNoaW5lL2NwdWZ1bmMuaD4K LSNpbmNsdWRlIDxtYWNoaW5lL2Zzci5oPgotI2luY2x1ZGUgPG1hY2hpbmUvcmVzb3VyY2UuaD4K LQotI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2kuaD4KLQotaW50Ci1vZndfcGNpX2F0dGFj aF9jb21tb24oZGV2aWNlX3QgZGV2LCBidXNfZG1hX3RhZ190IGRtYXQsIHVfbG9uZyBpb3NpemUs Ci0gICAgdV9sb25nIG1lbXNpemUpCi17Ci0Jc3RydWN0IG9md19wY2lfc29mdGMgKnNjOwotCXN0 cnVjdCBvZndfcGNpX3JhbmdlcyAqcmFuZ2U7Ci0JcGhhbmRsZV90IG5vZGU7Ci0JdWludDMyX3Qg cHJvcF9hcnJheVsyXTsKLQl1X2ludCBpLCBqLCBucmFuZ2U7Ci0KLQlzYyA9IGRldmljZV9nZXRf c29mdGMoZGV2KTsKLQlub2RlID0gb2Z3X2J1c19nZXRfbm9kZShkZXYpOwotCXNjLT5zY19ub2Rl ID0gbm9kZTsKLQlzYy0+c2NfcGNpX2RtYXQgPSBkbWF0OwotCi0JLyogSW5pdGlhbGl6ZSBtZW1v cnkgYW5kIEkvTyBybWFucy4gKi8KLQlzYy0+c2NfcGNpX2lvX3JtYW4ucm1fdHlwZSA9IFJNQU5f QVJSQVk7Ci0Jc2MtPnNjX3BjaV9pb19ybWFuLnJtX2Rlc2NyID0gIlBDSSBJL08gUG9ydHMiOwot CWlmIChybWFuX2luaXQoJnNjLT5zY19wY2lfaW9fcm1hbikgIT0gMCB8fAotCSAgICBybWFuX21h bmFnZV9yZWdpb24oJnNjLT5zY19wY2lfaW9fcm1hbiwgMCwgaW9zaXplKSAhPSAwKSB7Ci0JCWRl dmljZV9wcmludGYoZGV2LCAiZmFpbGVkIHRvIHNldCB1cCBJL08gcm1hblxuIik7Ci0JCXJldHVy biAoRU5YSU8pOwotCX0KLQlzYy0+c2NfcGNpX21lbV9ybWFuLnJtX3R5cGUgPSBSTUFOX0FSUkFZ OwotCXNjLT5zY19wY2lfbWVtX3JtYW4ucm1fZGVzY3IgPSAiUENJIE1lbW9yeSI7Ci0JaWYgKHJt YW5faW5pdCgmc2MtPnNjX3BjaV9tZW1fcm1hbikgIT0gMCB8fAotCSAgICBybWFuX21hbmFnZV9y ZWdpb24oJnNjLT5zY19wY2lfbWVtX3JtYW4sIDAsIG1lbXNpemUpICE9IDApIHsKLQkJZGV2aWNl X3ByaW50ZihkZXYsICJmYWlsZWQgdG8gc2V0IHVwIG1lbW9yeSBybWFuXG4iKTsKLQkJcmV0dXJu IChFTlhJTyk7Ci0JfQotCi0JLyoKLQkgKiBGaW5kIHRoZSBhZGRyZXNzZXMgb2YgdGhlIHZhcmlv dXMgYnVzIHNwYWNlcy4gIFRoZSBwaHlzaWNhbAotCSAqIHN0YXJ0IGFkZHJlc3NlcyBvZiB0aGUg cmFuZ2VzIGFyZSB0aGUgY29uZmlndXJhdGlvbiwgSS9PIGFuZAotCSAqIG1lbW9yeSBoYW5kbGVz LiAgVGhlcmUgc2hvdWxkIG5vdCBiZSBtdWx0aXBsZSBvbmVzIG9mIG9uZSBraW5kLgotCSAqLwot CW5yYW5nZSA9IE9GX2dldHByb3BfYWxsb2Mobm9kZSwgInJhbmdlcyIsIHNpemVvZigqcmFuZ2Up LAotCSAgICAodm9pZCAqKikmcmFuZ2UpOwotCWZvciAoaSA9IDA7IGkgPCBucmFuZ2U7IGkrKykg ewotCQlqID0gT0ZXX1BDSV9SQU5HRV9DUygmcmFuZ2VbaV0pOwotCQlpZiAoc2MtPnNjX3BjaV9i aFtqXSAhPSAwKSB7Ci0JCQlkZXZpY2VfcHJpbnRmKGRldiwgImR1cGxpY2F0ZSByYW5nZSBmb3Ig c3BhY2UgJWRcbiIsCi0JCQkgICAgaik7Ci0JCQlmcmVlKHJhbmdlLCBNX09GV1BST1ApOwotCQkJ cmV0dXJuIChFSU5WQUwpOwotCQl9Ci0JCXNjLT5zY19wY2lfYmhbal0gPSBPRldfUENJX1JBTkdF X1BIWVMoJnJhbmdlW2ldKTsKLQl9Ci0JZnJlZShyYW5nZSwgTV9PRldQUk9QKTsKLQotCS8qCi0J ICogTWFrZSBzdXJlIHRoYXQgdGhlIGV4cGVjdGVkIHJhbmdlcyBhcmUgYWN0dWFsbHkgcHJlc2Vu dC4KLQkgKiBUaGUgT0ZXX1BDSV9DU19NRU02NCBvbmUgaXMgbm90IGN1cnJlbnRseSB1c2VkLgot CSAqLwotCWlmIChzYy0+c2NfcGNpX2JoW09GV19QQ0lfQ1NfQ09ORklHXSA9PSAwKSB7Ci0JCWRl dmljZV9wcmludGYoZGV2LCAibWlzc2luZyBDT05GSUcgcmFuZ2VcbiIpOwotCQlyZXR1cm4gKEVO WElPKTsKLQl9Ci0JaWYgKHNjLT5zY19wY2lfYmhbT0ZXX1BDSV9DU19JT10gPT0gMCkgewotCQlk ZXZpY2VfcHJpbnRmKGRldiwgIm1pc3NpbmcgSU8gcmFuZ2VcbiIpOwotCQlyZXR1cm4gKEVOWElP KTsKLQl9Ci0JaWYgKHNjLT5zY19wY2lfYmhbT0ZXX1BDSV9DU19NRU0zMl0gPT0gMCkgewotCQlk ZXZpY2VfcHJpbnRmKGRldiwgIm1pc3NpbmcgTUVNMzIgcmFuZ2VcbiIpOwotCQlyZXR1cm4gKEVO WElPKTsKLQl9Ci0KLQkvKiBBbGxvY2F0ZSBvdXIgdGFncy4gKi8KLQlzYy0+c2NfcGNpX2lvdCA9 IHNwYXJjNjRfYWxsb2NfYnVzX3RhZyhOVUxMLCBQQ0lfSU9fQlVTX1NQQUNFKTsKLQlpZiAoc2Mt PnNjX3BjaV9pb3QgPT0gTlVMTCkgewotCQlkZXZpY2VfcHJpbnRmKGRldiwgImNvdWxkIG5vdCBh bGxvY2F0ZSBQQ0kgSS9PIHRhZ1xuIik7Ci0JCXJldHVybiAoRU5YSU8pOwotCX0KLQlzYy0+c2Nf cGNpX2NmZ3QgPSBzcGFyYzY0X2FsbG9jX2J1c190YWcoTlVMTCwgUENJX0NPTkZJR19CVVNfU1BB Q0UpOwotCWlmIChzYy0+c2NfcGNpX2NmZ3QgPT0gTlVMTCkgewotCQlkZXZpY2VfcHJpbnRmKGRl diwKLQkJICAgICJjb3VsZCBub3QgYWxsb2NhdGUgUENJIGNvbmZpZ3VyYXRpb24gc3BhY2UgdGFn XG4iKTsKLQkJcmV0dXJuIChFTlhJTyk7Ci0JfQotCi0JLyoKLQkgKiBHZXQgdGhlIGJ1cyByYW5n ZSBmcm9tIHRoZSBmaXJtd2FyZS4KLQkgKi8KLQlpID0gT0ZfZ2V0cHJvcChub2RlLCAiYnVzLXJh bmdlIiwgKHZvaWQgKilwcm9wX2FycmF5LAotCSAgICBzaXplb2YocHJvcF9hcnJheSkpOwotCWlm IChpID09IC0xKSB7Ci0JCWRldmljZV9wcmludGYoZGV2LCAiY291bGQgbm90IGdldCBidXMtcmFu Z2VcbiIpOwotCQlyZXR1cm4gKEVOWElPKTsKLQl9Ci0JaWYgKGkgIT0gc2l6ZW9mKHByb3BfYXJy YXkpKSB7Ci0JCWRldmljZV9wcmludGYoZGV2LCAiYnJva2VuIGJ1cy1yYW5nZSAoJWQpIiwgaSk7 Ci0JCXJldHVybiAoRUlOVkFMKTsKLQl9Ci0Jc2MtPnNjX3BjaV9zZWNidXMgPSBwcm9wX2FycmF5 WzBdOwotCXNjLT5zY19wY2lfc3ViYnVzID0gcHJvcF9hcnJheVsxXTsKLQlpZiAoYm9vdHZlcmJv c2UgIT0gMCkKLQkJZGV2aWNlX3ByaW50ZihkZXYsICJidXMgcmFuZ2UgJXUgdG8gJXU7IFBDSSBi dXMgJWRcbiIsCi0JCSAgICBzYy0+c2NfcGNpX3NlY2J1cywgc2MtPnNjX3BjaV9zdWJidXMsIHNj LT5zY19wY2lfc2VjYnVzKTsKLQotCW9md19idXNfc2V0dXBfaWluZm8obm9kZSwgJnNjLT5zY19w Y2lfaWluZm8sIHNpemVvZihvZndfcGNpX2ludHJfdCkpOwotCi0JcmV0dXJuICgwKTsKLX0KLQot dWludDMyX3QKLW9md19wY2lfcmVhZF9jb25maWdfY29tbW9uKGRldmljZV90IGRldiwgdV9pbnQg cmVnbWF4LCB1X2xvbmcgb2Zmc2V0LAotICAgIHVfaW50IGJ1cywgdV9pbnQgc2xvdCwgdV9pbnQg ZnVuYywgdV9pbnQgcmVnLCBpbnQgd2lkdGgpCi17Ci0Jc3RydWN0IG9md19wY2lfc29mdGMgKnNj OwotCWJ1c19zcGFjZV9oYW5kbGVfdCBiaDsKLQl1aW50MzJfdCByLCB3cmQ7Ci0JaW50IGk7Ci0J dWludDE2X3Qgc2hydDsKLQl1aW50OF90IGJ5dGU7Ci0KLQlzYyA9IGRldmljZV9nZXRfc29mdGMo ZGV2KTsKLQlpZiAoYnVzIDwgc2MtPnNjX3BjaV9zZWNidXMgfHwgYnVzID4gc2MtPnNjX3BjaV9z dWJidXMgfHwKLQkgICAgc2xvdCA+IFBDSV9TTE9UTUFYIHx8IGZ1bmMgPiBQQ0lfRlVOQ01BWCB8 fCByZWcgPiByZWdtYXgpCi0JCXJldHVybiAoLTEpOwotCi0JYmggPSBzYy0+c2NfcGNpX2JoW09G V19QQ0lfQ1NfQ09ORklHXTsKLQlzd2l0Y2ggKHdpZHRoKSB7Ci0JY2FzZSAxOgotCQlpID0gYnVz X3NwYWNlX3BlZWtfMShzYy0+c2NfcGNpX2NmZ3QsIGJoLCBvZmZzZXQsICZieXRlKTsKLQkJciA9 IGJ5dGU7Ci0JCWJyZWFrOwotCWNhc2UgMjoKLQkJaSA9IGJ1c19zcGFjZV9wZWVrXzIoc2MtPnNj X3BjaV9jZmd0LCBiaCwgb2Zmc2V0LCAmc2hydCk7Ci0JCXIgPSBzaHJ0OwotCQlicmVhazsKLQlj YXNlIDQ6Ci0JCWkgPSBidXNfc3BhY2VfcGVla180KHNjLT5zY19wY2lfY2ZndCwgYmgsIG9mZnNl dCwgJndyZCk7Ci0JCXIgPSB3cmQ7Ci0JCWJyZWFrOwotCWRlZmF1bHQ6Ci0JCXBhbmljKCIlczog YmFkIHdpZHRoICVkIiwgX19mdW5jX18sIHdpZHRoKTsKLQkJLyogTk9UUkVBQ0hFRCAqLwotCX0K LQotCWlmIChpKSB7Ci0jaWZkZWYgT0ZXX1BDSV9ERUJVRwotCQlwcmludGYoIiVzOiByZWFkIGRh dGEgZXJyb3IgcmVhZGluZzogJWQuJWQuJWQ6IDB4JXhcbiIsCi0JCSAgICBfX2Z1bmNfXywgYnVz LCBzbG90LCBmdW5jLCByZWcpOwotI2VuZGlmCi0JCXIgPSAtMTsKLQl9Ci0JcmV0dXJuIChyKTsK LX0KLQotdm9pZAotb2Z3X3BjaV93cml0ZV9jb25maWdfY29tbW9uKGRldmljZV90IGRldiwgdV9p bnQgcmVnbWF4LCB1X2xvbmcgb2Zmc2V0LAotICAgIHVfaW50IGJ1cywgdV9pbnQgc2xvdCwgdV9p bnQgZnVuYywgdV9pbnQgcmVnLCB1aW50MzJfdCB2YWwsIGludCB3aWR0aCkKLXsKLQlzdHJ1Y3Qg b2Z3X3BjaV9zb2Z0YyAqc2M7Ci0JYnVzX3NwYWNlX2hhbmRsZV90IGJoOwotCi0Jc2MgPSBkZXZp Y2VfZ2V0X3NvZnRjKGRldik7Ci0JaWYgKGJ1cyA8IHNjLT5zY19wY2lfc2VjYnVzIHx8IGJ1cyA+ IHNjLT5zY19wY2lfc3ViYnVzIHx8Ci0JICAgIHNsb3QgPiBQQ0lfU0xPVE1BWCB8fCBmdW5jID4g UENJX0ZVTkNNQVggfHwgcmVnID4gcmVnbWF4KQotCQlyZXR1cm47Ci0KLQliaCA9IHNjLT5zY19w Y2lfYmhbT0ZXX1BDSV9DU19DT05GSUddOwotCXN3aXRjaCAod2lkdGgpIHsKLQljYXNlIDE6Ci0J CWJ1c19zcGFjZV93cml0ZV8xKHNjLT5zY19wY2lfY2ZndCwgYmgsIG9mZnNldCwgdmFsKTsKLQkJ YnJlYWs7Ci0JY2FzZSAyOgotCQlidXNfc3BhY2Vfd3JpdGVfMihzYy0+c2NfcGNpX2NmZ3QsIGJo LCBvZmZzZXQsIHZhbCk7Ci0JCWJyZWFrOwotCWNhc2UgNDoKLQkJYnVzX3NwYWNlX3dyaXRlXzQo c2MtPnNjX3BjaV9jZmd0LCBiaCwgb2Zmc2V0LCB2YWwpOwotCQlicmVhazsKLQlkZWZhdWx0Ogot CQlwYW5pYygiJXM6IGJhZCB3aWR0aCAlZCIsIF9fZnVuY19fLCB3aWR0aCk7Ci0JCS8qIE5PVFJF QUNIRUQgKi8KLQl9Ci19Ci0KLW9md19wY2lfaW50cl90Ci1vZndfcGNpX3JvdXRlX2ludGVycnVw dF9jb21tb24oZGV2aWNlX3QgYnJpZGdlLCBkZXZpY2VfdCBkZXYsIGludCBwaW4pCi17Ci0Jc3Ry dWN0IG9md19wY2lfc29mdGMgKnNjOwotCXN0cnVjdCBvZndfcGNpX3JlZ2lzdGVyIHJlZzsKLQlv ZndfcGNpX2ludHJfdCBwaW50ciwgbWludHI7Ci0KLQlzYyA9IGRldmljZV9nZXRfc29mdGMoYnJp ZGdlKTsKLQlwaW50ciA9IHBpbjsKLQlpZiAob2Z3X2J1c19sb29rdXBfaW1hcChvZndfYnVzX2dl dF9ub2RlKGRldiksICZzYy0+c2NfcGNpX2lpbmZvLAotCSAgICAmcmVnLCBzaXplb2YocmVnKSwg JnBpbnRyLCBzaXplb2YocGludHIpLCAmbWludHIsIHNpemVvZihtaW50ciksCi0JICAgIE5VTEwp ICE9IDApCi0JCXJldHVybiAobWludHIpOwotCXJldHVybiAoUENJX0lOVkFMSURfSVJRKTsKLX0K LQotdm9pZAotb2Z3X3BjaV9kbWFtYXBfc3luY19zdHN0X29yZGVyX2NvbW1vbih2b2lkKQotewot CXN0YXRpYyB1X2NoYXIgYnVmW1ZJU19CTE9DS1NJWkVdIF9fYWxpZ25lZChWSVNfQkxPQ0tTSVpF KTsKLQlyZWdpc3Rlcl90IHJlZywgczsKLQotCXMgPSBpbnRyX2Rpc2FibGUoKTsKLQlyZWcgPSBy ZChmcHJzKTsKLQl3cihmcHJzLCByZWcgfCBGUFJTX0ZFRiwgMCk7Ci0JX19hc20gX192b2xhdGls ZSgic3RkYSAlJWYwLCBbJTBdICUxIgotCSAgICA6IDogInIiIChidWYpLCAibiIgKEFTSV9CTEtf Q09NTUlUX1MpKTsKLQltZW1iYXIoU3luYyk7Ci0Jd3IoZnBycywgcmVnLCAwKTsKLQlpbnRyX3Jl c3RvcmUocyk7Ci19Ci0KLWludAotb2Z3X3BjaV9yZWFkX2l2YXIoZGV2aWNlX3QgZGV2LCBkZXZp Y2VfdCBjaGlsZCBfX3VudXNlZCwgaW50IHdoaWNoLAotICAgIHVpbnRwdHJfdCAqcmVzdWx0KQot ewotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKLQotCXN3aXRjaCAod2hpY2gpIHsKLQljYXNl IFBDSUJfSVZBUl9ET01BSU46Ci0JCSpyZXN1bHQgPSBkZXZpY2VfZ2V0X3VuaXQoZGV2KTsKLQkJ cmV0dXJuICgwKTsKLQljYXNlIFBDSUJfSVZBUl9CVVM6Ci0JCXNjID0gZGV2aWNlX2dldF9zb2Z0 YyhkZXYpOwotCQkqcmVzdWx0ID0gc2MtPnNjX3BjaV9zZWNidXM7Ci0JCXJldHVybiAoMCk7Ci0J fQotCXJldHVybiAoRU5PRU5UKTsKLX0KLQotc3RydWN0IHJlc291cmNlICoKLW9md19wY2lfYWxs b2NfcmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCAq cmlkLAotICAgIHJtYW5fcmVzX3Qgc3RhcnQsIHJtYW5fcmVzX3QgZW5kLCBybWFuX3Jlc190IGNv dW50LCB1X2ludCBmbGFncykKLXsKLQlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7Ci0Jc3RydWN0 IHJlc291cmNlICpydjsKLQlzdHJ1Y3Qgcm1hbiAqcm07Ci0KLQlzYyA9IGRldmljZV9nZXRfc29m dGMoYnVzKTsKLQlzd2l0Y2ggKHR5cGUpIHsKLQljYXNlIFNZU19SRVNfSVJROgotCQkvKgotCQkg KiBYWFg6IERvbid0IGFjY2VwdCBibGFuayByYW5nZXMgZm9yIG5vdywgb25seSBzaW5nbGUKLQkJ ICogaW50ZXJydXB0cy4gIFRoZSBvdGhlciBjYXNlIHNob3VsZCBub3QgaGFwcGVuIHdpdGgKLQkJ ICogdGhlIE1JIFBDSSBjb2RlIC4uLgotCQkgKiBYWFg6IFRoaXMgbWF5IHJldHVybiBhIHJlc291 cmNlIHRoYXQgaXMgb3V0IG9mIHRoZQotCQkgKiByYW5nZSB0aGF0IHdhcyBzcGVjaWZpZWQuICBJ cyB0aGlzIGNvcnJlY3QgLi4uPwotCQkgKi8KLQkJaWYgKHN0YXJ0ICE9IGVuZCkKLQkJCXBhbmlj KCIlczogWFhYOiBpbnRlcnJ1cHQgcmFuZ2UiLCBfX2Z1bmNfXyk7Ci0JCXJldHVybiAoYnVzX2dl bmVyaWNfYWxsb2NfcmVzb3VyY2UoYnVzLCBjaGlsZCwgdHlwZSwgcmlkLAotCQkgICAgc3RhcnQs IGVuZCwgY291bnQsIGZsYWdzKSk7Ci0JY2FzZSBTWVNfUkVTX01FTU9SWToKLQkJcm0gPSAmc2Mt PnNjX3BjaV9tZW1fcm1hbjsKLQkJYnJlYWs7Ci0JY2FzZSBTWVNfUkVTX0lPUE9SVDoKLQkJcm0g PSAmc2MtPnNjX3BjaV9pb19ybWFuOwotCQlicmVhazsKLQlkZWZhdWx0OgotCQlyZXR1cm4gKE5V TEwpOwotCX0KLQotCXJ2ID0gcm1hbl9yZXNlcnZlX3Jlc291cmNlKHJtLCBzdGFydCwgZW5kLCBj b3VudCwgZmxhZ3MgJiB+UkZfQUNUSVZFLAotCSAgICBjaGlsZCk7Ci0JaWYgKHJ2ID09IE5VTEwp Ci0JCXJldHVybiAoTlVMTCk7Ci0Jcm1hbl9zZXRfcmlkKHJ2LCAqcmlkKTsKLQotCWlmICgoZmxh Z3MgJiBSRl9BQ1RJVkUpICE9IDAgJiYgYnVzX2FjdGl2YXRlX3Jlc291cmNlKGNoaWxkLCB0eXBl LAotCSAgICAqcmlkLCBydikgIT0gMCkgewotCQlybWFuX3JlbGVhc2VfcmVzb3VyY2UocnYpOwot CQlyZXR1cm4gKE5VTEwpOwotCX0KLQlyZXR1cm4gKHJ2KTsKLX0KLQotaW50Ci1vZndfcGNpX2Fj dGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsIGludCB0eXBlLCBp bnQgcmlkLAotICAgIHN0cnVjdCByZXNvdXJjZSAqcikKLXsKLQlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0 YyAqc2M7Ci0Jc3RydWN0IGJ1c19zcGFjZV90YWcgKnRhZzsKLQotCXNjID0gZGV2aWNlX2dldF9z b2Z0YyhidXMpOwotCXN3aXRjaCAodHlwZSkgewotCWNhc2UgU1lTX1JFU19JUlE6Ci0JCXJldHVy biAoYnVzX2dlbmVyaWNfYWN0aXZhdGVfcmVzb3VyY2UoYnVzLCBjaGlsZCwgdHlwZSwgcmlkLAot CQkgICAgcikpOwotCWNhc2UgU1lTX1JFU19NRU1PUlk6Ci0JCXRhZyA9IHNwYXJjNjRfYWxsb2Nf YnVzX3RhZyhyLCBQQ0lfTUVNT1JZX0JVU19TUEFDRSk7Ci0JCWlmICh0YWcgPT0gTlVMTCkKLQkJ CXJldHVybiAoRU5PTUVNKTsKLQkJcm1hbl9zZXRfYnVzdGFnKHIsIHRhZyk7Ci0JCXJtYW5fc2V0 X2J1c2hhbmRsZShyLCBzYy0+c2NfcGNpX2JoW09GV19QQ0lfQ1NfTUVNMzJdICsKLQkJICAgIHJt YW5fZ2V0X3N0YXJ0KHIpKTsKLQkJYnJlYWs7Ci0JY2FzZSBTWVNfUkVTX0lPUE9SVDoKLQkJcm1h bl9zZXRfYnVzdGFnKHIsIHNjLT5zY19wY2lfaW90KTsKLQkJcm1hbl9zZXRfYnVzaGFuZGxlKHIs IHNjLT5zY19wY2lfYmhbT0ZXX1BDSV9DU19JT10gKwotCQkgICAgcm1hbl9nZXRfc3RhcnQocikp OwotCQlicmVhazsKLQl9Ci0JcmV0dXJuIChybWFuX2FjdGl2YXRlX3Jlc291cmNlKHIpKTsKLX0K LQotaW50Ci1vZndfcGNpX2FkanVzdF9yZXNvdXJjZShkZXZpY2VfdCBidXMsIGRldmljZV90IGNo aWxkLCBpbnQgdHlwZSwKLSAgICBzdHJ1Y3QgcmVzb3VyY2UgKnIsIHJtYW5fcmVzX3Qgc3RhcnQs IHJtYW5fcmVzX3QgZW5kKQotewotCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKLQlzdHJ1Y3Qg cm1hbiAqcm07Ci0KLQlzYyA9IGRldmljZV9nZXRfc29mdGMoYnVzKTsKLQlzd2l0Y2ggKHR5cGUp IHsKLQljYXNlIFNZU19SRVNfSVJROgotCQlyZXR1cm4gKGJ1c19nZW5lcmljX2FkanVzdF9yZXNv dXJjZShidXMsIGNoaWxkLCB0eXBlLCByLAotCQkgICAgc3RhcnQsIGVuZCkpOwotCWNhc2UgU1lT X1JFU19NRU1PUlk6Ci0JCXJtID0gJnNjLT5zY19wY2lfbWVtX3JtYW47Ci0JCWJyZWFrOwotCWNh c2UgU1lTX1JFU19JT1BPUlQ6Ci0JCXJtID0gJnNjLT5zY19wY2lfaW9fcm1hbjsKLQkJYnJlYWs7 Ci0JZGVmYXVsdDoKLQkJcmV0dXJuIChFSU5WQUwpOwotCX0KLQlpZiAocm1hbl9pc19yZWdpb25f bWFuYWdlcihyLCBybSkgPT0gMCkKLQkJcmV0dXJuIChFSU5WQUwpOwotCXJldHVybiAocm1hbl9h ZGp1c3RfcmVzb3VyY2Uociwgc3RhcnQsIGVuZCkpOwotfQotCi1idXNfZG1hX3RhZ190Ci1vZndf cGNpX2dldF9kbWFfdGFnKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQgX191bnVzZWQpCi17 Ci0Jc3RydWN0IG9md19wY2lfc29mdGMgKnNjOwotCi0Jc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1 cyk7Ci0JcmV0dXJuIChzYy0+c2NfcGNpX2RtYXQpOwotfQotCi1waGFuZGxlX3QKLW9md19wY2lf Z2V0X25vZGUoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCBfX3VudXNlZCkKLXsKLQlzdHJ1 Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7Ci0KLQlzYyA9IGRldmljZV9nZXRfc29mdGMoYnVzKTsKLQkv KiBXZSBvbmx5IGhhdmUgb25lIGNoaWxkLCB0aGUgUENJIGJ1cywgd2hpY2ggbmVlZHMgb3VyIG93 biBub2RlLiAqLwotCXJldHVybiAoc2MtPnNjX25vZGUpOwotfQpkaWZmIC0tZ2l0IGEvc3lzL3Nw YXJjNjQvcGNpL29md19wY2kuaCBiL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpLmgKZGVsZXRlZCBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDZkMWU1ZDkuLjAwMDAwMDAKLS0tIGEvc3lzL3NwYXJjNjQv cGNpL29md19wY2kuaAorKysgL2Rldi9udWxsCkBAIC0xLDE3MCArMCwwIEBACi0vKi0KLSAqIENv cHlyaWdodCAoYykgMTk5OSwgMjAwMCBNYXR0aGV3IFIuIEdyZWVuCi0gKiBBbGwgcmlnaHRzIHJl c2VydmVkLgotICoKLSAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5h cnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAotICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVk IHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCi0gKiBhcmUgbWV0OgotICog MS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBj b3B5cmlnaHQKLSAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBm b2xsb3dpbmcgZGlzY2xhaW1lci4KLSAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9y bSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0Ci0gKiAgICBub3RpY2UsIHRoaXMg bGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCi0g KiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0 aGUgZGlzdHJpYnV0aW9uLgotICogMy4gVGhlIG5hbWUgb2YgdGhlIGF1dGhvciBtYXkgbm90IGJl IHVzZWQgdG8gZW5kb3JzZSBvciBwcm9tb3RlIHByb2R1Y3RzCi0gKiAgICBkZXJpdmVkIGZyb20g dGhpcyBzb2Z0d2FyZSB3aXRob3V0IHNwZWNpZmljIHByaW9yIHdyaXR0ZW4gcGVybWlzc2lvbi4K LSAqCi0gKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycn IEFORCBBTlkgRVhQUkVTUyBPUgotICogSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJV VCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQgV0FSUkFOVElFUwotICogT0YgTUVSQ0hBTlRB QklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1F RC4KLSAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgQkUgTElBQkxFIEZPUiBBTlkgRElS RUNULCBJTkRJUkVDVCwKLSAqIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09O U0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcsCi0gKiBCVVQgTk9UIExJTUlURUQgVE8sIFBS T0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMgT1IgU0VSVklDRVM7Ci0gKiBMT1NTIE9GIFVT RSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENB VVNFRAotICogQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRS QUNULCBTVFJJQ1QgTElBQklMSVRZLAotICogT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0Ug T1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKLSAqIE9VVCBPRiBUSEUgVVNFIE9GIFRI SVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKLSAqIFNV Q0ggREFNQUdFLgotICovCi0KLS8qLQotICogQ29weXJpZ2h0IChjKSAxOTk4LCAxOTk5IEVkdWFy ZG8gRS4gSG9ydmF0aAotICogQ29weXJpZ2h0IChjKSAyMDAxLCAyMDAzIGJ5IFRob21hcyBNb2Vz dGwgPHRtbUBGcmVlQlNELm9yZz4KLSAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCi0gKgotICogUmVk aXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3 aXRob3V0Ci0gKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUg Zm9sbG93aW5nIGNvbmRpdGlvbnMKLSAqIGFyZSBtZXQ6Ci0gKiAxLiBSZWRpc3RyaWJ1dGlvbnMg b2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAotICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy LgotICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRo ZSBhYm92ZSBjb3B5cmlnaHQKLSAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMg YW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKLSAqICAgIGRvY3VtZW50YXRpb24g YW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCi0g KiAzLiBUaGUgbmFtZSBvZiB0aGUgYXV0aG9yIG1heSBub3QgYmUgdXNlZCB0byBlbmRvcnNlIG9y IHByb21vdGUgcHJvZHVjdHMKLSAqICAgIGRlcml2ZWQgZnJvbSB0aGlzIHNvZnR3YXJlIHdpdGhv dXQgc3BlY2lmaWMgcHJpb3Igd3JpdHRlbiBwZXJtaXNzaW9uLgotICoKLSAqIFRISVMgU09GVFdB UkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBgYEFTIElTJycgQU5EIEFOWSBFWFBSRVNTIE9S Ci0gKiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBU SEUgSU1QTElFRCBXQVJSQU5USUVTCi0gKiBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1Mg Rk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFIEFSRSBESVNDTEFJTUVELgotICogSU4gTk8gRVZFTlQg U0hBTEwgVEhFIEFVVEhPUiBCRSBMSUFCTEUgRk9SIEFOWSBESVJFQ1QsIElORElSRUNULAotICog SU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMIERBTUFHRVMg KElOQ0xVRElORywKLSAqIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJ VFVURSBHT09EUyBPUiBTRVJWSUNFUzsKLSAqIExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRT OyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pIEhPV0VWRVIgQ0FVU0VECi0gKiBBTkQgT04gQU5Z IFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVCBMSUFCSUxJ VFksCi0gKiBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJ TkcgSU4gQU5ZIFdBWQotICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJ RiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgotICogU1VDSCBEQU1BR0UuCi0gKgotICoJ ZnJvbTogTmV0QlNEOiBwc3ljaG9yZWcuaCx2IDEuMTQgMjAwOC8wNS8zMCAwMjoyOTozNyBtcmcg RXhwCi0gKgotICogJEZyZWVCU0QkCi0gKi8KLQotI2lmbmRlZiBfU1BBUkM2NF9QQ0lfT0ZXX1BD SV9IXwotI2RlZmluZQlfU1BBUkM2NF9QQ0lfT0ZXX1BDSV9IXwotCi0jaW5jbHVkZSA8c3lzL3Jt YW4uaD4KLQotI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1c19zdWJyLmg+Ci0KLSNpbmNsdWRlICJv ZndfcGNpX2lmLmgiCi0KLXR5cGVkZWYgdWludDMyX3Qgb2Z3X3BjaV9pbnRyX3Q7Ci0KLS8qIFBD SSByYW5nZSBjaGlsZCBzcGFjZXMuIFhYWDogYXJlIHRoZXNlIE1JPyAqLwotI2RlZmluZQlPRldf UENJX0NTX0NPTkZJRwkweDAwCi0jZGVmaW5lCU9GV19QQ0lfQ1NfSU8JCTB4MDEKLSNkZWZpbmUJ T0ZXX1BDSV9DU19NRU0zMgkweDAyCi0jZGVmaW5lCU9GV19QQ0lfQ1NfTUVNNjQJMHgwMwotI2Rl ZmluZQlPRldfUENJX05VTV9DUwkJNAotCi0vKiBPRlcgZGV2aWNlIHR5cGVzICovCi0jZGVmaW5l CU9GV19UWVBFX1BDSQkJInBjaSIKLSNkZWZpbmUJT0ZXX1RZUEVfUENJRQkJInBjaWV4IgotCi1z dHJ1Y3Qgb2Z3X3BjaV9tc2lfYWRkcl9yYW5nZXMgewotCXVpbnQzMl90CWFkZHIzMl9oaTsKLQl1 aW50MzJfdAlhZGRyMzJfbG87Ci0JdWludDMyX3QJYWRkcjMyX3N6OwotCXVpbnQzMl90CWFkZHI2 NF9oaTsKLQl1aW50MzJfdAlhZGRyNjRfbG87Ci0JdWludDMyX3QJYWRkcjY0X3N6OwotfTsKLQot I2RlZmluZQlPRldfUENJX01TSV9BRERSX1JBTkdFXzMyKHIpIFwKLQkoKCh1aW50NjRfdCkocikt PmFkZHIzMl9oaSA8PCAzMikgfCAodWludDY0X3QpKHIpLT5hZGRyMzJfbG8pCi0jZGVmaW5lCU9G V19QQ0lfTVNJX0FERFJfUkFOR0VfNjQocikgXAotCSgoKHVpbnQ2NF90KShyKS0+YWRkcjY0X2hp IDw8IDMyKSB8ICh1aW50NjRfdCkociktPmFkZHI2NF9sbykKLQotc3RydWN0IG9md19wY2lfbXNp X2VxX3RvX2RldmlubyB7Ci0JdWludDMyX3QJZXFfZmlyc3Q7Ci0JdWludDMyX3QJZXFfY291bnQ7 Ci0JdWludDMyX3QJZGV2aW5vX2ZpcnN0OwotfTsKLQotc3RydWN0IG9md19wY2lfbXNpX3Jhbmdl cyB7Ci0JdWludDMyX3QJZmlyc3Q7Ci0JdWludDMyX3QJY291bnQ7Ci19OwotCi1zdHJ1Y3Qgb2Z3 X3BjaV9yYW5nZXMgewotCXVpbnQzMl90CWNzcGFjZTsKLQl1aW50MzJfdAljaGlsZF9oaTsKLQl1 aW50MzJfdAljaGlsZF9sbzsKLQl1aW50MzJfdAlwaHlzX2hpOwotCXVpbnQzMl90CXBoeXNfbG87 Ci0JdWludDMyX3QJc2l6ZV9oaTsKLQl1aW50MzJfdAlzaXplX2xvOwotfTsKLQotI2RlZmluZQlP RldfUENJX1JBTkdFX0NISUxEKHIpIFwKLQkoKCh1aW50NjRfdCkociktPmNoaWxkX2hpIDw8IDMy KSB8ICh1aW50NjRfdCkociktPmNoaWxkX2xvKQotI2RlZmluZQlPRldfUENJX1JBTkdFX1BIWVMo cikgXAotCSgoKHVpbnQ2NF90KShyKS0+cGh5c19oaSA8PCAzMikgfCAodWludDY0X3QpKHIpLT5w aHlzX2xvKQotI2RlZmluZQlPRldfUENJX1JBTkdFX1NJWkUocikgXAotCSgoKHVpbnQ2NF90KShy KS0+c2l6ZV9oaSA8PCAzMikgfCAodWludDY0X3QpKHIpLT5zaXplX2xvKQotI2RlZmluZQlPRldf UENJX1JBTkdFX0NTKHIpCSgoKHIpLT5jc3BhY2UgPj4gMjQpICYgMHgwMykKLQotLyogZGVmYXVs dCB2YWx1ZXMgKi8KLSNkZWZpbmUJT0ZXX1BDSV9MQVRFTkNZCTY0Ci0KLS8qCi0gKiBDb21tb24g YW5kIGdlbmVyaWMgcGFydHMgb2YgaG9zdC1QQ0ktYnJpZGdlIHN1cHBvcnQKLSAqLwotCi1zdHJ1 Y3Qgb2Z3X3BjaV9zb2Z0YyB7Ci0Jc3RydWN0IHJtYW4JCXNjX3BjaV9tZW1fcm1hbjsKLQlzdHJ1 Y3Qgcm1hbgkJc2NfcGNpX2lvX3JtYW47Ci0KLQlidXNfc3BhY2VfaGFuZGxlX3QJc2NfcGNpX2Jo W09GV19QQ0lfTlVNX0NTXTsKLQlidXNfc3BhY2VfdGFnX3QJCXNjX3BjaV9jZmd0OwotCWJ1c19z cGFjZV90YWdfdAkJc2NfcGNpX2lvdDsKLQlidXNfZG1hX3RhZ190CQlzY19wY2lfZG1hdDsKLQot CXN0cnVjdCBvZndfYnVzX2lpbmZvCXNjX3BjaV9paW5mbzsKLQotCXBoYW5kbGVfdAkJc2Nfbm9k ZTsKLQotCXVpbnQ4X3QJCQlzY19wY2lfc2VjYnVzOwotCXVpbnQ4X3QJCQlzY19wY2lfc3ViYnVz OwotfTsKLQotaW50IG9md19wY2lfYXR0YWNoX2NvbW1vbihkZXZpY2VfdCBkZXYsIGJ1c19kbWFf dGFnX3QgZG1hdCwgdV9sb25nIGlvc2l6ZSwKLSAgICB1X2xvbmcgbWVtc2l6ZSk7Ci11aW50MzJf dCBvZndfcGNpX3JlYWRfY29uZmlnX2NvbW1vbihkZXZpY2VfdCBkZXYsIHVfaW50IHJlZ21heCwg dV9sb25nIG9mZnNldCwKLSAgICB1X2ludCBidXMsIHVfaW50IHNsb3QsIHVfaW50IGZ1bmMsIHVf aW50IHJlZywgaW50IHdpZHRoKTsKLXZvaWQgb2Z3X3BjaV93cml0ZV9jb25maWdfY29tbW9uKGRl dmljZV90IGRldiwgdV9pbnQgcmVnbWF4LCB1X2xvbmcgb2Zmc2V0LAotICAgIHVfaW50IGJ1cywg dV9pbnQgc2xvdCwgdV9pbnQgZnVuYywgdV9pbnQgcmVnLCB1aW50MzJfdCB2YWwsIGludCB3aWR0 aCk7Ci1vZndfcGNpX2ludHJfdCBvZndfcGNpX3JvdXRlX2ludGVycnVwdF9jb21tb24oZGV2aWNl X3QgYnJpZGdlLCBkZXZpY2VfdCBkZXYsCi0gICAgaW50IHBpbik7Ci0KLXZvaWQgb2Z3X3BjaV9k bWFtYXBfc3luY19zdHN0X29yZGVyX2NvbW1vbih2b2lkKTsKLQotYnVzX2FjdGl2YXRlX3Jlc291 cmNlX3Qgb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZTsKLWJ1c19hZGp1c3RfcmVzb3VyY2VfdCBv ZndfcGNpX2FkanVzdF9yZXNvdXJjZTsKLWJ1c19hbGxvY19yZXNvdXJjZV90IG9md19wY2lfYWxs b2NfcmVzb3VyY2U7Ci1idXNfZ2V0X2RtYV90YWdfdCBvZndfcGNpX2dldF9kbWFfdGFnOwotYnVz X3JlYWRfaXZhcl90IG9md19wY2lfcmVhZF9pdmFyOwotCi1vZndfYnVzX2dldF9ub2RlX3Qgb2Z3 X3BjaV9nZXRfbm9kZTsKLQotI2VuZGlmIC8qICEgX1NQQVJDNjRfUENJX09GV19QQ0lfSF8gKi8K ZGlmZiAtLWdpdCBhL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpYi5jIGIvc3lzL3NwYXJjNjQvcGNp L29md19wY2liLmMKaW5kZXggNzk0NDIzNy4uNmI0MjkwYiAxMDA2NDQKLS0tIGEvc3lzL3NwYXJj NjQvcGNpL29md19wY2liLmMKKysrIGIvc3lzL3NwYXJjNjQvcGNpL29md19wY2liLmMKQEAgLTQ2 LDE0ICs0NiwxNiBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxkZXYvb2Z3 L29md19idXMuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2 L29mdy9vZndfYnVzX3N1YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2lu Y2x1ZGUgPGRldi9wY2kvcGNpcmVnLmg+CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4KICNp bmNsdWRlIDxkZXYvcGNpL3BjaWJfcHJpdmF0ZS5oPgogCiAjaW5jbHVkZSAicGNpYl9pZi5oIgor I2luY2x1ZGUgIm9md19wY2lfaWYuaCIKIAotI2luY2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2ku aD4KICNpbmNsdWRlIDxzcGFyYzY0L3BjaS9vZndfcGNpYl9zdWJyLmg+CiAKICNkZWZpbmUJUENJ X0RFVklEX0FMSV9NNTI0OQkweDUyNDkxMGI5CmRpZmYgLS1naXQgYS9zeXMvc3BhcmM2NC9wY2kv b2Z3X3BjaWJfc3Vici5jIGIvc3lzL3NwYXJjNjQvcGNpL29md19wY2liX3N1YnIuYwppbmRleCAx NGZhNzJiLi40YzJiMTEzIDEwMDY0NAotLS0gYS9zeXMvc3BhcmM2NC9wY2kvb2Z3X3BjaWJfc3Vi ci5jCisrKyBiL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpYl9zdWJyLmMKQEAgLTM0LDggKzM0LDkg QEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9ybWFuLmg+CiAKICNpbmNs dWRlIDxkZXYvb2Z3L29md19idXMuaD4KLSNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KICNp bmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1 YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KIAogI2luY2x1ZGUgPG1hY2hpbmUv YnVzLmg+CiAKQEAgLTQ1LDcgKzQ2LDYgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5j bHVkZSAicGNpYl9pZi5oIgogCi0jaW5jbHVkZSA8c3BhcmM2NC9wY2kvb2Z3X3BjaS5oPgogI2lu Y2x1ZGUgPHNwYXJjNjQvcGNpL29md19wY2liX3N1YnIuaD4KIAogdm9pZApkaWZmIC0tZ2l0IGEv c3lzL3NwYXJjNjQvcGNpL29md19wY2lidXMuYyBiL3N5cy9zcGFyYzY0L3BjaS9vZndfcGNpYnVz LmMKaW5kZXggOTJiOWY3Ni4uMTc4NjA2YiAxMDA2NDQKLS0tIGEvc3lzL3NwYXJjNjQvcGNpL29m d19wY2lidXMuYworKysgYi9zeXMvc3BhcmM2NC9wY2kvb2Z3X3BjaWJ1cy5jCkBAIC0zOSwxMCAr MzksMTIgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9saWJrZXJuLmg+ CiAjaW5jbHVkZSA8c3lzL21vZHVsZS5oPgogI2luY2x1ZGUgPHN5cy9wY2lpby5oPgorI2luY2x1 ZGUgPHN5cy9ybWFuLmg+CiAKICNpbmNsdWRlIDxkZXYvb2Z3L29md19idXMuaD4KLSNpbmNsdWRl IDxkZXYvb2Z3L29md19wY2kuaD4KICNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CisjaW5j bHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2ku aD4KIAogI2luY2x1ZGUgPG1hY2hpbmUvYnVzLmg+CiAjaWZuZGVmIFNVTjRWCkBAIC01NSwxMCAr NTcsOSBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIu aD4KICNpbmNsdWRlIDxkZXYvcGNpL3BjaV9wcml2YXRlLmg+CiAKLSNpbmNsdWRlIDxzcGFyYzY0 L3BjaS9vZndfcGNpLmg+Ci0KICNpbmNsdWRlICJwY2liX2lmLmgiCiAjaW5jbHVkZSAicGNpX2lm LmgiCisjaW5jbHVkZSAib2Z3X3BjaV9pZi5oIgogCiAvKiBIZWxwZXIgZnVuY3Rpb25zICovCiBz dGF0aWMgdm9pZCBvZndfcGNpYnVzX3NldHVwX2RldmljZShkZXZpY2VfdCBicmlkZ2UsIHVpbnQz Ml90IGNsb2NrLApkaWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvcGNpL3BzeWNoby5jIGIvc3lzL3Nw YXJjNjQvcGNpL3BzeWNoby5jCmluZGV4IDQ5NmRmOTYuLjM0NDFkMDggMTAwNjQ0Ci0tLSBhL3N5 cy9zcGFyYzY0L3BjaS9wc3ljaG8uYworKysgYi9zeXMvc3BhcmM2NC9wY2kvcHN5Y2hvLmMKQEAg LTU4LDYgKzU4LDggQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8ZGV2L29m dy9vZndfYnVzLmg+CiAjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2luY2x1ZGUgPGRl di9vZncvb2Z3X2J1c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAKICNp bmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1ZGUgPG1hY2hpbmUvYnVzX2NvbW1vbi5oPgpA QCAtNzAsMTEgKzcyLDExIEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxkZXYv cGNpL3BjaXJlZy5oPgogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAKLSNpbmNsdWRlIDxz cGFyYzY0L3BjaS9vZndfcGNpLmg+CiAjaW5jbHVkZSA8c3BhcmM2NC9wY2kvcHN5Y2hvcmVnLmg+ CiAjaW5jbHVkZSA8c3BhcmM2NC9wY2kvcHN5Y2hvdmFyLmg+CiAKICNpbmNsdWRlICJwY2liX2lm LmgiCisjaW5jbHVkZSAib2Z3X3BjaV9pZi5oIgogCiBzdGF0aWMgY29uc3Qgc3RydWN0IHBzeWNo b19kZXNjICpwc3ljaG9fZmluZF9kZXNjKGNvbnN0IHN0cnVjdCBwc3ljaG9fZGVzYyAqLAogICAg IGNvbnN0IGNoYXIgKik7CkBAIC0xMzAsOCArMTMyLDggQEAgc3RhdGljIGRldmljZV9tZXRob2Rf dCBwc3ljaG9fbWV0aG9kc1tdID0gewogCURFVk1FVEhPRChidXNfc2V0dXBfaW50ciwJcHN5Y2hv X3NldHVwX2ludHIpLAogCURFVk1FVEhPRChidXNfdGVhcmRvd25faW50ciwJYnVzX2dlbmVyaWNf dGVhcmRvd25faW50ciksCiAJREVWTUVUSE9EKGJ1c19hbGxvY19yZXNvdXJjZSwJcHN5Y2hvX2Fs bG9jX3Jlc291cmNlKSwKLQlERVZNRVRIT0QoYnVzX2FjdGl2YXRlX3Jlc291cmNlLCBvZndfcGNp X2FjdGl2YXRlX3Jlc291cmNlKSwKLQlERVZNRVRIT0QoYnVzX2RlYWN0aXZhdGVfcmVzb3VyY2Us IGJ1c19nZW5lcmljX2RlYWN0aXZhdGVfcmVzb3VyY2UpLAorCURFVk1FVEhPRChidXNfYWN0aXZh dGVfcmVzb3VyY2UsICAgc3BhcmM2NF9vZndfcGNpX2FjdGl2YXRlX3Jlc291cmNlKSwKKwlERVZN RVRIT0QoYnVzX2RlYWN0aXZhdGVfcmVzb3VyY2UsIHNwYXJjNjRfb2Z3X3BjaV9kZWFjdGl2YXRl X3Jlc291cmNlKSwKIAlERVZNRVRIT0QoYnVzX2FkanVzdF9yZXNvdXJjZSwJb2Z3X3BjaV9hZGp1 c3RfcmVzb3VyY2UpLAogCURFVk1FVEhPRChidXNfcmVsZWFzZV9yZXNvdXJjZSwJYnVzX2dlbmVy aWNfcmVsZWFzZV9yZXNvdXJjZSksCiAJREVWTUVUSE9EKGJ1c19nZXRfZG1hX3RhZywJb2Z3X3Bj aV9nZXRfZG1hX3RhZyksCkBAIC01NDEsOCArNTQzLDggQEAgcHN5Y2hvX2F0dGFjaChkZXZpY2Vf dCBkZXYpCiAJCXBhbmljKCIlczogb2Z3X3BjaV9hdHRhY2hfY29tbW9uKCkgZmFpbGVkIiwgX19m dW5jX18pOwogCiAJLyogQ2xlYXIgYW55IHBlbmRpbmcgUENJIGVycm9yIGJpdHMuICovCi0JUENJ Ql9XUklURV9DT05GSUcoZGV2LCBzYy0+c2Nfb3BzLnNjX3BjaV9zZWNidXMsIFBDU19ERVZJQ0Us IFBDU19GVU5DLAotCSAgICBQQ0lSX1NUQVRVUywgUENJQl9SRUFEX0NPTkZJRyhkZXYsIHNjLT5z Y19vcHMuc2NfcGNpX3NlY2J1cywKKwlQQ0lCX1dSSVRFX0NPTkZJRyhkZXYsIHNjLT5zY19vcHMu c2Nfc2VjYnVzLCBQQ1NfREVWSUNFLCBQQ1NfRlVOQywKKwkgICAgUENJUl9TVEFUVVMsIFBDSUJf UkVBRF9DT05GSUcoZGV2LCBzYy0+c2Nfb3BzLnNjX3NlY2J1cywKIAkgICAgUENTX0RFVklDRSwg UENTX0ZVTkMsIFBDSVJfU1RBVFVTLCAyKSwgMik7CiAJUENJQ1RMX1dSSVRFOChzYywgUENSX0NT LCBQQ0lDVExfUkVBRDgoc2MsIFBDUl9DUykpOwogCVBDSUNUTF9XUklURTgoc2MsIFBDUl9BRlMs IFBDSUNUTF9SRUFEOChzYywgUENSX0FGUykpOwpAQCAtNjA1LDE5ICs2MDcsMTkgQEAgcHN5Y2hv X2F0dGFjaChkZXZpY2VfdCBkZXYpCiAJICogU2V0IHRoZSBsYXRlbmN5IHRpbWVyIHJlZ2lzdGVy IGFzIHRoaXMgaXNuJ3QgYWx3YXlzIGRvbmUgYnkgdGhlCiAJICogZmlybXdhcmUuCiAJICovCi0J UENJQl9XUklURV9DT05GSUcoZGV2LCBzYy0+c2Nfb3BzLnNjX3BjaV9zZWNidXMsIFBDU19ERVZJ Q0UsIFBDU19GVU5DLAorCVBDSUJfV1JJVEVfQ09ORklHKGRldiwgc2MtPnNjX29wcy5zY19zZWNi dXMsIFBDU19ERVZJQ0UsIFBDU19GVU5DLAogCSAgICBQQ0lSX0xBVFRJTUVSLCBPRldfUENJX0xB VEVOQ1ksIDEpOwogCiAJZm9yIChpID0gUENJUl9WRU5ET1I7IGkgPCBQQ0lSX1NUQVRVUzsgaSAr PSBzaXplb2YodWludDE2X3QpKQogCQlsZTE2ZW5jKCZzYy0+c2NfcGNpX2hwYmNmZ1tpXSwKLQkJ ICAgIGJ1c19zcGFjZV9yZWFkXzIoc2MtPnNjX29wcy5zY19wY2lfY2ZndCwKLQkJICAgIHNjLT5z Y19vcHMuc2NfcGNpX2JoW09GV19QQ0lfQ1NfQ09ORklHXSwKLQkJICAgIFBTWUNIT19DT05GX09G RihzYy0+c2Nfb3BzLnNjX3BjaV9zZWNidXMsIFBDU19ERVZJQ0UsCisJCSAgICBidXNfc3BhY2Vf cmVhZF8yKHNjLT5zY19vcHMuc2NfY2ZndCwKKwkJICAgIHNjLT5zY19vcHMuc2NfYmhbT0ZXX1BD SV9DT05GSUddLAorCQkgICAgUFNZQ0hPX0NPTkZfT0ZGKHNjLT5zY19vcHMuc2Nfc2VjYnVzLCBQ Q1NfREVWSUNFLAogCQkgICAgUENTX0ZVTkMsIGkpKSk7CiAJZm9yIChpID0gUENJUl9SRVZJRDsg aSA8PSBQQ0lSX0JJU1Q7IGkgKz0gc2l6ZW9mKHVpbnQ4X3QpKQotCQlzYy0+c2NfcGNpX2hwYmNm Z1tpXSA9IGJ1c19zcGFjZV9yZWFkXzEoc2MtPnNjX29wcy5zY19wY2lfY2ZndCwKLQkJICAgIHNj LT5zY19vcHMuc2NfcGNpX2JoW09GV19QQ0lfQ1NfQ09ORklHXSwgUFNZQ0hPX0NPTkZfT0ZGKAot CQkgICAgc2MtPnNjX29wcy5zY19wY2lfc2VjYnVzLCBQQ1NfREVWSUNFLCBQQ1NfRlVOQywgaSkp OworCQlzYy0+c2NfcGNpX2hwYmNmZ1tpXSA9IGJ1c19zcGFjZV9yZWFkXzEoc2MtPnNjX29wcy5z Y19jZmd0LAorCQkgICAgc2MtPnNjX29wcy5zY19iaFtPRldfUENJX0NPTkZJR10sIFBTWUNIT19D T05GX09GRigKKwkJICAgIHNjLT5zY19vcHMuc2Nfc2VjYnVzLCBQQ1NfREVWSUNFLCBQQ1NfRlVO QywgaSkpOwogCiAJLyoKIAkgKiBPbiBFMjUwIHRoZSBpbnRlcnJ1cHQgbWFwIGVudHJ5IGZvciB0 aGUgRUJ1cyBicmlkZ2UgaXMgd3JvbmcsCkBAIC04ODIsNyArODg0LDcgQEAgcHN5Y2hvX3JlYWRf Y29uZmlnKGRldmljZV90IGRldiwgdV9pbnQgYnVzLCB1X2ludCBzbG90LCB1X2ludCBmdW5jLCB1 X2ludCByZWcsCiAJICogVGhlIFBzeWNobyBicmlkZ2VzIGNvbnRhaW4gYSBkdXBlIG9mIHRoZWly IGhlYWRlciBhdCAweDgwCiAJICogd2hpY2ggd2UgbnVsbGlmeSB0aGF0IHdheSBhbHNvLgogCSAq LwotCWlmIChidXMgPT0gc2MtPnNjX29wcy5zY19wY2lfc2VjYnVzICYmIHNsb3QgPT0gUENTX0RF VklDRSAmJgorCWlmIChidXMgPT0gc2MtPnNjX29wcy5zY19zZWNidXMgJiYgc2xvdCA9PSBQQ1Nf REVWSUNFICYmCiAJICAgIGZ1bmMgPT0gUENTX0ZVTkMpIHsKIAkJaWYgKHJlZyAlIHdpZHRoICE9 IDApCiAJCQlyZXR1cm4gKC0xKTsKQEAgLTg5Myw5ICs4OTUsOSBAQCBwc3ljaG9fcmVhZF9jb25m aWcoZGV2aWNlX3QgZGV2LCB1X2ludCBidXMsIHVfaW50IHNsb3QsIHVfaW50IGZ1bmMsIHVfaW50 IHJlZywKIAkJaWYgKChyZWcgPCBQQ0lSX1NUQVRVUyAmJiByZWcgKyB3aWR0aCA+IFBDSVJfU1RB VFVTKSB8fAogCQkgICAgcmVnID09IFBDSVJfU1RBVFVTIHx8IHJlZyA9PSBQQ0lSX1NUQVRVUyAr IDEpCiAJCQlsZTE2ZW5jKCZzYy0+c2NfcGNpX2hwYmNmZ1tQQ0lSX1NUQVRVU10sCi0JCQkgICAg YnVzX3NwYWNlX3JlYWRfMihzYy0+c2Nfb3BzLnNjX3BjaV9jZmd0LAotCQkJICAgIHNjLT5zY19v cHMuc2NfcGNpX2JoW09GV19QQ0lfQ1NfQ09ORklHXSwKLQkJCSAgICBQU1lDSE9fQ09ORl9PRkYo c2MtPnNjX29wcy5zY19wY2lfc2VjYnVzLAorCQkJICAgIGJ1c19zcGFjZV9yZWFkXzIoc2MtPnNj X29wcy5zY19jZmd0LAorCQkJICAgIHNjLT5zY19vcHMuc2NfYmhbT0ZXX1BDSV9DT05GSUddLAor CQkJICAgIFBTWUNIT19DT05GX09GRihzYy0+c2Nfb3BzLnNjX3NlY2J1cywKIAkJCSAgICBQQ1Nf REVWSUNFLCBQQ1NfRlVOQywgUENJUl9TVEFUVVMpKSk7CiAKIAkJc3dpdGNoICh3aWR0aCkgewpk aWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvcGNpL3NjaGl6by5jIGIvc3lzL3NwYXJjNjQvcGNpL3Nj aGl6by5jCmluZGV4IGE5NjE1NWIuLjhlNDRhNWEgMTAwNjQ0Ci0tLSBhL3N5cy9zcGFyYzY0L3Bj aS9zY2hpem8uYworKysgYi9zeXMvc3BhcmM2NC9wY2kvc2NoaXpvLmMKQEAgLTU4LDYgKzU4LDgg QEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+ CiAjaW5jbHVkZSA8ZGV2L29mdy9vcGVuZmlybS5oPgorI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1 c19zdWJyLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfcGNpLmg+CiAKICNpbmNsdWRlIDxtYWNo aW5lL2J1cy5oPgogI2luY2x1ZGUgPG1hY2hpbmUvYnVzX2NvbW1vbi5oPgpAQCAtNjksMTEgKzcx LDExIEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxkZXYvcGNpL3BjaXJlZy5o PgogI2luY2x1ZGUgPGRldi9wY2kvcGNpdmFyLmg+CiAKLSNpbmNsdWRlIDxzcGFyYzY0L3BjaS9v ZndfcGNpLmg+CiAjaW5jbHVkZSA8c3BhcmM2NC9wY2kvc2NoaXpvcmVnLmg+CiAjaW5jbHVkZSA8 c3BhcmM2NC9wY2kvc2NoaXpvdmFyLmg+CiAKICNpbmNsdWRlICJwY2liX2lmLmgiCisjaW5jbHVk ZSAib2Z3X3BjaV9pZi5oIgogCiBzdGF0aWMgY29uc3Qgc3RydWN0IHNjaGl6b19kZXNjICpzY2hp em9fZ2V0X2Rlc2MoZGV2aWNlX3QpOwogc3RhdGljIHZvaWQgc2NoaXpvX3NldF9pbnRyKHN0cnVj dCBzY2hpem9fc29mdGMgKiwgdV9pbnQsIHVfaW50LApAQCAtMTI3LDggKzEyOSw4IEBAIHN0YXRp YyBkZXZpY2VfbWV0aG9kX3Qgc2NoaXpvX21ldGhvZHNbXSA9IHsKIAlERVZNRVRIT0QoYnVzX3Nl dHVwX2ludHIsCXNjaGl6b19zZXR1cF9pbnRyKSwKIAlERVZNRVRIT0QoYnVzX3RlYXJkb3duX2lu dHIsCWJ1c19nZW5lcmljX3RlYXJkb3duX2ludHIpLAogCURFVk1FVEhPRChidXNfYWxsb2NfcmVz b3VyY2UsCXNjaGl6b19hbGxvY19yZXNvdXJjZSksCi0JREVWTUVUSE9EKGJ1c19hY3RpdmF0ZV9y ZXNvdXJjZSwgb2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZSksCi0JREVWTUVUSE9EKGJ1c19kZWFj dGl2YXRlX3Jlc291cmNlLCBidXNfZ2VuZXJpY19kZWFjdGl2YXRlX3Jlc291cmNlKSwKKwlERVZN RVRIT0QoYnVzX2FjdGl2YXRlX3Jlc291cmNlLCAgIHNwYXJjNjRfb2Z3X3BjaV9hY3RpdmF0ZV9y ZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19kZWFjdGl2YXRlX3Jlc291cmNlLCBzcGFyYzY0X29m d19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZSksCiAJREVWTUVUSE9EKGJ1c19hZGp1c3RfcmVzb3Vy Y2UsCW9md19wY2lfYWRqdXN0X3Jlc291cmNlKSwKIAlERVZNRVRIT0QoYnVzX3JlbGVhc2VfcmVz b3VyY2UsCWJ1c19nZW5lcmljX3JlbGVhc2VfcmVzb3VyY2UpLAogCURFVk1FVEhPRChidXNfZ2V0 X2RtYV90YWcsCW9md19wY2lfZ2V0X2RtYV90YWcpLApAQCAtNTQ4LDkgKzU1MCw5IEBAIHNjaGl6 b19hdHRhY2goZGV2aWNlX3QgZGV2KQogCQlwYW5pYygiJXM6IG9md19wY2lfYXR0YWNoX2NvbW1v bigpIGZhaWxlZCIsIF9fZnVuY19fKTsKIAogCS8qIENsZWFyIGFueSBwZW5kaW5nIFBDSSBlcnJv ciBiaXRzLiAqLwotCVBDSUJfV1JJVEVfQ09ORklHKGRldiwgc2MtPnNjX29wcy5zY19wY2lfc2Vj YnVzLCBTVFhfQ1NfREVWSUNFLAorCVBDSUJfV1JJVEVfQ09ORklHKGRldiwgc2MtPnNjX29wcy5z Y19zZWNidXMsIFNUWF9DU19ERVZJQ0UsCiAJICAgIFNUWF9DU19GVU5DLCBQQ0lSX1NUQVRVUywg UENJQl9SRUFEX0NPTkZJRyhkZXYsCi0JICAgIHNjLT5zY19vcHMuc2NfcGNpX3NlY2J1cywgU1RY X0NTX0RFVklDRSwgU1RYX0NTX0ZVTkMsIFBDSVJfU1RBVFVTLAorCSAgICBzYy0+c2Nfb3BzLnNj X3NlY2J1cywgU1RYX0NTX0RFVklDRSwgU1RYX0NTX0ZVTkMsIFBDSVJfU1RBVFVTLAogCSAgICAy KSwgMik7CiAJU0NISVpPX1BDSV9TRVQoc2MsIFNUWF9QQ0lfQ1RSTCwgU0NISVpPX1BDSV9SRUFE Xzgoc2MsIFNUWF9QQ0lfQ1RSTCkpOwogCVNDSElaT19QQ0lfU0VUKHNjLCBTVFhfUENJX0FGU1Is IFNDSElaT19QQ0lfUkVBRF84KHNjLCBTVFhfUENJX0FGU1IpKTsKQEAgLTY3OSw3ICs2ODEsNyBA QCBzY2hpem9fYXR0YWNoKGRldmljZV90IGRldikKIAkgKiBTZXQgdGhlIGxhdGVuY3kgdGltZXIg cmVnaXN0ZXIgYXMgdGhpcyBpc24ndCBhbHdheXMgZG9uZSBieSB0aGUKIAkgKiBmaXJtd2FyZS4K IAkgKi8KLQlQQ0lCX1dSSVRFX0NPTkZJRyhkZXYsIHNjLT5zY19vcHMuc2NfcGNpX3NlY2J1cywg U1RYX0NTX0RFVklDRSwKKwlQQ0lCX1dSSVRFX0NPTkZJRyhkZXYsIHNjLT5zY19vcHMuc2Nfc2Vj YnVzLCBTVFhfQ1NfREVWSUNFLAogCSAgICBTVFhfQ1NfRlVOQywgUENJUl9MQVRUSU1FUiwgT0ZX X1BDSV9MQVRFTkNZLCAxKTsKIAogI2RlZmluZQlTQ0hJWk9fU1lTQ1RMX0FERF9VSU5UKG5hbWUs IGFyZywgZGVzYykJCQkJXApAQCAtODA0LDcgKzgwNiw3IEBAIHNjaGl6b19wY2lfYnVzKHZvaWQg KmFyZykKIAkJeHN0YXQgPSBTQ0hJWk9fUENJX1JFQURfOChzYywgWE1TX1BDSV9YX0VSUl9TVEFU KTsKIAllbHNlCiAJCXhzdGF0ID0gMDsKLQlzdGF0dXMgPSBQQ0lCX1JFQURfQ09ORklHKHNjLT5z Y19kZXYsIHNjLT5zY19vcHMuc2NfcGNpX3NlY2J1cywKKwlzdGF0dXMgPSBQQ0lCX1JFQURfQ09O RklHKHNjLT5zY19kZXYsIHNjLT5zY19vcHMuc2Nfc2VjYnVzLAogCSAgICBTVFhfQ1NfREVWSUNF LCBTVFhfQ1NfRlVOQywgUENJUl9TVEFUVVMsIDIpOwogCiAJLyoKQEAgLTg0NSw3ICs4NDcsNyBA QCBzY2hpem9fcGNpX2J1cyh2b2lkICphcmcpCiAJICAgICh1bnNpZ25lZCBsb25nIGxvbmcpaW9t bXUsICh1bnNpZ25lZCBsb25nIGxvbmcpeHN0YXQsIHN0YXR1cyk7CiAKIAkvKiBDbGVhciB0aGUg ZXJyb3IgYml0cyB0aGF0IHdlIGNhdWdodC4gKi8KLQlQQ0lCX1dSSVRFX0NPTkZJRyhzYy0+c2Nf ZGV2LCBzYy0+c2Nfb3BzLnNjX3BjaV9zZWNidXMsIFNUWF9DU19ERVZJQ0UsCisJUENJQl9XUklU RV9DT05GSUcoc2MtPnNjX2Rldiwgc2MtPnNjX29wcy5zY19zZWNidXMsIFNUWF9DU19ERVZJQ0Us CiAJICAgIFNUWF9DU19GVU5DLCBQQ0lSX1NUQVRVUywgc3RhdHVzLCAyKTsKIAlTQ0hJWk9fUENJ X1dSSVRFXzgoc2MsIFNUWF9QQ0lfQ1RSTCwgY3NyKTsKIAlTQ0hJWk9fUENJX1dSSVRFXzgoc2Ms IFNUWF9QQ0lfQUZTUiwgYWZzcik7CkBAIC05NzIsNyArOTc0LDcgQEAgc2NoaXpvX3JlYWRfY29u ZmlnKGRldmljZV90IGRldiwgdV9pbnQgYnVzLCB1X2ludCBzbG90LCB1X2ludCBmdW5jLCB1X2lu dCByZWcsCiAJICogVGhlIFNjaGl6byBicmlkZ2VzIGNvbnRhaW4gYSBkdXBlIG9mIHRoZWlyIGhl YWRlciBhdCAweDgwLgogCSAqLwogCWlmIChzYy0+c2NfbW9kZSA9PSBTQ0hJWk9fTU9ERV9TQ1og JiYKLQkgICAgYnVzID09IHNjLT5zY19vcHMuc2NfcGNpX3NlY2J1cyAmJiBzbG90ID09IFNUWF9D U19ERVZJQ0UgJiYKKwkgICAgYnVzID09IHNjLT5zY19vcHMuc2Nfc2VjYnVzICYmIHNsb3QgPT0g U1RYX0NTX0RFVklDRSAmJgogCSAgICBmdW5jID09IFNUWF9DU19GVU5DICYmIHJlZyArIHdpZHRo ID4gMHg4MCkKIAkJcmV0dXJuICgwKTsKIApkaWZmIC0tZ2l0IGEvc3lzL3NwYXJjNjQvcGNpL3Nw YXJjNjRfb2Z3X3BjaS5jIGIvc3lzL3NwYXJjNjQvcGNpL3NwYXJjNjRfb2Z3X3BjaS5jCm5ldyBm aWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjVlOGQ1OTIKLS0tIC9kZXYvbnVsbAorKysg Yi9zeXMvc3BhcmM2NC9wY2kvc3BhcmM2NF9vZndfcGNpLmMKQEAgLTAsMCArMSwzMTcgQEAKKy8q LQorICogQ29weXJpZ2h0IChjKSAxOTk5LCAyMDAwIE1hdHRoZXcgUi4gR3JlZW4KKyAqIENvcHly aWdodCAoYykgMjAwMSAtIDIwMDMgYnkgVGhvbWFzIE1vZXN0bCA8dG1tQEZyZWVCU0Qub3JnPgor ICogQ29weXJpZ2h0IChjKSAyMDA1IC0gMjAxNSBieSBNYXJpdXMgU3Ryb2JsIDxtYXJpdXNARnJl ZUJTRC5vcmc+CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9u IGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICog bW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBj b25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBj b2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBs aXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJl ZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29w eXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9s bG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhl ciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICogMy4gVGhlIG5h bWUgb2YgdGhlIGF1dGhvciBtYXkgbm90IGJlIHVzZWQgdG8gZW5kb3JzZSBvciBwcm9tb3RlIHBy b2R1Y3RzCisgKiAgICBkZXJpdmVkIGZyb20gdGhpcyBzb2Z0d2FyZSB3aXRob3V0IHNwZWNpZmlj IHByaW9yIHdyaXR0ZW4gcGVybWlzc2lvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJ REVEIEJZIFRIRSBBVVRIT1IgYGBBUyBJUycnIEFORCBBTlkgRVhQUkVTUyBPUgorICogSU1QTElF RCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFIElNUExJRUQg V0FSUkFOVElFUworICogT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRSBBUkUgRElTQ0xBSU1FRC4KKyAqIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBB VVRIT1IgQkUgTElBQkxFIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwKKyAqIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTCBEQU1BR0VTIChJTkNMVURJTkcs CisgKiBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMg T1IgU0VSVklDRVM7CisgKiBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5F U1MgSU5URVJSVVBUSU9OKSBIT1dFVkVSIENBVVNFRAorICogQU5EIE9OIEFOWSBUSEVPUlkgT0Yg TElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QgTElBQklMSVRZLAorICogT1Ig VE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBX QVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBP RiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqCWZyb206IE5ldEJT RDogcHN5Y2hvLmMsdiAxLjM1IDIwMDEvMDkvMTAgMTY6MTc6MDYgZWVoIEV4cAorICovCisKKyNp bmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2luY2x1ZGUg Im9wdF9vZndfcGNpLmgiCisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMv c3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvYnVzLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgor I2luY2x1ZGUgPHN5cy9ybWFuLmg+CisKKyNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+Cisj aW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1 YnIuaD4KKyNpbmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KKworI2luY2x1ZGUgPGRldi9wY2kv cGNpcmVnLmg+CisjaW5jbHVkZSA8ZGV2L3BjaS9wY2l2YXIuaD4KKworI2luY2x1ZGUgPG1hY2hp bmUvYXNpLmg+CisjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL2J1 c19wcml2YXRlLmg+CisjaW5jbHVkZSA8bWFjaGluZS9jcHVmdW5jLmg+CisjaW5jbHVkZSA8bWFj aGluZS9mc3IuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNlLmg+CisKKyNpbmNsdWRlICJv ZndfcGNpX2lmLmgiCisKK3N0YXRpYyBkZXZpY2VfbWV0aG9kX3QJc3BhcmM2NF9vZndfcGNpX21l dGhvZHNbXSA9IHsKKworCURFVk1FVEhPRChidXNfYWN0aXZhdGVfcmVzb3VyY2UsCXNwYXJjNjRf b2Z3X3BjaV9hY3RpdmF0ZV9yZXNvdXJjZSksCisJREVWTUVUSE9EKGJ1c19kZWFjdGl2YXRlX3Jl c291cmNlLAlzcGFyYzY0X29md19wY2lfZGVhY3RpdmF0ZV9yZXNvdXJjZSksCisKKwlERVZNRVRI T0RfRU5ECit9OworCitERUZJTkVfQ0xBU1NfMShvZndfcGNpLCBzcGFyYzY0X29md19wY2lfZHJp dmVyLCBzcGFyYzY0X29md19wY2lfbWV0aG9kcywKKyAgICBzaXplb2Yoc3RydWN0IG9md19wY2lf c29mdGMpLCBvZndfcGNpX2RyaXZlcik7CisKK2ludAorb2Z3X3BjaV9hdHRhY2hfY29tbW9uKGRl dmljZV90IGRldiwgYnVzX2RtYV90YWdfdCBkbWF0LCB1X2xvbmcgaW9zaXplLAorICAgIHVfbG9u ZyBtZW1zaXplKQoreworCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsKKwlzdHJ1Y3Qgb2Z3X3Bj aV9yYW5nZSAqcmFuZ2VzOworCXBoYW5kbGVfdCBub2RlOworCXVpbnQzMl90IHByb3BfYXJyYXlb Ml07CisJdV9pbnQgaSwgaiwgbnJhbmdlOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGRldik7 CisJbm9kZSA9IG9md19idXNfZ2V0X25vZGUoZGV2KTsKKwlzYy0+c2Nfbm9kZSA9IG5vZGU7CisJ c2MtPnNjX2RtYXQgPSBkbWF0OworCisJLyogSW5pdGlhbGl6ZSBtZW1vcnkgYW5kIEkvTyBybWFu cy4gKi8KKwlzYy0+c2NfaW9fcm1hbi5ybV90eXBlID0gUk1BTl9BUlJBWTsKKwlzYy0+c2NfaW9f cm1hbi5ybV9kZXNjciA9ICJQQ0kgSS9PIFBvcnRzIjsKKwlpZiAocm1hbl9pbml0KCZzYy0+c2Nf aW9fcm1hbikgIT0gMCB8fAorCSAgICBybWFuX21hbmFnZV9yZWdpb24oJnNjLT5zY19pb19ybWFu LCAwLCBpb3NpemUpICE9IDApIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsICJmYWlsZWQgdG8gc2V0 IHVwIEkvTyBybWFuXG4iKTsKKwkJcmV0dXJuIChFTlhJTyk7CisJfQorCXNjLT5zY19tZW1fcm1h bi5ybV90eXBlID0gUk1BTl9BUlJBWTsKKwlzYy0+c2NfbWVtX3JtYW4ucm1fZGVzY3IgPSAiUENJ IE1lbW9yeSI7CisJaWYgKHJtYW5faW5pdCgmc2MtPnNjX21lbV9ybWFuKSAhPSAwIHx8CisJICAg IHJtYW5fbWFuYWdlX3JlZ2lvbigmc2MtPnNjX21lbV9ybWFuLCAwLCBtZW1zaXplKSAhPSAwKSB7 CisJCWRldmljZV9wcmludGYoZGV2LCAiZmFpbGVkIHRvIHNldCB1cCBtZW1vcnkgcm1hblxuIik7 CisJCXJldHVybiAoRU5YSU8pOworCX0KKworCS8qCisJICogRmluZCB0aGUgYWRkcmVzc2VzIG9m IHRoZSB2YXJpb3VzIGJ1cyBzcGFjZXMuICBUaGUgcGh5c2ljYWwKKwkgKiBzdGFydCBhZGRyZXNz ZXMgb2YgdGhlIHJhbmdlcyBhcmUgdGhlIGNvbmZpZ3VyYXRpb24sIEkvTyBhbmQKKwkgKiBtZW1v cnkgaGFuZGxlcy4gIFRoZXJlIHNob3VsZCBub3QgYmUgbXVsdGlwbGUgb25lcyBvZiBvbmUga2lu ZC4KKwkgKi8KKwlucmFuZ2UgPSBPRl9nZXRlbmNwcm9wX2FsbG9jKG5vZGUsICJyYW5nZXMiLCBz aXplb2YoKnJhbmdlcyksCisJICAgICh2b2lkICoqKSZyYW5nZXMpOworCWZvciAoaSA9IDA7IGkg PCBucmFuZ2U7IGkrKykgeworCQlqID0gcmFuZ2VzW2ldLnBjaV9oaSAmIE9GV19QQ0lfUEhZU19I SV9TUEFDRU1BU0s7CisJCWlmIChzYy0+c2NfYmhbal0gIT0gMCkgeworCQkJZGV2aWNlX3ByaW50 ZihkZXYsICJkdXBsaWNhdGUgcmFuZ2UgZm9yIHNwYWNlICVkXG4iLAorCQkJICAgIGopOworCQkJ ZnJlZShyYW5nZXMsIE1fT0ZXUFJPUCk7CisJCQlyZXR1cm4gKEVJTlZBTCk7CisJCX0KKwkJc2Mt PnNjX2JoW2pdID0gcmFuZ2VzW2ldLmhvc3Q7CisJfQorCWZyZWUocmFuZ2VzLCBNX09GV1BST1Ap OworCisJLyoKKwkgKiBNYWtlIHN1cmUgdGhhdCB0aGUgZXhwZWN0ZWQgcmFuZ2VzIGFyZSBhY3R1 YWxseSBwcmVzZW50LgorCSAqIFRoZSBPRldfUENJX01FTTY0IG9uZSBpcyBub3QgY3VycmVudGx5 IHVzZWQuCisJICovCisJaWYgKHNjLT5zY19iaFtPRldfUENJX0NPTkZJR10gPT0gMCkgeworCQlk ZXZpY2VfcHJpbnRmKGRldiwgIm1pc3NpbmcgQ09ORklHIHJhbmdlXG4iKTsKKwkJcmV0dXJuIChF TlhJTyk7CisJfQorCWlmIChzYy0+c2NfYmhbT0ZXX1BDSV9JT10gPT0gMCkgeworCQlkZXZpY2Vf cHJpbnRmKGRldiwgIm1pc3NpbmcgSU8gcmFuZ2VcbiIpOworCQlyZXR1cm4gKEVOWElPKTsKKwl9 CisJaWYgKHNjLT5zY19iaFtPRldfUENJX01FTTMyXSA9PSAwKSB7CisJCWRldmljZV9wcmludGYo ZGV2LCAibWlzc2luZyBNRU0zMiByYW5nZVxuIik7CisJCXJldHVybiAoRU5YSU8pOworCX0KKwor CS8qIEFsbG9jYXRlIG91ciB0YWdzLiAqLworCXNjLT5zY19pb3QgPSBzcGFyYzY0X2FsbG9jX2J1 c190YWcoTlVMTCwgUENJX0lPX0JVU19TUEFDRSk7CisJaWYgKHNjLT5zY19pb3QgPT0gTlVMTCkg eworCQlkZXZpY2VfcHJpbnRmKGRldiwgImNvdWxkIG5vdCBhbGxvY2F0ZSBQQ0kgSS9PIHRhZ1xu Iik7CisJCXJldHVybiAoRU5YSU8pOworCX0KKwlzYy0+c2NfY2ZndCA9IHNwYXJjNjRfYWxsb2Nf YnVzX3RhZyhOVUxMLCBQQ0lfQ09ORklHX0JVU19TUEFDRSk7CisJaWYgKHNjLT5zY19jZmd0ID09 IE5VTEwpIHsKKwkJZGV2aWNlX3ByaW50ZihkZXYsCisJCSAgICAiY291bGQgbm90IGFsbG9jYXRl IFBDSSBjb25maWd1cmF0aW9uIHNwYWNlIHRhZ1xuIik7CisJCXJldHVybiAoRU5YSU8pOworCX0K KworCS8qCisJICogR2V0IHRoZSBidXMgcmFuZ2UgZnJvbSB0aGUgZmlybXdhcmUuCisJICovCisJ aSA9IE9GX2dldHByb3Aobm9kZSwgImJ1cy1yYW5nZSIsICh2b2lkICopcHJvcF9hcnJheSwKKwkg ICAgc2l6ZW9mKHByb3BfYXJyYXkpKTsKKwlpZiAoaSA9PSAtMSkgeworCQlkZXZpY2VfcHJpbnRm KGRldiwgImNvdWxkIG5vdCBnZXQgYnVzLXJhbmdlXG4iKTsKKwkJcmV0dXJuIChFTlhJTyk7CisJ fQorCWlmIChpICE9IHNpemVvZihwcm9wX2FycmF5KSkgeworCQlkZXZpY2VfcHJpbnRmKGRldiwg ImJyb2tlbiBidXMtcmFuZ2UgKCVkKSIsIGkpOworCQlyZXR1cm4gKEVJTlZBTCk7CisJfQorCXNj LT5zY19zZWNidXMgPSBwcm9wX2FycmF5WzBdOworCXNjLT5zY19zdWJidXMgPSBwcm9wX2FycmF5 WzFdOworCWlmIChib290dmVyYm9zZSAhPSAwKQorCQlkZXZpY2VfcHJpbnRmKGRldiwgImJ1cyBy YW5nZSAldSB0byAldTsgUENJIGJ1cyAlZFxuIiwKKwkJICAgIHNjLT5zY19zZWNidXMsIHNjLT5z Y19zdWJidXMsIHNjLT5zY19zZWNidXMpOworCisJb2Z3X2J1c19zZXR1cF9paW5mbyhub2RlLCAm c2MtPnNjX3BjaV9paW5mbywgc2l6ZW9mKG9md19wY2lfaW50cl90KSk7CisKKwlyZXR1cm4gKDAp OworfQorCit1aW50MzJfdAorb2Z3X3BjaV9yZWFkX2NvbmZpZ19jb21tb24oZGV2aWNlX3QgZGV2 LCB1X2ludCByZWdtYXgsIHVfbG9uZyBvZmZzZXQsCisgICAgdV9pbnQgYnVzLCB1X2ludCBzbG90 LCB1X2ludCBmdW5jLCB1X2ludCByZWcsIGludCB3aWR0aCkKK3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9z b2Z0YyAqc2M7CisJYnVzX3NwYWNlX2hhbmRsZV90IGJoOworCXVpbnQzMl90IHIsIHdyZDsKKwlp bnQgaTsKKwl1aW50MTZfdCBzaHJ0OworCXVpbnQ4X3QgYnl0ZTsKKworCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhkZXYpOworCWlmIChidXMgPCBzYy0+c2Nfc2VjYnVzIHx8IGJ1cyA+IHNjLT5zY19z dWJidXMgfHwKKwkgICAgc2xvdCA+IFBDSV9TTE9UTUFYIHx8IGZ1bmMgPiBQQ0lfRlVOQ01BWCB8 fCByZWcgPiByZWdtYXgpCisJCXJldHVybiAoLTEpOworCisJYmggPSBzYy0+c2NfYmhbT0ZXX1BD SV9DT05GSUddOworCXN3aXRjaCAod2lkdGgpIHsKKwljYXNlIDE6CisJCWkgPSBidXNfc3BhY2Vf cGVla18xKHNjLT5zY19jZmd0LCBiaCwgb2Zmc2V0LCAmYnl0ZSk7CisJCXIgPSBieXRlOworCQli cmVhazsKKwljYXNlIDI6CisJCWkgPSBidXNfc3BhY2VfcGVla18yKHNjLT5zY19jZmd0LCBiaCwg b2Zmc2V0LCAmc2hydCk7CisJCXIgPSBzaHJ0OworCQlicmVhazsKKwljYXNlIDQ6CisJCWkgPSBi dXNfc3BhY2VfcGVla180KHNjLT5zY19jZmd0LCBiaCwgb2Zmc2V0LCAmd3JkKTsKKwkJciA9IHdy ZDsKKwkJYnJlYWs7CisJZGVmYXVsdDoKKwkJcGFuaWMoIiVzOiBiYWQgd2lkdGggJWQiLCBfX2Z1 bmNfXywgd2lkdGgpOworCQkvKiBOT1RSRUFDSEVEICovCisJfQorCisJaWYgKGkpIHsKKyNpZmRl ZiBPRldfUENJX0RFQlVHCisJCXByaW50ZigiJXM6IHJlYWQgZGF0YSBlcnJvciByZWFkaW5nOiAl ZC4lZC4lZDogMHgleFxuIiwKKwkJICAgIF9fZnVuY19fLCBidXMsIHNsb3QsIGZ1bmMsIHJlZyk7 CisjZW5kaWYKKwkJciA9IC0xOworCX0KKwlyZXR1cm4gKHIpOworfQorCit2b2lkCitvZndfcGNp X3dyaXRlX2NvbmZpZ19jb21tb24oZGV2aWNlX3QgZGV2LCB1X2ludCByZWdtYXgsIHVfbG9uZyBv ZmZzZXQsCisgICAgdV9pbnQgYnVzLCB1X2ludCBzbG90LCB1X2ludCBmdW5jLCB1X2ludCByZWcs IHVpbnQzMl90IHZhbCwgaW50IHdpZHRoKQoreworCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsK KwlidXNfc3BhY2VfaGFuZGxlX3QgYmg7CisKKwlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsK KwlpZiAoYnVzIDwgc2MtPnNjX3NlY2J1cyB8fCBidXMgPiBzYy0+c2Nfc3ViYnVzIHx8CisJICAg IHNsb3QgPiBQQ0lfU0xPVE1BWCB8fCBmdW5jID4gUENJX0ZVTkNNQVggfHwgcmVnID4gcmVnbWF4 KQorCQlyZXR1cm47CisKKwliaCA9IHNjLT5zY19iaFtPRldfUENJX0NPTkZJR107CisJc3dpdGNo ICh3aWR0aCkgeworCWNhc2UgMToKKwkJYnVzX3NwYWNlX3dyaXRlXzEoc2MtPnNjX2NmZ3QsIGJo LCBvZmZzZXQsIHZhbCk7CisJCWJyZWFrOworCWNhc2UgMjoKKwkJYnVzX3NwYWNlX3dyaXRlXzIo c2MtPnNjX2NmZ3QsIGJoLCBvZmZzZXQsIHZhbCk7CisJCWJyZWFrOworCWNhc2UgNDoKKwkJYnVz X3NwYWNlX3dyaXRlXzQoc2MtPnNjX2NmZ3QsIGJoLCBvZmZzZXQsIHZhbCk7CisJCWJyZWFrOwor CWRlZmF1bHQ6CisJCXBhbmljKCIlczogYmFkIHdpZHRoICVkIiwgX19mdW5jX18sIHdpZHRoKTsK KwkJLyogTk9UUkVBQ0hFRCAqLworCX0KK30KKworb2Z3X3BjaV9pbnRyX3QKK29md19wY2lfcm91 dGVfaW50ZXJydXB0X2NvbW1vbihkZXZpY2VfdCBicmlkZ2UsIGRldmljZV90IGRldiwgaW50IHBp bikKK3sKKwlzdHJ1Y3Qgb2Z3X3BjaV9zb2Z0YyAqc2M7CisJc3RydWN0IG9md19wY2lfcmVnaXN0 ZXIgcmVnOworCW9md19wY2lfaW50cl90IHBpbnRyLCBtaW50cjsKKworCXNjID0gZGV2aWNlX2dl dF9zb2Z0YyhicmlkZ2UpOworCXBpbnRyID0gcGluOworCWlmIChvZndfYnVzX2xvb2t1cF9pbWFw KG9md19idXNfZ2V0X25vZGUoZGV2KSwgJnNjLT5zY19wY2lfaWluZm8sCisJICAgICZyZWcsIHNp emVvZihyZWcpLCAmcGludHIsIHNpemVvZihwaW50ciksICZtaW50ciwgc2l6ZW9mKG1pbnRyKSwK KwkgICAgTlVMTCkgIT0gMCkKKwkJcmV0dXJuIChtaW50cik7CisJcmV0dXJuIChQQ0lfSU5WQUxJ RF9JUlEpOworfQorCit2b2lkCitvZndfcGNpX2RtYW1hcF9zeW5jX3N0c3Rfb3JkZXJfY29tbW9u KHZvaWQpCit7CisJc3RhdGljIHVfY2hhciBidWZbVklTX0JMT0NLU0laRV0gX19hbGlnbmVkKFZJ U19CTE9DS1NJWkUpOworCXJlZ2lzdGVyX3QgcmVnLCBzOworCisJcyA9IGludHJfZGlzYWJsZSgp OworCXJlZyA9IHJkKGZwcnMpOworCXdyKGZwcnMsIHJlZyB8IEZQUlNfRkVGLCAwKTsKKwlfX2Fz bSBfX3ZvbGF0aWxlKCJzdGRhICUlZjAsIFslMF0gJTEiCisJICAgIDogOiAiciIgKGJ1ZiksICJu IiAoQVNJX0JMS19DT01NSVRfUykpOworCW1lbWJhcihTeW5jKTsKKwl3cihmcHJzLCByZWcsIDAp OworCWludHJfcmVzdG9yZShzKTsKK30KKworaW50CitzcGFyYzY0X29md19wY2lfYWN0aXZhdGVf cmVzb3VyY2UoZGV2aWNlX3QgYnVzLCBkZXZpY2VfdCBjaGlsZCwgaW50IHR5cGUsIGludCByaWQs CisgICAgc3RydWN0IHJlc291cmNlICpyKQoreworCXN0cnVjdCBvZndfcGNpX3NvZnRjICpzYzsK KwlzdHJ1Y3QgYnVzX3NwYWNlX3RhZyAqdGFnOworCisJc2MgPSBkZXZpY2VfZ2V0X3NvZnRjKGJ1 cyk7CisJc3dpdGNoICh0eXBlKSB7CisJY2FzZSBTWVNfUkVTX0lSUToKKwkJcmV0dXJuIChidXNf Z2VuZXJpY19hY3RpdmF0ZV9yZXNvdXJjZShidXMsIGNoaWxkLCB0eXBlLCByaWQsCisJCSAgICBy KSk7CisJY2FzZSBTWVNfUkVTX01FTU9SWToKKwkJdGFnID0gc3BhcmM2NF9hbGxvY19idXNfdGFn KHIsIFBDSV9NRU1PUllfQlVTX1NQQUNFKTsKKwkJaWYgKHRhZyA9PSBOVUxMKQorCQkJcmV0dXJu IChFTk9NRU0pOworCQlybWFuX3NldF9idXN0YWcociwgdGFnKTsKKwkJcm1hbl9zZXRfYnVzaGFu ZGxlKHIsIHNjLT5zY19iaFtPRldfUENJX01FTTMyXSArCisJCSAgICBybWFuX2dldF9zdGFydChy KSk7CisJCWJyZWFrOworCWNhc2UgU1lTX1JFU19JT1BPUlQ6CisJCXJtYW5fc2V0X2J1c3RhZyhy LCBzYy0+c2NfaW90KTsKKwkJcm1hbl9zZXRfYnVzaGFuZGxlKHIsIHNjLT5zY19iaFtPRldfUENJ X0lPXSArCisJCSAgICBybWFuX2dldF9zdGFydChyKSk7CisJCWJyZWFrOworCX0KKwlyZXR1cm4g KHJtYW5fYWN0aXZhdGVfcmVzb3VyY2UocikpOworfQorCitpbnQKK3NwYXJjNjRfb2Z3X3BjaV9k ZWFjdGl2YXRlX3Jlc291cmNlKGRldmljZV90IGJ1cywgZGV2aWNlX3QgY2hpbGQsCisgICAgaW50 IHR5cGUsIGludCByaWQsIHN0cnVjdCByZXNvdXJjZSAqcikKK3sKKworICAgICAgICByZXR1cm4g KGJ1c19nZW5lcmljX2RlYWN0aXZhdGVfcmVzb3VyY2UoYnVzLCBjaGlsZCwgdHlwZSwgcmlkLCBy KSk7Cit9CmRpZmYgLS1naXQgYS9zeXMvc3BhcmM2NC9zcGFyYzY0L2pidXNwcG0uYyBiL3N5cy9z cGFyYzY0L3NwYXJjNjQvamJ1c3BwbS5jCmluZGV4IDEyZjlmMGYuLjBiNDEwNTQgMTAwNjQ0Ci0t LSBhL3N5cy9zcGFyYzY0L3NwYXJjNjQvamJ1c3BwbS5jCisrKyBiL3N5cy9zcGFyYzY0L3NwYXJj NjQvamJ1c3BwbS5jCkBAIC0zNSwxMyArMzUsMTQgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwog I2luY2x1ZGUgPHN5cy9yZXNvdXJjZS5oPgogI2luY2x1ZGUgPHN5cy9ybWFuLmg+CiAKKyNpbmNs dWRlIDxkZXYvb2Z3L29md19idXNfc3Vici5oPgogI2luY2x1ZGUgPGRldi9vZncvb2Z3X2J1cy5o PgogCiAjaW5jbHVkZSA8bWFjaGluZS9idXMuaD4KICNpbmNsdWRlIDxtYWNoaW5lL3Jlc291cmNl Lmg+CiAKICNpZiAxCi0jaW5jbHVkZSA8c3BhcmM2NC9wY2kvb2Z3X3BjaS5oPgorI2luY2x1ZGUg PGRldi9vZncvb2Z3X3BjaS5oPgogI2VuZGlmCiAKICNkZWZpbmUJSkJVU1BQTV9OUkVHCTIKZGlm ZiAtLWdpdCBhL3N5cy9zcGFyYzY0L3NwYXJjNjQvb2Z3X21hY2hkZXAuYyBiL3N5cy9zcGFyYzY0 L3NwYXJjNjQvb2Z3X21hY2hkZXAuYwppbmRleCA3ZmNmNWM4Li5hOWI0MGY4IDEwMDY0NAotLS0g YS9zeXMvc3BhcmM2NC9zcGFyYzY0L29md19tYWNoZGVwLmMKKysrIGIvc3lzL3NwYXJjNjQvc3Bh cmM2NC9vZndfbWFjaGRlcC5jCkBAIC0zNCwxMiArMzQsMTQgQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgogI2luY2x1ZGUgPHN5cy9idXMuaD4KICNpbmNs dWRlIDxzeXMvc3lzdG0uaD4KKyNpbmNsdWRlIDxzeXMvcm1hbi5oPgogCiAjaW5jbHVkZSA8bmV0 L2V0aGVybmV0Lmg+CiAKKyNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+CiAjaW5jbHVkZSA8 ZGV2L29mdy9vZndfYnVzLmg+CisjaW5jbHVkZSA8ZGV2L29mdy9vZndfYnVzX3N1YnIuaD4KICNp bmNsdWRlIDxkZXYvb2Z3L29md19wY2kuaD4KLSNpbmNsdWRlIDxkZXYvb2Z3L29wZW5maXJtLmg+ CiAKICNpbmNsdWRlIDxtYWNoaW5lL2J1cy5oPgogI2luY2x1ZGUgPG1hY2hpbmUvaWRwcm9tLmg+ Cg== --047d7bd76bea87df0b052cfd99e4-- From owner-freebsd-ppc@freebsd.org Tue Mar 1 17:29:13 2016 Return-Path: Delivered-To: freebsd-ppc@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 18CBAABDF3D for ; Tue, 1 Mar 2016 17:29:13 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8A081BD4 for ; Tue, 1 Mar 2016 17:29:12 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id c3so174954940vkb.3 for ; Tue, 01 Mar 2016 09:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=uzLNKe1J2Eilem8KzrY4cownrbLCKcYFoU0EkH+B79s=; b=Cxd77hvbO7kcYIlznBSOi7RiIYGeFrFk4WnMjBdGj+5Ts2IGPjD0WLirPoHhFUOx3y vHipBlt1bEyI+TNk1duPbxaukB1i7g/84qjL5ur8AnNoUz+vH8XT2kuDDuP4v8VkQvSz MJFFn8Y9teRfLqzpilibfcKgrK1nVcDgYcTYlnP3ky1Hjaj9kjZOxsohpo7GQYInGCPu i2LtuXw3TsVI4no4ZFW5lpYmM57wRwvdtXc1SABbBTVp6/Dbsg1oEgoiIqgVGwtUWlW7 U4agHjXAobrkhHDkjOHp5HgopK7OS1b6zMp+LjguEEyiLzatdqCSWibgtDYnFnIpJHkF 6yGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=uzLNKe1J2Eilem8KzrY4cownrbLCKcYFoU0EkH+B79s=; b=bbhBDnYHvyZnhGN38MyPYU8ZrnTQ+vqEQ5B5p6IRULS9aWLqpryS/8qzuChpekGqpR aGljI5JIQdztH/aM5uYZlm7Jfb4YCl5oOXTNYM6rNnhzJrDoNoWGoWB2yRQk88QKsKFt AvPU1i1JPgJ/A0KazBySFD0FhLHuV2dBYJFu/nyFF8AcS5vqOMCufBS4eaXSY8oJSs03 2CNbyYuNm4yxh+uP2ZzzP7NJ53ymy8rTx8x3zaZqJSi4MPaUKjxQlX8b896hXJVF26A2 gGTUBtmC8wpqBrni9lKqIaVkL/V1D5UokcHVaoBwz4EvUfrhHyJq2xw0HOGxGsFfBvy6 Z+gA== X-Gm-Message-State: AD7BkJLQvV0rfrsHeJ+PRVJF4DHKpC0APd7oyddRy/kiilMgQfV0iTVeB0CIWOpNZdnfWQv1B3wnuNMPQY5rdQ== MIME-Version: 1.0 X-Received: by 10.31.49.207 with SMTP id x198mr16598502vkx.1.1456853351875; Tue, 01 Mar 2016 09:29:11 -0800 (PST) Received: by 10.103.37.196 with HTTP; Tue, 1 Mar 2016 09:29:11 -0800 (PST) In-Reply-To: <3qF0t51zMJz1cXKx@baobab.bilink.it> References: <3qF0t51zMJz1cXKx@baobab.bilink.it> Date: Tue, 1 Mar 2016 12:29:11 -0500 Message-ID: Subject: Re: PPC boot0 From: Joe Nosay To: Luciano Mannucci Cc: FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:29:13 -0000 What machine do you have? On Tue, Mar 1, 2016 at 9:18 AM, Luciano Mannucci wrote: > > I'm still unable to install 11.0 CURRENT under IBM KVM. > It does install but it doesnt boot. > I'm trying to install /boot0 manually but I can't find it on the ISO > DVD. Maybe I can extract it via dd from the iso file, if only I knew > the precise size and offset. > Where may I find this info? > > Thanks to everyone, > > Luciano. > -- > /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) > \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 > X AGAINST HTML MAIL / E-MAIL: posthamster@sublink.sublink.ORG > / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@freebsd.org Tue Mar 1 17:38:14 2016 Return-Path: Delivered-To: freebsd-ppc@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 89C0EABE463 for ; Tue, 1 Mar 2016 17:38:14 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4466F1055 for ; Tue, 1 Mar 2016 17:38:14 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id e185so175159464vkb.1 for ; Tue, 01 Mar 2016 09:38:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=TmMeK9I0RtUIhgCkoTS9jfcxBTYP9xCejPJXzRJCbuk=; b=GP7OtkRlIUCo1Aczniob6Uw5izfcKbf6mxylUMlTpjiuxZCNmkXf8aD8o90haGNfJV 2aMcUAcGvRgLHCs59cFSVa8rMIesB24GLeZz3OHojEqrTFg5iOVPtwPdU7TYoYarKqCp /k4K4uAUzvpc81Nab3KXdEcrVrWBoqDr9KthfKQcaczFIQYy5Tw7SttobQAZxZ4qKqNv DMM3+xMfp6agD2sr/NbPO0MJeEQbAmxSn056ag5WfAffFZkSzzed5MTpN0XkL+nanA8h C4+ktv7za9wHzyeuNSsO9Dqx1cfkNiBPJbmDdm4Xy+TrMRx34d9152srUxcr4dU8EHrV crfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=TmMeK9I0RtUIhgCkoTS9jfcxBTYP9xCejPJXzRJCbuk=; b=Gc8jDBXSBsyN3f+5jBH3QeTfv9XJmlu9lWDf6Igg5maYaeZcMaVjHxzy2yKLa/W3gR Gu5Y01YXUSGlGBDzFEzHQRfCcyy3D1JZj26KjIAYYpn1u+S5AXeVovZ1ZOLqVdRFvQ6s vyS9512fNAJY/btBdEEevUuwormSBU2xMQDyLqoUUP76RpKuLwqojXhP2Wbf/qlAJ/8l 7JKY1Vx/zr2jyiqpEO/Ry5soNAu6m47K8EmeGACGUNW1YhGaRTVGwW9mYtl7a44K6EAk L53nglAMeMdJ5EY13vnLFrylFI3MX55T2S55Vb+9kIxcY3QsJcwPJqhTgapmkzlLmaFH bQ4w== X-Gm-Message-State: AD7BkJLCyQRCjvpbCX8pRLvBUrCuFsU3yigcEtEvQfLlrlvRtmfHCLDaMS7BbADcplaq32uo8mtd2OkoGAkJag== MIME-Version: 1.0 X-Received: by 10.31.141.10 with SMTP id p10mr17023978vkd.93.1456853893437; Tue, 01 Mar 2016 09:38:13 -0800 (PST) Received: by 10.103.37.196 with HTTP; Tue, 1 Mar 2016 09:38:13 -0800 (PST) In-Reply-To: <56D458AC.3020002@idempot.net> References: <6d087c44f7aca144efdd6e5967cf8417@openmailbox.org> <56D458AC.3020002@idempot.net> Date: Tue, 1 Mar 2016 12:38:13 -0500 Message-ID: Subject: Fwd: socppc q: How big a challenge would it be to support QorIQ PPC CPU:s (used for instance in MicroTik RB1100AHx2 routerboard)? From: Joe Nosay To: FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:38:14 -0000 I'm posting this towards the FreeBSD - forwarding, that is - PowerPC mailing list. Hopefully, there will be someone that can - I don't have permissions - share the codebase with you. ---------- Forwarded message ---------- From: Matthew Weigel Date: Mon, Feb 29, 2016 at 9:41 AM Subject: Re: socppc q: How big a challenge would it be to support QorIQ PPC CPU:s (used for instance in MicroTik RB1100AHx2 routerboard)? To: ppc@openbsd.org On 2/29/16 12:28 AM, Tinker wrote: > Hi, > > Just for me to get an idea, how complex would it be to support Freescale > QorIQ such as the P2020 used in http://routerboard.com/RB1100AHx2 , or > P4080 or P5020? > The P2 series poses more significant problems, the e500v2 core in them uses a different FPU with different instructions- it would basically be a different userland platform, you couldn't share binaries between an RB600-A and a RB1100-AHx2. The P3 and P4 series (which includes the P2040, confusingly) use the e500mc core, which has userland compatibility with the existing OpenBSD powerpc userland. The P5 series uses the e5500 core which adds some 64-bit things but is backward compatible (if memory serves then you could even expect a kernel compiled for e500mc to run on an e5500, but I'm not 100% certain). The harder thing is to find something out there that uses a P2040, P2041, P3041, or P4080 to get started with. -- Matthew Weigel hacker unique & idempot . ent From owner-freebsd-ppc@freebsd.org Tue Mar 1 17:47:37 2016 Return-Path: Delivered-To: freebsd-ppc@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 23C63ABEA2B for ; Tue, 1 Mar 2016 17:47:37 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2E5A180C; Tue, 1 Mar 2016 17:47:36 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x22d.google.com with SMTP id e6so175359710vkh.2; Tue, 01 Mar 2016 09:47:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=Yj4H3sgrM1X5kQkMadBBqjlDSSguGKWKBj900epUUsk=; b=sRT2heJrqMztmUn9uj3rFKTabfqN5QAfLnFUmY8eaVOiZp5tTkr0EbIEyR+MFVlgp4 zeF4b0mHMP3TaJoOyJrFUY04ArXz0V6qOKPDkYmVlD8+6YQqscJ3XyvMsm4vnl5Suekz InlDFD7Bx56fiZHD9ZBaRFrot1Z6dYt61rZYSoN2+8XMuMfY8UUt4eal07eKrw9MemRb xKQ0yBz/Zf84Vw+7uqolrDcB5HCyb8GVzJO0INviAWcnbm03nX9eCx7NzfJtEeT5jVem N+lYWFoUacz2pmf3IxlVrO4E/jmiFIFHttqy1KEhsMCaHCUlMWreUh68+bAL2r2ti/CM QLig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=Yj4H3sgrM1X5kQkMadBBqjlDSSguGKWKBj900epUUsk=; b=g1MHnox+6E9vEqovpALFp3BxWFllyDy09mIZbPVC0kbYDaf9yXNyEnMa/tcxJ+mRhD YAXNgKgau5u1vvJiHGzmBlU3YSn/0Im0L/7iONAOBJJPzDr6/tm+k1LuV0of1Otck5Pv VSVZ4gJIjQ+pUr03JFuZ3RSFsldMUKYf/vDPua8MQDyYDNjHWIgD0rirQHED7ZU4/HsS lkOO0Uw/oSEgPq2LKOexSkoZx0UsfosgapywQvmDTeSc8eF2u1Ph0pru1IXEkhifGLB9 BZW4jSoUr9NH+0vo8NPSanGTEh/ouvAcn65TgCiIXw8R32GkC6GI3HhCTmOsI8tks7e8 MXcQ== X-Gm-Message-State: AD7BkJI3BAvXiwQ/sdO+5ZiL1ZRuHKtQS1wZtL2KJlmE6vaUZcfxTS+BJRlAu57PffNCyxFTy5slSe+nWy/6ng== MIME-Version: 1.0 X-Received: by 10.31.132.140 with SMTP id g134mr16759293vkd.94.1456854455854; Tue, 01 Mar 2016 09:47:35 -0800 (PST) Received: by 10.103.37.196 with HTTP; Tue, 1 Mar 2016 09:47:35 -0800 (PST) In-Reply-To: <25667.1456727424@cvs.openbsd.org> References: <022bdbbe3337a338996bd649c1084a77@openmailbox.org> <25667.1456727424@cvs.openbsd.org> Date: Tue, 1 Mar 2016 12:47:35 -0500 Message-ID: Subject: Fwd: What about the IBM POWER7 and POWER8 platforms, did anyone ever think about porting these to OpenBSD? From: Joe Nosay To: Adrian Chadd , FreeBSD PowerPC ML Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:47:37 -0000 I'm doing this so that you - the OpenBSD PowerPC team - will have others to aid and assist you. There is no reason why the codebase should remain just with one. ---------- Forwarded message ---------- From: Theo de Raadt Date: Mon, Feb 29, 2016 at 1:30 AM Subject: Re: What about the IBM POWER7 and POWER8 platforms, did anyone ever think about porting these to OpenBSD? To: Tinker Cc: ppc@openbsd.org > Reading through all docs and email archives for OpenBSD, I cannot find a > single mentioning of the IBM POWER processors, e.g., the POWER7 such as > IBM Power 720 Express [1], or the Tyan BP012 or IBM S812L which feature > Power8 [2]. > > Power8 is a BIG DEAL, or at least it should be, e.g. see > http://www.v3.co.uk/v3-uk/news/2413565/ibm-claims-power8-systems-beat-x86-for-performance-per-dollar > - it's faster than Xeons. > > And perhaps safer? If you send me a private mail and I'll give you addresses to get machines delivered to. I'd make a guess that 3-4 people need machines to ensure progress. Thanks for your offer. From owner-freebsd-ppc@freebsd.org Tue Mar 1 17:55:52 2016 Return-Path: Delivered-To: freebsd-ppc@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 D226EABEEFA for ; Tue, 1 Mar 2016 17:55:52 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D6151DCE; Tue, 1 Mar 2016 17:55:52 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x236.google.com with SMTP id e6so175619390vkh.2; Tue, 01 Mar 2016 09:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=jz/ud3I/NezrXVVoeY6eMYcCeFj8pyXNtdwz3ji66+A=; b=X+zjetgJYiqF+dg949rj6M/IzIQeosaNxat6k5/kfJQPj6Tn9CV6w8DY7sIGqaU9aa aMc3Rcl52XK+ZZoEu5Mu85SQEsS6Ef+EqQ1RgvVF/nq3chCTrilb3i9HWHBScYQJRB6k VH8LNukwBYqTsvEdewpqTjEu8jPMnsNmyRf4HSzlL+P1Jf2qkj0VvnX/lE9eCFUFzlCM sXWJ/Rcr3rOYEbNaPGhGn9SnIBpfvAuDE0nBSajnGu0k81sPwNI+TGSptLGvnpOAq01u /0rwwUevfVARfULu/FwlTyx3ST0XdenYdhnWGmUI9BHhbrBvCCvZRbwkUbsjEmXk7nsD 15ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=jz/ud3I/NezrXVVoeY6eMYcCeFj8pyXNtdwz3ji66+A=; b=eSX+bHHyl1XPLnu+TLCfmrwknt9b8ZtC25enxWw4zt3v+VmXkIDHTp2FnUIfYcsKiX 6ZW9rS1wh+3VhiQK2V6wBVjgjdrwQXFTvfvz7pq/Svbki2ZZwAj0JbXxX5o1fBJjS7Zt JAkyyUfoibxhZarHnxalqKx4bqjucEMKKtz6O2seXRVP31Y0lcv2jKMKhw6PNyHBBZkk nm3HBhIde4FXzNRN2gKeMok7x9BAnJyM5H07k8JzAF9XPdA+uaSx5aWZr3y6o0NQxDhK Q4BpoT9EitLAV3vxRkwwHBkK92Zrn1Ow4gYgYHLhZGJDhUTjQ2f89dO1XQqI2bjHxTy4 yp/Q== X-Gm-Message-State: AD7BkJK0QWEIkHs4Fq8GZSREuPJEnlquO5BwH2EgaYTAnJqoRSXce4gVsYE8eufklfAaYQRY4C/5NMhNCSJbyA== MIME-Version: 1.0 X-Received: by 10.31.151.75 with SMTP id z72mr14778943vkd.104.1456854951736; Tue, 01 Mar 2016 09:55:51 -0800 (PST) Received: by 10.103.37.196 with HTTP; Tue, 1 Mar 2016 09:55:51 -0800 (PST) In-Reply-To: <3qF5Yt3W9tzRRqY@baobab.bilink.it> References: <3qF0t51zMJz1cXKx@baobab.bilink.it> <3qF5Yt3W9tzRRqY@baobab.bilink.it> Date: Tue, 1 Mar 2016 12:55:51 -0500 Message-ID: Subject: Fwd: PPC boot0 From: Joe Nosay To: FreeBSD PowerPC ML , Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:55:53 -0000 Apologies to Adrian and the list. I believe that these two - look at Adrian's blog - have the solution. I need to start keeping certain mails for the references. ---------- Forwarded message ---------- From: Luciano Mannucci Date: Tue, Mar 1, 2016 at 12:49 PM Subject: Re: PPC boot0 To: Joe Nosay On Tue, 1 Mar 2016 12:29:11 -0500 Joe Nosay wrote: > What machine do you have? A couple of IBM S822L, running IBM PowerKVM, which should be a clone of RH Fedora 20 for PPC64 something. Luciano -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL / E-MAIL: posthamster@sublink.sublink.ORG / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ From owner-freebsd-ppc@freebsd.org Tue Mar 1 18:03:44 2016 Return-Path: Delivered-To: freebsd-ppc@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 296C6ABF409 for ; Tue, 1 Mar 2016 18:03:44 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8F5F15E3; Tue, 1 Mar 2016 18:03:43 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id k196so177078401vka.0; Tue, 01 Mar 2016 10:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=GCQ1/QSmCPXsMj4xYEvDph7XWrElkyA7AzW04saLM1U=; b=XCYO1ivww7qvyU93QgqBq+xBvb4qxX+dr8sorv74xuk8aDD3rwoWQ2XSao+vgifOw1 zHfSrMNtGKCJoTtCIdf3pNV0sRzDjrzbrGg2MfhpzAorLh80Bv+GMVGKlsa7BuVeyJvN rxFnmgvhI5UdZ5gaLfmyAYkD0JQybgnfFj07u+KF1sqOUvqeI7HQ4xeqmzMPqdx6HFkD QTeFberQTQsAMr5VdcreLHQlJwTQ9xoGoPx7V+DSRMt2uC1fm47qtOKAahIeXY8M+LR0 8xAQ1A/j6ySzly0JYOgQO3jnjm8LqA23X979mLeOvJ7zVN6htxdaviN3vpEnwvP2HAPV I9OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=GCQ1/QSmCPXsMj4xYEvDph7XWrElkyA7AzW04saLM1U=; b=FKLZOckPVrA9okdqj8ybcq6AZ4xexY+Nal6I8IMqPHwk2erPhaT0NL2JS5oBr6/YXI YCDSfxy+cb645KNaJ7PqSfGR0gN2XYZnvCX+dS1TSEx7VA1JdiJ8LPd+8VTnn5npi69Z vq7IYoPRSoIKHZvGa6rTOR1xewyArZxtZOQ1j+2Vba8t+C8/ugwk9r3n1N9mY1Zvwq8z fyJhcm6xlH85zsjSFi7gfbNXa17DELFIBpWAKTPKGY+gPCsZKeU2xMaP2q2JqQEWhi+a NHkrD6bBQNeXvkjgbDAsHbyD+aCnMyrVIJRiKtzgeHKvOFaTMr1DxyjX0kXv1uRXvjQ0 hmNw== X-Gm-Message-State: AD7BkJLB8qqTN93pW5TkHpRKN2TDfOxVP1WCT8fILKuSzrUxjWNOY6DKlBPW/gZjxkR7PRT3waMGXj2dIOaJ3w== MIME-Version: 1.0 X-Received: by 10.31.141.10 with SMTP id p10mr17133676vkd.93.1456855423014; Tue, 01 Mar 2016 10:03:43 -0800 (PST) Received: by 10.103.37.196 with HTTP; Tue, 1 Mar 2016 10:03:42 -0800 (PST) In-Reply-To: <3qF5Yt3W9tzRRqY@baobab.bilink.it> References: <3qF0t51zMJz1cXKx@baobab.bilink.it> <3qF5Yt3W9tzRRqY@baobab.bilink.it> Date: Tue, 1 Mar 2016 13:03:42 -0500 Message-ID: Subject: Fwd: PPC boot0 From: Joe Nosay To: FreeBSD PowerPC ML , Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:03:44 -0000 Apologies to Adrian and the list. I believe that these two - look at Adrian's blog http://adrianchadd.blogspot.com/2015/02/freebsd-on-power8-its-alive.html?showComment=1456854322416#c8232073838862258082 ---------- Forwarded message ---------- From: Luciano Mannucci Date: Tue, Mar 1, 2016 at 12:49 PM Subject: Re: PPC boot0 To: Joe Nosay On Tue, 1 Mar 2016 12:29:11 -0500 Joe Nosay wrote: > What machine do you have? A couple of IBM S822L, running IBM PowerKVM, which should be a clone of RH Fedora 20 for PPC64 something. Luciano -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL / E-MAIL: posthamster@sublink.sublink.ORG / \ AND POSTINGS / WWW: http://www.lesassaie.IT/ From owner-freebsd-ppc@freebsd.org Wed Mar 2 17:23:16 2016 Return-Path: Delivered-To: freebsd-ppc@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 A4D38AC17A0 for ; Wed, 2 Mar 2016 17:23:16 +0000 (UTC) (envelope-from andy.silva@snscommunication.com) Received: from mailer238.gate85.rs.smtp.com (mailer238.gate85.rs.smtp.com [74.91.85.238]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EDB51A3A for ; Wed, 2 Mar 2016 17:23:16 +0000 (UTC) (envelope-from andy.silva@snscommunication.com) X-MSFBL: eyJnIjoiU25zdGVsZWNvbV9kZWRpY2F0ZWRfcG9vbCIsImIiOiI3NF85MV84NV8y MzgiLCJyIjoiZnJlZWJzZC1wcGNAZnJlZWJzZC5vcmcifQ== Received: from [192.168.80.21] ([192.168.80.21:52678] helo=rs-ord-mta02-1.smtp.com) by rs-ord-mta04-3.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTP id 95/78-07610-08127D65; Wed, 02 Mar 2016 17:23:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1456939392; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=jN/qemq/TEawe4XFVzCPszGsbvVzg5Ig0obqTsXlBBQ=; b=vjGGFmXfoNPz/tRMJYYW+WZdHR6sMlJQaOdmNHMNVuWcBSabkKZkoZfDLkHQelZH Hy+TcEAUy6FpVGrGo6Oqotg1Dg3BnxXk6VAMTBthyqQO3FKP+Z7ansmSaE41v5G9 OaW5h/qwW9toULllMY1TRsYY0EoneU1SYl3RNWVsLQA=; Received: from [154.20.125.37] ([154.20.125.37:25084] helo=d154-20-125-37.bchsia.telus.net) by rs-ord-mta02-1.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id B6/68-09147-08127D65; Wed, 02 Mar 2016 17:23:12 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snscommunication.com To: freebsd-ppc@freebsd.org Subject: The 5G Wireless Ecosystem: 2016 - 2030 - Technologies, Applications, Verticals, Strategies & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Wed, 2 Mar 2016 09:23:09 -0800 Message-ID: <59244189465282793432242@Ankur> X-SMTPCOM-Spam-Policy: SMTP.com is a paid relay service. We do not tolerate UCE of any kind. Please report it ASAP to abuse@smtp.com X-SMTPCOM-Tracking-Number: 4a2a10b1-ea7a-4e5f-8a07-a227a5684b3a X-SMTPCOM-Sender-ID: 6008902 Feedback-ID: 6008902:SMTPCOM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 17:23:16 -0000 The 5G Wireless Ecosystem: 2016 - 2030 - Technologies, Applications, Vertic= als, Strategies & Forecasts Hello=20 I wanted to bring to your attention the latest SNS Research report in which= you might be interested, " The 5G Wireless Ecosystem: 2016 =96 2030 =96 Te= chnologies, Applications, Verticals, Strategies & Forecasts."=20 I believe this report will be highly applicable for you. If you would like = to see the report sample or have any questions, please let me know. =20 Key Questions Answered: =20 The report provides answers to the following key questions: How much will vendors and operators invest in 5G R&D commitments=3F What will be the number of 5G subscriptions in 2020 and at what rate will i= t grow=3F What will be the key applications of 5G networks=3F What trends, challenges and barriers will influence the development and ado= ption of 5G=3F Which regions and countries will be the first to adopt 5G=3F Will 5G networks utilize new spectrum bands=3F Who are the key 5G vendors and what are their strategies=3F Will 5G networks rely on a C-RAN architecture=3F What are the prospects of millimeter wave technology for 5G radio access ne= tworking=3F What will be the impact of 5G on the M2M and IoT ecosystem=3F Will drone and satellite based communication platforms play a wider role in= 5G networks=3F Report Information: Release Date: February 2016 Number of Pages: 145 Number of Tables and Figures: 59 Report Overview: While LTE and LTE-Advanced deployments are still underway, mobile operators= and vendors have already embarked on R&D initiatives to develop so-called = =935G=94 technology, with a vision of commercialization by 2020. 5G is esse= ntially a revolutionary paradigm shift in wireless networking to support th= e throughput, latency and scalability requirements of future use cases such= as extreme bandwidth augmented reality applications and connectivity manag= ement for Billions of M2M (Machine to Machine) devices. Although 5G is yet to be standardized, vendors are aggressively investing i= n 5G development efforts with a principal focus on new air interface transm= ission schemes, higher frequency bands and advanced antenna technologies su= ch as Massive MIMO and beamforming. With large scale commercial deployments= expected to begin in 2020, we estimate that 5G networks will generate near= ly $250 Billion in annual service revenue by 2025. The =935G Wireless Ecosystem: 2016 =96 2030 =96 Technologies, Applications,= Verticals, Strategies & Forecasts=94 report presents an in-depth assessmen= t of the emerging 5G ecosystem including key market drivers, challenges, en= abling technologies, use cases, vertical market applications, spectrum asse= ssment, mobile operator deployment commitments, case studies, standardizati= on, research initiatives and vendor strategies. The report also presents fo= recasts for 5G investments and operator services. The report comes with an associated Excel datasheet suite covering quantita= tive data from all numeric forecasts presented in the report =20 Key Findings: =20 The report has the following key findings: Although 5G is yet to be standardized, vendors are aggressively investing i= n 5G development efforts with a principal focus on new air interface transm= ission schemes, higher frequency bands and advanced antenna technologies su= ch as Massive MIMO and beamforming. Driven by regional, national government, mobile operator and vendor initiat= ives, we expect that over $6 Billion will be spent on 5G R&D and trial inve= stments between 2015 and 2020. With large scale commercial deployments expected to begin in 2020, we estim= ate that 5G networks will generate nearly $250 Billion in annual service re= venue by 2025. 5G networks are expected to utilize a variety of spectrum bands for diverse= applications, ranging from established sub-6 GHz cellular bands to millime= ter wave frequencies. Topics Covered: =20 The report covers the following topics: 5G requirements, use cases and vertical market applications 5G market drivers and barriers Air interface and antenna technologies: new waveforms, millimeter wave radi= o access, MIMO, phased array antennas and beamforming=20 Spectrum technologies: cognitive radio, spectrum sensing, aggregation and L= SA (Licensed Shared Access) D2D (Device to Device) communications and self-backhauling networks Complimentary technologies for 5G: NFV (Network Functions Virtualization), = SDN (Software Defined Networking), HetNets (Heterogeneous Networks), C-RAN = (Centralized RAN), Cloud RAN, MEC (Mobile Edge Computing), drones and satel= lites Mobile operator commitments, case studies and 5G spectrum assessment 5G Standardization and research initiatives Competitive assessment of vendor strategies R&D, commercial infrastructure and operator service forecasts till 2030 Forecast Segmentation: Market forecasts are provided for each of the following submarkets and thei= r subcategories: 5G R&D Investments New Waveforms & Millimeter Wave Radio Access MIMO, Beamforming & Antenna Technologies Interference & Spectrum Management C-RAN, Virtualization & Other Technologies 5G Commercial Infrastructure Investments Distributed Macrocell Base Stations Small Cells RRHs (Remote Radio Heads) C-RAN BBUs (Baseband Units) Mobile Core Fronthaul & Backhaul Networking 5G Operator Services Subscriptions Service Revenue Regional Segmentation Asia Pacific Eastern Europe Latin & Central America Middle East & Africa North America Western Europe Report Pricing: Single User License: USD 2,500 Company Wide License: USD 3,500 Ordering Process: Please contact Andy Silva on andy.silva@snscommunication.com Provide the following information: 1. Report Title - 2. Report License - (Single User/Company Wide) 3. Name - 4. Email - 5. Job Title - 6. Company - 7. Invoice Address - Please contact me if you have any questions, or wish to purchase a copy. Ta= ble of contents and List of figures mentioned below for your better inside. I look forward to hearing from you. Kind Regards Andy Silva Marketing Executive Signals and Systems Telecom =20 =20 ___________________________________________________________________________= __________________________________________________________________________ =20 Table of Content =20 1.1 Executive Summary 1.2 Topics Covered 1.3 Forecast Segmentation 1.4 Key Questions Answered 1.5 Key Findings 1.6 Methodology 1.7 Target Audience 1.8 Companies & Organizations Mentioned =20 Chapter 2: The Evolving 5G Ecosystem 2.1 What is 5G=3F 2.2 5G Requirements 2.2.1 Data Volume 2.2.2 Throughput 2.2.3 Response Time & Latency 2.2.4 Device Density 2.2.5 Availability & Coverage 2.2.6 Battery Life 2.2.7 Energy Saving & Cost Reduction 2.3 5G Market Drivers 2.3.1 Why the Need for a 5G Standard=3F 2.3.2 Improving Spectrum Utilization 2.3.3 Advances in Air Interface Transmission Schemes 2.3.4 Gigabit Wireless Connectivity: Supporting Future Services 2.3.5 Moving Towards the IoT (Internet of Things): Increasing Device Dens= ity 2.3.6 Towards a Flatter Network Architecture 2.4 Challenges & Inhibitors to 5G 2.4.1 Skepticism 2.4.2 Standardization Challenges: Too Many Stakeholders 2.4.3 Spectrum Regulation & Complexities 2.4.4 Massive MIMO, Beamforming & Antenna Technology Issues 2.4.5 Higher Frequencies Mean New Infrastructure 2.4.6 Complex Performance Requirements 2.4.7 Energy Efficiency & Technology Scaling 2.5 5G Applications & Use Cases 2.5.1 Extreme Bandwidth Applications: Video, Internet Gaming & Augmented = Reality 2.5.2 MTC/M2M, IoT & Ubiquitous Communications 2.5.2.1 Short-burst Traffic 2.5.3 Vertical Industries & Safety Critical Domains 2.5.3.1 Automotive 2.5.3.2 Energy & Smart Grids 2.5.3.3 Transport & Logistics 2.5.3.4 Healthcare 2.5.3.5 Smart Cities 2.5.3.6 Public Safety 2.5.3.7 Fitness & Sports =20 Chapter 3: Enabling Technologies for 5G 3.1 Key Technologies & Concepts 3.1.1 Air Interface: Waveform Options 3.1.2 Millimeter Wave Radio Access 3.1.3 Massive MIMO 3.1.4 Phased Array Antennas 3.1.5 Beamforming 3.1.6 D2D (Device to Device) Communications 3.1.7 Self-Backhauling & Mesh Networking 3.1.8 Cognitive Radio & Spectrum Sensing 3.1.9 Unlicensed Spectrum Usage 3.1.10 LSA (Licensed Shared Access) 3.1.11 Spectrum Aggregation 3.1.12 Integration of VLC (Visible Light Communication) 3.2 Complimentary Technologies 3.2.1 NFV & SDN 3.2.2 HetNet & C-RAN Architecture 3.2.3 Cloud RAN 3.2.4 MEC (Mobile Edge Computing) 3.2.5 Drones & Satellites 3.2.5.1 Satellite Integration in 5G Networks 3.2.5.2 Google and Facebook=92s Drone Ambitions 3.2.5.3 Interest from Mobile Operators =20 Chapter 4: 5G Investments & Future Forecast 4.1 How Much is Being Invested in 5G R&D=3F 4.2 R&D Investments by Technology 4.2.1 New Waveforms & Millimeter Wave Radio Access 4.2.2 MIMO, Beamforming & Antenna Technologies 4.2.3 Interference & Spectrum Management 4.2.4 C-RAN, Virtualization & Other Technologies 4.3 Global Outlook for 5G Infrastructure 4.3.1 Segmentation by Submarket 4.3.2 Distributed Macrocell Base Stations 4.3.3 Small Cells 4.3.4 RRHs (Remote Radio Heads) 4.3.5 C-RAN BBUs (Baseband Units) 4.3.6 Mobile Core 4.3.7 Fronthaul & Backhaul Networking 4.3.8 Segmentation by Region 4.4 Global Outlook for 5G Operator Services 4.4.1 Subscriptions 4.4.2 Service Revenue 4.4.3 Regional Segmentation 4.5 Asia Pacific 4.5.1 Infrastructure 4.5.2 Subscriptions 4.5.3 Service Revenue 4.6 Eastern Europe 4.6.1 Infrastructure 4.6.2 Subscriptions 4.6.3 Service Revenue 4.7 Latin & Central America 4.7.1 Infrastructure 4.7.2 Subscriptions 4.7.3 Service Revenue 4.8 Middle East & Africa 4.8.1 Infrastructure 4.8.2 Subscriptions 4.8.3 Service Revenue 4.9 North America 4.9.1 Infrastructure 4.9.2 Subscriptions 4.9.3 Service Revenue 4.10 Western Europe 4.10.1 Infrastructure 4.10.2 Subscriptions 4.10.3 Service Revenue =20 Chapter 5: Mobile Operator Commitments & 5G Spectrum Assessment 5.1 Mobile Operator Commitments 5.1.1 Japan, South Korea & Asia 5.1.2 Europe 5.1.3 North America 5.1.4 Rest of the World 5.1.5 Operator Case Studies 5.1.5.1 NTT DoCoMo 5.1.5.2 SK Telecom 5.2 Spectrum Options for 5G 5.2.1 Sub-1 GHz 5.2.2 1-6 GHz 5.2.2.1 3-4 GHz 5.2.2.2 5 GHz 5.2.3 Above 6 GHz 5.2.3.1 15 GHz 5.2.3.2 24-30 GHz 5.2.3.3 30-60 GHz 5.2.3.4 60, 70 & 80 GHz 5.2.4 Higher Bands =20 Chapter 6: 5G Standardization & Research Initiatives 6.1 ITU (International Telecommunication Union) 6.1.1 IMT-2020 6.1.2 Spectrum Allocation 6.2 3GPP (Third Generation Partnership Project) 6.2.1 Phased Standardization Approach 6.2.2 R&D Efforts 6.3 ETSI (European Telecommunications Standards Institute) 6.3.1 ISGs (Industry Specification Groups) for Enabling Technologies 6.4 GSMA 6.4.1 Defining 5G 6.4.2 Spectrum Policy Position 6.5 NGMN (Next Generation Mobile Networks) Alliance 6.5.1 5G Work Program 6.6 5G Americas 6.6.1 5G Advocacy Efforts 6.7 WWRF (World Wireless Research Forum) 6.7.1 New Working Groups for 5G 6.8 IEEE (Institute of Electrical and Electronics Engineers) 6.8.1 5G Advocacy Efforts 6.9 Small Cell Forum 6.9.1 Mapping 5G Requirements for Small Cells 6.10 CableLabs 6.10.1 Research on High Capacity Millimeter Wave Small Cells 6.11 European Commission Initiatives 6.11.1 5G PPP (5G Infrastructure Public Private Partnership) 6.11.1.1 5G NORMA 6.11.1.2 METIS-II 6.11.1.3 mmMAGIC 6.11.1.4 FANTASTIC-5G 6.11.1.5 Flex5Gware 6.11.1.6 5G-XHaul 6.11.1.7 5G-Crosshaul 6.11.1.8 Other Projects 6.11.2 FP7 Projects 6.11.2.1 METIS 6.11.2.2 5GNOW 6.11.2.3 MiWEBA 6.11.2.4 MiWaveS 6.11.2.5 Other Projects 6.12 National Initiatives 6.12.1 South Korea 6.12.1.1 5G Forum 6.12.1.2 ETRI (Electronics and Telecommunications Research) 6.12.2 Japan 6.12.2.1 ARIB 20B AH (2020 and Beyond AdHoc) 6.12.2.2 5GMF (Fifth Generation Mobile Communications Promotion Forum) 6.12.3 China 6.12.3.1 IMT-2020 (5G) Promotion Group 6.12.3.2 863 Research Program 6.12.3.3 Future Forum 6.12.4 Taiwan 6.12.4.1 TAICS (Taiwan Association of Information and Communication Sta= ndards) 6.12.5 USA 6.12.5.1 NSF (National Science Foundation) 6.12.5.2 NIST (National Institute of Standards and Technology) 6.12.5.3 FCC (Federal Communications Commission) 6.12.5.4 ATIS (Alliance for Telecommunications Industry Solutions) 6.12.5.5 TIA (Telecommunications Industry Association) 6.12.6 UK 6.12.6.1 Ofcom 6.12.7 Russia 6.12.7.1 5GRUS 6.12.8 Germany 6.12.8.1 5G:Haus 6.12.9 Spain 6.12.9.1 5TONIC 6.12.10 Finland 6.12.10.1 5GTNF (5G Test Network Finland) 6.13 Academic Initiatives 6.13.1 5GIC (5G Innovation Center, University of Surrey) 6.13.2 NYU WIRELESS (New York University) 6.13.3 5G Lab (TU Dresden) 6.13.4 Viterbi School of Engineering (University of Southern California) 6.13.5 Hiroshima University 6.13.6 Tokyo Institute of Technology =20 Chapter 7: Vendor Demonstrations, Commitments & Strategies 7.1 Cohere Technologies 7.1.1 5G Strategy 7.1.2 Demonstrations & Trial Commitments 7.2 Cisco Systems 7.2.1 5G Strategy 7.2.2 Demonstrations & Trial Commitments 7.3 Ericsson 7.3.1 5G Strategy 7.3.2 Demonstrations & Trial Commitments 7.4 Fujitsu 7.4.1 5G Strategy 7.4.2 Demonstrations & Trial Commitments 7.5 Google 7.5.1 5G Strategy 7.5.2 Demonstrations & Trial Commitments 7.6 Huawei 7.6.1 5G Strategy 7.6.2 Demonstrations & Trial Commitments 7.7 Intel Corporation 7.7.1 5G Strategy 7.7.2 Demonstrations & Trial Commitments 7.8 InterDigital 7.8.1 5G Strategy 7.8.2 Demonstrations & Trial Commitments 7.9 Keysight Technologies 7.9.1 5G Strategy 7.9.2 Demonstrations & Trial Commitments 7.10 Kumu Networks 7.10.1 5G Strategy 7.10.2 Demonstrations & Trial Commitments 7.11 Mitsubishi Electric 7.11.1 5G Strategy 7.11.2 Demonstrations & Trial Commitments 7.12 NEC Corporation 7.12.1 5G Strategy 7.12.2 Demonstrations & Trial Commitments 7.13 NI (National Instruments) 7.13.1 5G Strategy 7.13.2 Demonstrations & Trial Commitments 7.14 Nokia 7.14.1 5G Strategy 7.14.2 Demonstrations & Trial Commitments 7.15 Panasonic 7.15.1 5G Strategy 7.15.2 Demonstrations & Trial Commitments 7.16 Qualcomm 7.16.1 5G Strategy 7.16.2 Demonstrations & Trial Commitments 7.17 Rohde & Schwarz 7.17.1 5G Strategy 7.17.2 Demonstrations & Trial Commitments 7.18 Samsung 7.18.1 5G Strategy 7.18.2 Demonstrations & Trial Commitments 7.19 SiBEAM 7.19.1 5G Strategy 7.19.2 Demonstrations & Trial Commitments 7.20 ZTE 7.20.1 5G Strategy 7.20.2 Demonstrations & Trial Commitments =20 List of Figures Figure 1: 5G Requirements Figure 2: Potential Waveform Options for 5G Figure 3: D2D Communication Scenarios Figure 4: LSA Concept Figure 5: NFV Concept Figure 6: C-RAN Architecture Figure 7: Cloud RAN Concept Figure 8: Global 5G R&D Investments: 2016 - 2020 ($ Million) Figure 9: Global 5G R&D Investments by Technology: 2016 - 2020 ($ Million) Figure 10: Global 5G R&D Investments on New Waveforms & Millimeter Wave Rad= io Access: 2016 - 2020 ($ Million) Figure 11: Global 5G R&D Investments on MIMO, Beamforming & Antenna Technol= ogies: 2016 - 2020 ($ Million) Figure 12: Global 5G R&D Investments on Interference & Spectrum Management:= 2016 - 2020 ($ Million) Figure 13: Global 5G R&D Investments on C-RAN, Virtualization & Other Techn= ologies: 2016 - 2020 ($ Million) Figure 14: Global 5G Infrastructure Investments: 2020 - 2030 ($ Million) Figure 15: Global 5G Infrastructure Investments by Submarket: 2020 - 2030 (= $ Million) Figure 16: Global 5G Distributed Macrocell Base Station Shipments: 2020 - 2= 030 (Thousands of Units) Figure 17: Global 5G Distributed Macrocell Base Station Shipment Revenue: 2= 020 - 2030 ($ Million) Figure 18: Global 5G Small Cell Shipments: 2020 - 2030 (Thousands of Units) Figure 19: Global 5G Small Cell Shipment Revenue: 2020 - 2030 ($ Million) Figure 20: Global 5G RRH Shipments: 2020 - 2030 (Thousands of Units) Figure 21: Global 5G RRH Shipment Revenue: 2020 - 2030 ($ Million) Figure 22: Global 5G C-RAN BBU Shipments: 2020 - 2030 (Thousands of Units) Figure 23: Global 5G C-RAN BBU Shipment Revenue: 2020 - 2030 ($ Million) Figure 24: Global 5G Mobile Core Investments: 2020 - 2030 ($ Million) Figure 25: Global 5G Fronthaul & Backhaul Investments: 2020 - 2030 ($ Milli= on) Figure 26: 5G Infrastructure Investments by Region: 2020 - 2030 ($ Million) Figure 27: Global 5G Subscriptions: 2020 - 2030 (Millions) Figure 28: Global 5G Service Revenue: 2020 - 2030 ($ Billion) Figure 29: 5G Subscriptions by Region: 2020 - 2030 (Millions) Figure 30: 5G Service Revenue by Region: 2020 - 2030 ($ Billion) Figure 31: Asia Pacific 5G Infrastructure Investments: 2020 - 2030 ($ Milli= on) Figure 32: Asia Pacific 5G Subscriptions: 2020 - 2030 (Millions) Figure 33: Asia Pacific 5G Service Revenue: 2020 - 2030 ($ Billion) Figure 34: Eastern Europe 5G Infrastructure Investments: 2020 - 2030 ($ Mil= lion) Figure 35: Eastern Europe 5G Subscriptions: 2020 - 2030 (Millions) Figure 36: Eastern Europe 5G Service Revenue: 2020 - 2030 ($ Billion) Figure 37: Latin & Central America 5G Infrastructure Investments: 2020 - 20= 30 ($ Million) Figure 38: Latin & Central America 5G Subscriptions: 2020 - 2030 (Millions) Figure 39: Latin & Central America 5G Service Revenue: 2020 - 2030 ($ Billi= on) Figure 40: Middle East & Africa 5G Infrastructure Investments: 2020 - 2030 = ($ Million) Figure 41: Middle East & Africa 5G Subscriptions: 2020 - 2030 (Millions) Figure 42: Middle East & Africa 5G Service Revenue: 2020 - 2030 ($ Billion) Figure 43: North America 5G Infrastructure Investments: 2020 - 2030 ($ Mill= ion) Figure 44: North America 5G Subscriptions: 2020 - 2030 (Millions) Figure 45: North America 5G Service Revenue: 2020 - 2030 ($ Billion) Figure 46: Western Europe 5G Infrastructure Investments: 2020 - 2030 ($ Mil= lion) Figure 47: Western Europe 5G Subscriptions: 2020 - 2030 (Millions) Figure 48: Western Europe 5G Service Revenue: 2020 - 2030 ($ Billion) Figure 49: NTT DoCoMo=92s 5G Roadmap Figure 50: SK Telecom=92s Phased 5G Approach Figure 51: BBU-RRH Functional Split Options for 5G C-RAN Figure 52: Spectrum Bands for 5G Figure 53: IMT-2020 Development Roadmap Figure 54: 3GPP 5G Standardization Roadmap Figure 55: NGMN 5G Work Program Figure 56: 5G Networks & Service Vision Figure 57: 5G PPP=92s Development Roadmap Figure 58: ARIB=92s Vision of Radio Access Technologies for 5G Figure 59: Japan 5G Implementation Roadmap =20 Thank you once again and looking forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snscommunication.com Reef Tower Jumeirah Lake Towers Sheikh Zayed Road Dubai, UAE =20 =20 To unsubscribe send an email with unsubscribe in the subject line to: remov= e@snsreports.com From owner-freebsd-ppc@freebsd.org Wed Mar 2 18:47:06 2016 Return-Path: Delivered-To: freebsd-ppc@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 BFBE9AC2EA4 for ; Wed, 2 Mar 2016 18:47:06 +0000 (UTC) (envelope-from miltoncsl@yahoo.com) Received: from nm6.bullet.mail.bf1.yahoo.com (nm6.bullet.mail.bf1.yahoo.com [98.139.212.165]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 882C61089 for ; Wed, 2 Mar 2016 18:47:06 +0000 (UTC) (envelope-from miltoncsl@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456944419; bh=Co35fpWiq5FJU8SITNqgUc8H7UgZmuSPlYkAcLDNUe8=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=EDrRpy7FuK86zUCAB9euku82MZnpG0ioxGYu78FeKu6EiTpfiZBxeRCH/xSxsNtFOScu8C55tgZaZ1UfRDwthSD5I8WSDXAbXEBCQZz6480ZDl9pArzQtNmyN3m2X4ScqiH51TcKuq3QvXxWZsuOqaRsKbGI7o6rzWuUIbSByc397KTwg3mLn5q1kZ0NtLkbpI5LDbezNquz2ItcjVFHorAW9zAGqVUw/5mbSHkkZKJBHzqE0XuPRAjs/FCMt/tGYul7gO05JYyhmM7ge01cdiB4cv5t9ZD1g/rh96J+DmMZpcXUbRZ8Dc4O3ulDN2XnSxLN6EFJYZwaOfaQWSonmg== Received: from [98.139.170.182] by nm6.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2016 18:46:59 -0000 Received: from [98.139.212.222] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2016 18:46:59 -0000 Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 02 Mar 2016 18:46:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 135974.48845.bm@omp1031.mail.bf1.yahoo.com X-YMail-OSG: RcG.0hgVM1n_O_4h2EJV4PIb0v2TB.ut1Sn8GynMMn0n8k6OiPNSc0k21jPPMR_ Flf3T3CB4K3hqefTWN4loxBj6wdOwsgjW1ypOskid8pqfw81UFPG9bgrOjVvGD8ODeZxEZik6O6T UlLIOE3UGDf70Gbmna5UKcewmhcwrMXe5QCDwjGqVwTMDuI7pqljuWd8o80EYE.kAiztTHNm2kaq AdbnQVfXt.wVtUkXfYqDVlkf49oOfpReaxBjIzODZcgEXS7XOKkAuKHcoB5UZlxb.JPMLJ2J8d8H chki3jtU_YWrMWTpwSuXu71UQxpNxjHk4DjZ1k4VnBZizP9s60WtbWtXSOaS6UJx2Emdm.Dc1g8Q bAQfPBj1P0hexTonIOBvOMiXgyXeR7MeDZrjU3fmVYfvXeXl1zONlNHZKRcxuVC.qDsM1lcb.7fZ zroOGQ9jj9lKXW2_BX8dJhJSNP3BVi1cWyRX1I14v84mabb.Hv.IavOPSJiNmKzCh1kKQ2nTGhN4 T7V9ETmxX Received: by 76.13.26.142; Wed, 02 Mar 2016 18:46:58 +0000 Date: Wed, 2 Mar 2016 18:46:35 +0000 (UTC) From: =?UTF-8?Q?Milton_C=C3=A9sar_Disegna_de_Souza_Leite?= Reply-To: =?UTF-8?Q?Milton_C=C3=A9sar_Disegna_de_Souza_Leite?= To: "freebsd-ppc@freebsd.org" Message-ID: <1334703397.2531865.1456944395825.JavaMail.yahoo@mail.yahoo.com> Subject: Radeon Video Card Support. MIME-Version: 1.0 References: <1334703397.2531865.1456944395825.JavaMail.yahoo.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 18:47:06 -0000 Hi, There are any news about support =C2=A0for Radeon video card in Powermacs G= 5 late 2005? More especifically about video cards Radeon X1900 Mac Edition.= I have one PowerMac G5 2.0GHz dual core with Radeon X1900. This card work w= ith Mac OS X Leopard 10.5.8 without problems but not in FreeBSD 10.x. It do= es not work also in Debian, Gentoo and Ubuntu Mate (distros that I have tes= ted in my ppc).I searched by others card that can function in Powermac and = I discovered that Radeon HD series can work in Linux (4650 and 6570 are exa= mples that I have found) like a second video card until with 3D (Thank for = Luigi Burdo).There are any similar attempts for FreeBSD for Radeon HD serie= s? =C2=A0Milton C=C3=A9sar Disegna de Souza Leite "Preocupe-se mais com sua consci=C3=AAncia do que com sua reputa=C3=A7=C3= =A3o. Porque sua consci=C3=AAncia =C3=A9 o que voc=C3=AA =C3=A9, e sua repu= ta=C3=A7=C3=A3o =C3=A9 o que os outros pensam de voc=C3=AA. E o que os outr= os pensam, =C3=A9 problema deles." From owner-freebsd-ppc@freebsd.org Wed Mar 2 20:14:52 2016 Return-Path: Delivered-To: freebsd-ppc@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 4DCA8AC296D for ; Wed, 2 Mar 2016 20:14:52 +0000 (UTC) (envelope-from miltoncsl@yahoo.com) Received: from nm2-vm1.bullet.mail.bf1.yahoo.com (nm2-vm1.bullet.mail.bf1.yahoo.com [98.139.213.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 16C471507 for ; Wed, 2 Mar 2016 20:14:51 +0000 (UTC) (envelope-from miltoncsl@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456949685; bh=GT98x81uYY3Ao5guMXuvgRjYtijyx9siw6p11A1Ft4I=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=RKjpBSd13WTs87kbDM83abm8COf2Aznb4B2lkaXVxkhbSAW8HufPLv4OKs2OC5VtbcZH01bC8ecyTL80h7ruXsnxxZDSYAv2jFNr8hA0EfXVtfwwDn3FapmDzy6IXWfuma4vy0lZ6VOZFy83DbtmVoJCMlBzzLORTB/QXDz9LL1hgN4rI6/DbvKn+svu4oTurNUrJIS1/MWTrWIUNL8xzZxiWMHpzv+qWSgK/67jVxBYP3RuEkDZNiAW77t26rUr2CuzOELUdvmg3wsrFqAmVVTS6v/PUedT/XYS/iFKgrmN9a2L3Yi1ib+HMIBkri8XHjvXGj4dfIN+5sU3mFUcAQ== Received: from [98.139.215.141] by nm2.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2016 20:14:45 -0000 Received: from [98.139.212.221] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 02 Mar 2016 20:14:45 -0000 Received: from [127.0.0.1] by omp1030.mail.bf1.yahoo.com with NNFMP; 02 Mar 2016 20:14:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 365605.93359.bm@omp1030.mail.bf1.yahoo.com X-YMail-OSG: fIRVw6EVM1lrSQZEZEyYYzza_HIqns7J2FhzJuJ2paOlGq89CFfzrJN.KYwiCIt QJ1o3_xQpvses1n3Vrn_CZS_tjLe6TegIBC7Jh7eGP1itVzP4AipRD8MDSo6PJHQIUeOlE.Q5aE. sPxxZXJepT9fbdQEkkXag1XYF0T4_C.RE0LePDr1uH4jMycyPYRxLNM9m5LqMkd6fmRd7fBYpKS9 Xp6OuliDqU5HVJT2g669x3l_ybBGkNPb6Gaw2.epYebJizv9eC41fq0L.o.83rwhH_WA7Yw2PvLE 9.JTX__aXodvjx1O._X6A1QZZj7MAn9AMDLbO46UpKGmKp4wRa.8tVbT3jr2x7dRg7ml76RzJexL CNL9o5N1yUqNr52of_dPVOXnFXrTT6Asf6u7vou1Pf_vvRd5kgg7jhJqVpfaNRH8TR1.Cg.M8VRh 2gI0MkDhzTp_WHLy6KjG0B2SpV5gn8dVZXWl6xavW4saoPPemTdNyNmekeBHWk13.V1pQAG1kB9W 8ps9FAKQ6QA-- Received: by 66.196.81.105; Wed, 02 Mar 2016 20:14:44 +0000 Date: Wed, 2 Mar 2016 20:14:44 +0000 (UTC) From: =?UTF-8?Q?Milton_C=C3=A9sar_Disegna_de_Souza_Leite?= Reply-To: =?UTF-8?Q?Milton_C=C3=A9sar_Disegna_de_Souza_Leite?= To: "freebsd-ppc@freebsd.org" Message-ID: <66456897.2636817.1456949684196.JavaMail.yahoo@mail.yahoo.com> Subject: Radeon Video Card Support. MIME-Version: 1.0 References: <66456897.2636817.1456949684196.JavaMail.yahoo.ref@mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 20:14:52 -0000 Hi, There are any news about support =C2=A0for Radeon video card in Powermacs G= 5 late 2005? More especifically about video cards Radeon X1900 Mac Edition.= I have one PowerMac G5 2.0GHz dual core with Radeon X1900. This card work w= ith Mac OS X Leopard 10.5.8 without problems but not in FreeBSD 10.x. It do= es not work also in Debian, Gentoo and Ubuntu Mate (distros that I have tes= ted in my ppc).I searched by others card that can function in Powermac and = I discovered that Radeon HD series can work in Linux (4650 and 6570 are exa= mples that I have found) like a second video card until with 3D (Thank for = Luigi Burdo).There are any similar attempts for FreeBSD for Radeon HD serie= s? Milton C=C3=A9sar Disegna de Souza Leite "Preocupe-se mais com sua consci=C3=AAncia do que com sua reputa=C3=A7=C3= =A3o. Porque sua consci=C3=AAncia =C3=A9 o que voc=C3=AA =C3=A9, e sua repu= ta=C3=A7=C3=A3o =C3=A9 o que os outros pensam de voc=C3=AA. E o que os outr= os pensam, =C3=A9 problema deles." From owner-freebsd-ppc@freebsd.org Thu Mar 3 01:47:27 2016 Return-Path: Delivered-To: freebsd-ppc@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 E311CAC21F2 for ; Thu, 3 Mar 2016 01:47:27 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CCD318F0 for ; Thu, 3 Mar 2016 01:47:27 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id c3so7308411vkb.3 for ; Wed, 02 Mar 2016 17:47:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=p8ks/exLbmoW09zk3tZ5LH86JWcxq+qopdEZEIgnWPA=; b=vP9+UqyUb0po0FKeirzahyJkv1pxq3LIXcX8QHuNE/cTY+mV0n+eTEdutaf0dlEX6E 2r/gkhxbpjpGJn7wOBedokl8NOhuOvVzwgwj0GPct4o7RlTs/IMHhk3tRof0BjXcMm56 ykRIqZmOINovES84bgkuwHr7ECrIX/m8sqP+OB3gvaX5Be2H82PkcCLX8h/41X1uGVSs JcA55BnePe6F1CTTa3pguB8ebDSLE23sVSnJN4Zwtb7COr7w2yh1ydebjua4W9z959V6 k/FgkSVM05oxddIfvkNn/jGzqksLT0gPz8Mfm+17lcZDcSL5xUSDcUpnT80J9y3bph9x ztUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=p8ks/exLbmoW09zk3tZ5LH86JWcxq+qopdEZEIgnWPA=; b=LYxo6T5QSxDSq/Q7W1UPGaASxmb6tUO38DRB3YP6/B/O45M48DFGGiI9RvTq3DZZZ5 1P1mc6Egh3Q/pMXXQN824buaHSqQVowpE6UD1+aNAlsYa188shW4/Lrh4CCdCJ7lXEzL G4QXlha9qNWxyHkHit0UthMILHDQcFZYdeqo28M07prs8vdjIRCJw4N6EqhZdyqSyTy2 ENbLeqnw4wtvFS/H7Sis0w9s54Qid2AH9tOK01JBziTXdBQTSNk2uvTyhncMLSYQ2WtT 34Vdj8QUAbqjFA7b7NC2Lt80Rnumu/tdhsDSD2VYABxaB8trcP5X7Iq3TMJh1nSLFAfq ADXw== X-Gm-Message-State: AD7BkJLEkNVAdUlc+xMfu5PiaZKrTEGeJcjL+WjVGedqNLjJ8h0K0OGZlYgNst7gwYcKr8TA5gA8x5wqF558+g== MIME-Version: 1.0 X-Received: by 10.31.128.82 with SMTP id b79mr23101497vkd.47.1456969646708; Wed, 02 Mar 2016 17:47:26 -0800 (PST) Received: by 10.103.37.196 with HTTP; Wed, 2 Mar 2016 17:47:26 -0800 (PST) In-Reply-To: <66456897.2636817.1456949684196.JavaMail.yahoo@mail.yahoo.com> References: <66456897.2636817.1456949684196.JavaMail.yahoo.ref@mail.yahoo.com> <66456897.2636817.1456949684196.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 2 Mar 2016 20:47:26 -0500 Message-ID: Subject: Re: Radeon Video Card Support. From: Joe Nosay To: =?UTF-8?Q?Milton_C=C3=A9sar_Disegna_de_Souza_Leite?= Cc: "freebsd-ppc@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 01:47:28 -0000 Oi, Qual e' and all that. This is somewhat of a X11 problem and not just PPC. On Wed, Mar 2, 2016 at 3:14 PM, Milton C=C3=A9sar Disegna de Souza Leite < freebsd-ppc@freebsd.org> wrote: > Hi, > There are any news about support for Radeon video card in Powermacs G5 > late 2005? More especifically about video cards Radeon X1900 Mac Edition.= I > have one PowerMac G5 2.0GHz dual core with Radeon X1900. This card work > with Mac OS X Leopard 10.5.8 without problems but not in FreeBSD 10.x. It > does not work also in Debian, Gentoo and Ubuntu Mate (distros that I have > tested in my ppc).I searched by others card that can function in Powermac > and I discovered that Radeon HD series can work in Linux (4650 and 6570 a= re > examples that I have found) like a second video card until with 3D (Thank > for Luigi Burdo).There are any similar attempts for FreeBSD for Radeon HD > series? > > Milton C=C3=A9sar Disegna de Souza Leite > > "Preocupe-se mais com sua consci=C3=AAncia do que com sua reputa=C3=A7=C3= =A3o. Porque sua > consci=C3=AAncia =C3=A9 o que voc=C3=AA =C3=A9, e sua reputa=C3=A7=C3=A3o= =C3=A9 o que os outros pensam de > voc=C3=AA. E o que os outros pensam, =C3=A9 problema deles." > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@freebsd.org Thu Mar 3 02:22:26 2016 Return-Path: Delivered-To: freebsd-ppc@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 40DEFAC1027 for ; Thu, 3 Mar 2016 02:22:26 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 08DC11AD4 for ; Thu, 3 Mar 2016 02:22:26 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-ig0-x236.google.com with SMTP id z8so8214448ige.0 for ; Wed, 02 Mar 2016 18:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0/CoZFMPhQxKY9ZHOv3xedHSyqrk2IN2ZEWdBIY0GQc=; b=WBrgFjezCEtaALx1bJmq/Mnmk0yFmxP+3r1yLti6C2tpa9SDSFcSs68uFadHKRJq7K 74/13Dbbntw9hMxksF9X6Udt1FgBwXiJwzOeK4Iz1wOJB/k3M8hIcsNeNHdF+phNpT3g wurXdKDNVmGwag8PyKCCpQydvtRzFtyjoGYD2sSBNfaXFeKfxIZwMLM+MWVNGHVtu5N4 14osyf0j5ZFIMHTKm8DUEDsOYI9tn7JIl6zPXO6xuSRbEhMoG0MTBVtBoPtjX1CK7RTS yNOriwDzgjGZFB3uu8g/CXNnLGFl0CUpNXrL0+zNauHHvpZ70AVQMa6zDv/kcMQNii4p /zbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0/CoZFMPhQxKY9ZHOv3xedHSyqrk2IN2ZEWdBIY0GQc=; b=G1lyRShXQ8Gs/zUWdVjf/QDb5li3BiXxtdOe0D8qY7xmJ3LhtEiPlgqLEw6jGRk920 YddvAdhPhxPUcJbcPKo7FhvFKaTBDCXgPOTbcTFhyB2tG1c3Agw6+Dy7IxiaVPYycs4q Hpq9F4lbtSbWdfCZVtwjaIZfHFjfNEdGZ2FflQ9fXrdvCVeyYbzyeU7jBqLumLHvsh0t vh3qbnnRyqgaqdOKYOfJYKoULgU4BxIsPoeeL+Z8HLLMAqhle0jfl64DISNSGEH5otKn hluCxd2IwF/nTMGPlEEGFyJ+Hdzx4lf/pRZTPCaA6EVo9jG0mcNqVGA2rrv9F2c3OaI0 vuUw== X-Gm-Message-State: AD7BkJIJWscBU0yUlXflMrCwWXMBbJe0YhPaRdEVwg2d96mDkfRw5Mv+ttNb72EK+erS0g== X-Received: by 10.50.3.70 with SMTP id a6mr3098174iga.40.1456971745430; Wed, 02 Mar 2016 18:22:25 -0800 (PST) Received: from manatee.acadix.biz (h184-61-62-248.nwblwi.dsl.dynamic.tds.net. [184.61.62.248]) by smtp.gmail.com with ESMTPSA id f129sm3995044ioe.36.2016.03.02.18.22.24 for (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 Mar 2016 18:22:24 -0800 (PST) Subject: Re: Radeon Video Card Support. To: freebsd-ppc@freebsd.org References: <66456897.2636817.1456949684196.JavaMail.yahoo.ref@mail.yahoo.com> <66456897.2636817.1456949684196.JavaMail.yahoo@mail.yahoo.com> From: Jason Bacon Message-ID: <56D79FDF.6040201@gmail.com> Date: Wed, 2 Mar 2016 20:22:23 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 02:22:26 -0000 If you can find out what it's most similar to that *is* supported by Xorg, there's a chance it will prove very easy to add support for it. There is support for the X1900 series: http://www.x.org/archive/X11R7.6/doc/man/man4/radeon.4.xhtml It *could* prove to be as easy as tweaking the radeon driver to recognize the chipset as one if its supported models. Or, it could mean studying the spec sheet and writing hundreds of lines of new code. :-/ Only one way to find out... On 03/02/2016 19:47, Joe Nosay wrote: > Oi, > Qual e' and all that. > This is somewhat of a X11 problem and not just PPC. > > On Wed, Mar 2, 2016 at 3:14 PM, Milton César Disegna de Souza Leite < > freebsd-ppc@freebsd.org> wrote: > >> Hi, >> There are any news about support for Radeon video card in Powermacs G5 >> late 2005? More especifically about video cards Radeon X1900 Mac Edition.I >> have one PowerMac G5 2.0GHz dual core with Radeon X1900. This card work >> with Mac OS X Leopard 10.5.8 without problems but not in FreeBSD 10.x. It >> does not work also in Debian, Gentoo and Ubuntu Mate (distros that I have >> tested in my ppc).I searched by others card that can function in Powermac >> and I discovered that Radeon HD series can work in Linux (4650 and 6570 are >> examples that I have found) like a second video card until with 3D (Thank >> for Luigi Burdo).There are any similar attempts for FreeBSD for Radeon HD >> series? >> >> Milton César Disegna de Souza Leite >> >> "Preocupe-se mais com sua consciência do que com sua reputação. Porque sua >> consciência é o que você é, e sua reputação é o que os outros pensam de >> você. E o que os outros pensam, é problema deles." >> >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >> > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" From owner-freebsd-ppc@freebsd.org Thu Mar 3 03:04:51 2016 Return-Path: Delivered-To: freebsd-ppc@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 A5C1BAC2292 for ; Thu, 3 Mar 2016 03:04:51 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8777A194A for ; Thu, 3 Mar 2016 03:04:51 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from aurora.physics.berkeley.edu (aurora.physics.berkeley.edu [128.32.117.67]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u232qrnG020677 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 2 Mar 2016 18:52:54 -0800 Subject: Re: Radeon Video Card Support. To: freebsd-ppc@freebsd.org References: <66456897.2636817.1456949684196.JavaMail.yahoo.ref@mail.yahoo.com> <66456897.2636817.1456949684196.JavaMail.yahoo@mail.yahoo.com> <56D79FDF.6040201@gmail.com> From: Nathan Whitehorn Message-ID: <56D7A705.9050007@freebsd.org> Date: Wed, 2 Mar 2016 18:52:53 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56D79FDF.6040201@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Sonic-CAuth: UmFuZG9tSVa/7XKGtr1TievBDXMdsKYIXuMRyyzwY/JSejHxsdkSKbP2Y0fYGjK5wtzW8U8Y0V/LlT1FXuISei1fkKDXKBsyWVrFpvnIqU8= X-Sonic-ID: C;Gq6bBuvg5RGoggURnien6Q== M;Ih/IBuvg5RGoggURnien6Q== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 03:04:51 -0000 I believe the X radeon driver relies on parsing some information out of the BIOS. Since the Mac version doesn't have a BIOS in the format the driver expects, it does not work. There was only the one model of card and so no one was ever interested in fixing it. You can get X with the xf86-video-scfb driver, but it will be unaccelerated. -Nathan On 03/02/16 18:22, Jason Bacon wrote: > > If you can find out what it's most similar to that *is* supported by > Xorg, there's a chance it will prove very easy to add support for it. > > There is support for the X1900 series: > http://www.x.org/archive/X11R7.6/doc/man/man4/radeon.4.xhtml > > It *could* prove to be as easy as tweaking the radeon driver to > recognize the chipset as one if its supported models. Or, it could > mean studying the spec sheet and writing hundreds of lines of new > code. :-/ Only one way to find out... > > On 03/02/2016 19:47, Joe Nosay wrote: >> Oi, >> Qual e' and all that. >> This is somewhat of a X11 problem and not just PPC. >> >> On Wed, Mar 2, 2016 at 3:14 PM, Milton César Disegna de Souza Leite < >> freebsd-ppc@freebsd.org> wrote: >> >>> Hi, >>> There are any news about support for Radeon video card in Powermacs G5 >>> late 2005? More especifically about video cards Radeon X1900 Mac >>> Edition.I >>> have one PowerMac G5 2.0GHz dual core with Radeon X1900. This card work >>> with Mac OS X Leopard 10.5.8 without problems but not in FreeBSD >>> 10.x. It >>> does not work also in Debian, Gentoo and Ubuntu Mate (distros that I >>> have >>> tested in my ppc).I searched by others card that can function in >>> Powermac >>> and I discovered that Radeon HD series can work in Linux (4650 and >>> 6570 are >>> examples that I have found) like a second video card until with 3D >>> (Thank >>> for Luigi Burdo).There are any similar attempts for FreeBSD for >>> Radeon HD >>> series? >>> >>> Milton César Disegna de Souza Leite >>> >>> "Preocupe-se mais com sua consciência do que com sua reputação. >>> Porque sua >>> consciência é o que você é, e sua reputação é o que os outros pensam de >>> você. E o que os outros pensam, é problema deles." >>> >>> _______________________________________________ >>> freebsd-ppc@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >>> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" >>> >> _______________________________________________ >> freebsd-ppc@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc >> To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org" > From owner-freebsd-ppc@freebsd.org Thu Mar 3 05:17:29 2016 Return-Path: Delivered-To: freebsd-ppc@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 D4EE1AC02DD for ; Thu, 3 Mar 2016 05:17:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-160.reflexion.net [208.70.211.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8770B1389 for ; Thu, 3 Mar 2016 05:17:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31907 invoked from network); 3 Mar 2016 04:51:05 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 3 Mar 2016 04:51:05 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Wed, 02 Mar 2016 23:50:51 -0500 (EST) Received: (qmail 18126 invoked from network); 3 Mar 2016 04:50:51 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 3 Mar 2016 04:50:51 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 7B29B1C43C6; Wed, 2 Mar 2016 20:50:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: Date: Wed, 2 Mar 2016 20:50:46 -0800 Cc: FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <27FEB264-0A3E-42DF-A549-1E54ED489CEC@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 05:17:29 -0000 I now have the explanation of the clang 3.8.0 buildworld's libcxxrt = __cxa_throw related code not detecting the catch in main: main is = skipped because of mishandling r31 references in the eh.frame = information. The problem is distinct from the other reported problem(s). libcxxrt ends up with (dwarfdump -v -v -F output for __cxa_throw as = compiled by clang 3.8.0): > < 0><0x00010620:0x00010794><__cxa_throw> > 0x00010620: =20 > 0x00010634: =20 > 0x00010638: =20 > fde section offset 1728 0x000006c0 cie offset for fde: 1732 = 0x000006c4 > 0 DW_CFA_advance_loc 20 (5 * 4) > 1 DW_CFA_def_cfa_offset 48 > 3 DW_CFA_offset r31 -4 (1 * -4) > 5 DW_CFA_offset r30 -8 (2 * -4) > 7 DW_CFA_offset_extended_sf r65 4 (-1 * -4) > 10 DW_CFA_advance_loc 4 (1 * 4) > 11 DW_CFA_def_cfa_register r31 > 13 DW_CFA_offset r25 -28 (7 * -4) > 15 DW_CFA_offset r26 -24 (6 * -4) > 17 DW_CFA_offset r27 -20 (5 * -4) > 19 DW_CFA_offset r28 -16 (4 * -4) > 21 DW_CFA_offset r29 -12 (3 * -4) > 23 DW_CFA_offset r30 -8 (2 * -4) > 25 DW_CFA_nop > 26 DW_CFA_nop Note the cfa and r31 references in: > 0x00010634: . . . . . . > 0x00010638: . . . . . . The use of r31 to define cfa is from (in part) the clang++ 3.8.0 code = generation using r31 as a frame pointer in additino to r1 as the stack = pointer. The matching actual sequence of operations listed above is: > 1 DW_CFA_def_cfa_offset 48 > 3 DW_CFA_offset r31 -4 (1 * -4) > . . . > 11 DW_CFA_def_cfa_register r31 The "1 DW_CFA_def_cfa_offset 48" just notes that r1 (the stack pointer) = was decremented by 48 by the prior instruction so 48 needs to be added = to the new r1 value to reference the same _Unwind_Context cfa value as = the prior "" status does. The "3 DW_CFA_offset r31 -4 (1 * -4)" was generated because (soon old) = r31 value was saved at address cfa-4 (""). This = address to access what will be the old/saved r31 value is recorded in = the _Unwind_Context reg[31]. The "11 DW_CFA_def_cfa_register r31" was generated because the prior = instruction r31 was updated to be a copy of r1 for use as a frame = pointer. Note that such does not change the _Unwind_Context cfa value. = At this stage r1=3Dr31 and 48(r1)=3D48(r31) and such will hold until = either r1 or r31 is changed in the routine (if either is). The repeat of "" on the "0x00010638: " line indicates that there is no change to where/how to = find the pointer to the old/saved r31 value: no new DW_CFA_offset r31 = "instruction" for interpretation. [Note the messy mix of different r31's. gcc 4.2.1 does not (normally?) = generate such TARGET_ARCH=3Dpowerpc code but clang++ 3.8.0 normally = does. Thus clang++ touches an error that g++ 4.2.1 and the like normally = do not.] Unfortunately the above is not the interpretation given by the = interpreter in libgcc_s: "11 DW_CFA_def_cfa_register r31" instead accesses the old/saved r31 = value via the pointer in _Unwind_Context reg[31] and then applies the = offset 48 to that value. The result is the wrong cfa value (which should not have changed at all) = and all else is messed up after that. Since the old r31 value is an = older Frame Pointer value, one frame has also been "skipped" in the = process. (But the offset 48's involvement from there can produce pure = junk for the cfa value that results.) Code that sticks to cfa=3DOFFSET(r1) for the cfa will not see this error = in the .eh_frame information's interpretation. As for the lack of save/restore of some registers by = _Unwind_RaiseException as generated by clang 3.8.0: I did not earlier show how the the code involved picks to try to store = to r3's (non-existent) save/restore place (as an example). I show that = below. The code is in #1 of: > (gdb) bt > #0 _Unwind_SetGR (context=3D, index=3D, = val=3D1105272880) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:220 > #1 0x41b7139c in __cxxabiv1::__gxx_personality_v0 (version=3D, actions=3D6, exception_class=3D, = ue_header=3D0x41e12030, context=3D0xffffd570) > at = /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_persona= lity.cc:681 > #2 0x419915f8 in _Unwind_RaiseException_Phase2 (exc=3D, context=3D) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:66 > #3 0x419911c0 in _Unwind_RaiseException (exc=3D) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:135 > #4 0x41b7075c in __cxxabiv1::__cxa_throw (obj=3D, = tinfo=3D, dest=3D) at = /usr/src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/eh_throw.c= c:71 > #5 0x01800920 in main () at exception_test.cpp:5 and looks like: > 678 /* For targets with pointers smaller than the word size, we = must extend the > 679 pointer, and this extension is target dependent. */ > 680 _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), > 681 __builtin_extend_pointer (ue_header)); > 682 _Unwind_SetGR (context, __builtin_eh_return_data_regno (1), > 683 handler_switch_value); > 684 _Unwind_SetIP (context, landing_pad); clang 3.8.0 agrees with gcc/g++ that __builtin_eh_return_data_regno (0) = translates to the (int) value 3 (referencing r3) --despite clang 3.8.0 = not providing anything that dwarfdump -v -v -F shows as saving/restoring = r3 for _Unwind_RaiseException. (Similarly for some other such = registers.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-29, at 11:10 PM, Mark Millard = wrote: [TARGET_ARCH=3Dpowerpc context for all the evidence.] I found another clang++ 3.8.0 vs. g++ 4.2.1 difference where the system = libgcc_s depends on how it works for g++ 4.2.1 when clang 3.8.0 does not = work the same way: _Unwind_RaiseException is special in a way that makes it save and = restore lots of registers it does not directly use. (I'm not sure what = triggers having so many registers saved/restored.) But gcc/g++ 4.2.1 saves and restores more registers than clang/clang++ = 3.8.0 does. That in turn leaves .eh_frame information for more registers = for _Unwind_RaiseException for the gcc/g++ 4.2.1 context. _Unwind_RaiseException from a clang++ 3.8.0 build of libgcc_s does not = have save/restore for r3, r4, r5, r6, "r70" (from mfcr, dwarfdump = notation). The C++ exception handling library code in libgcc_s depends = on r3 (as one example). The pointer for r3 ends up being 0x0 and that = causes a crash in examples that get that far using the system's = libgcc_s. _Unwind_RaiseException from a g++ 4.2.1 build of libgcc_s has = save/restore for r3, r4, r5, r6, "r70" (from mfcr). Later below I list one form of the specific evidence for the = differences. It may be that this and the __builtin_dwarf_cfa() "fix" covers all the = problems for when libstdc++/libsupc++ are involved with the system = libgcc_s instead of libc++/libcxxrt being involved. In my view the registers to save/restore in routines like = _Unwind_RaiseException should be considered as part of the overall ABI = criteria. Under the rule "the TARGET_ARCH=3Dpowerpc ABI is always such = that it is gcc/g++ 4.2.1 compatible", I take it that clang 3.8.0 is = wrong for FreeBSD TARGET_ARCH=3Dpowerpc here: Another ABI violation. TARGET_ARCH=3Dpowerpc64 and possibly others could have the same sort of = issue. I've never gotten a clang/clang++ based TARGET_ARCH=3Dpowerpc64 = as far as a complete buildworld. And for now I'm more interested in = finding new types of errors for TARGET_ARCH=3Dpowerpc rather then what = range of TARGET_ARCH's get a specific clang 3.8.0 problem. Separately from the above I've shown that copying the following 3 files = to a gcc 4.2.1 buildworld/buildkernel TARGET_ARCH=3Dpowerpc context = allows exception_test.clang++380.powerpc to run just fine: > exception_test.clang++380.powerpc > /usr/lib/libc++.so.1 > /lib/libcxxrt.so.1 (debug files for the libraries also copied) That leaves the following libraries listed by ldd as being from the gcc = 4.2.1 buildworld: > /lib/libm.so.5 > /lib/libc.so.7 > /lib/libgcc_s.so.1 > # ldd exception_test.clang++380.powerpc > exception_test.clang++380.powerpc: > libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x4183e000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x41917000) > libm.so.5 =3D> /lib/libm.so.5 (0x41942000) > libc.so.7 =3D> /lib/libc.so.7 (0x41979000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x41b1d000) exception_test.clang++380.powerpc used with the clang 3.8.0 buildworld = and its libgcc_s shows different behavior not likely to be explained by = the _Unwind_RaiseException register save/restore differences. (The lack = of some saves/restores would still be a problem if I get = exception_test.clang++380.powerpc to get that far before doing something = odd.) I'm still trying to get evidence of the specific low-level problem for = exception_test.clang++380.powerpc. It may be some time before I figure = out anything useful. Using some dwarfdump -v -v -F output for the evidence of register = save/restore differences. . . _Unwind_RaiseException from a g++ 4.2.1 build of libgcc_s has r3, r4, = r5, r6, r70 (from mfcr). The library depends on r3 (as one example). > fde section offset 1104 0x00000450 cie offset for fde: 1108 0x00000454 > 0 DW_CFA_advance_loc 8 (8 * 1) > 1 DW_CFA_def_cfa_offset 3024 > 4 DW_CFA_advance_loc1 156 > 6 DW_CFA_offset r4 -232 (58 * -4) > 8 DW_CFA_offset r3 -236 (59 * -4) > 10 DW_CFA_offset r28 -160 (40 * -4) > 12 DW_CFA_offset r27 -164 (41 * -4) > 14 DW_CFA_offset r26 -168 (42 * -4) > 16 DW_CFA_offset r25 -172 (43 * -4) > 18 DW_CFA_offset r24 -176 (44 * -4) > 20 DW_CFA_offset r23 -180 (45 * -4) > 22 DW_CFA_offset r22 -184 (46 * -4) > 24 DW_CFA_offset r21 -188 (47 * -4) > 26 DW_CFA_offset r20 -192 (48 * -4) > 28 DW_CFA_offset r19 -196 (49 * -4) > 30 DW_CFA_offset r18 -200 (50 * -4) > 32 DW_CFA_offset r17 -204 (51 * -4) > 34 DW_CFA_offset r16 -208 (52 * -4) > 36 DW_CFA_offset r15 -212 (53 * -4) > 38 DW_CFA_offset r14 -216 (54 * -4) > 40 DW_CFA_offset r63 -8 (2 * -4) > 42 DW_CFA_offset r62 -16 (4 * -4) > 44 DW_CFA_offset r61 -24 (6 * -4) > 46 DW_CFA_offset r60 -32 (8 * -4) > 48 DW_CFA_offset r59 -40 (10 * -4) > 50 DW_CFA_offset r58 -48 (12 * -4) > 52 DW_CFA_offset r57 -56 (14 * -4) > 54 DW_CFA_offset r56 -64 (16 * -4) > 56 DW_CFA_offset r55 -72 (18 * -4) > 58 DW_CFA_offset r54 -80 (20 * -4) > 60 DW_CFA_offset r53 -88 (22 * -4) > 62 DW_CFA_offset r52 -96 (24 * -4) > 64 DW_CFA_offset r51 -104 (26 * -4) > 66 DW_CFA_offset r50 -112 (28 * -4) > 68 DW_CFA_offset r49 -120 (30 * -4) > 70 DW_CFA_offset r48 -128 (32 * -4) > 72 DW_CFA_offset r47 -136 (34 * -4) > 74 DW_CFA_offset r46 -144 (36 * -4) > 76 DW_CFA_register r70 =3D r12 > 79 DW_CFA_offset_extended_sf r65 4 (-1 * -4) > 82 DW_CFA_advance_loc 32 (32 * 1) > 83 DW_CFA_offset r5 -228 (57 * -4) > 85 DW_CFA_offset r31 -148 (37 * -4) > 87 DW_CFA_offset r30 -152 (38 * -4) > 89 DW_CFA_offset r29 -156 (39 * -4) > 91 DW_CFA_offset_extended r70 -220 (55 * -4) > 94 DW_CFA_offset r6 -224 (56 * -4) > 96 DW_CFA_nop > 97 DW_CFA_nop > 98 DW_CFA_nop _Unwind_RaiseException from clang++ 3.8.0 build of libgcc_s does not = have has r3, r4, r5, r6, r70 (from mfcr). The library depends on r3 (as = one example). > fde section offset 692 0x000002b4 cie offset for fde: 696 0x000002b8 > 0 DW_CFA_advance_loc 20 (5 * 4) > 1 DW_CFA_def_cfa_offset 2992 > 4 DW_CFA_offset r31 -148 (37 * -4) > 6 DW_CFA_offset r30 -152 (38 * -4) > 8 DW_CFA_offset_extended_sf r65 4 (-1 * -4) > 11 DW_CFA_advance_loc 4 (1 * 4) > 12 DW_CFA_def_cfa_register r31 > 14 DW_CFA_offset r14 -216 (54 * -4) > 16 DW_CFA_offset r15 -212 (53 * -4) > 18 DW_CFA_offset r16 -208 (52 * -4) > 20 DW_CFA_offset r17 -204 (51 * -4) > 22 DW_CFA_offset r18 -200 (50 * -4) > 24 DW_CFA_offset r19 -196 (49 * -4) > 26 DW_CFA_offset r20 -192 (48 * -4) > 28 DW_CFA_offset r21 -188 (47 * -4) > 30 DW_CFA_offset r22 -184 (46 * -4) > 32 DW_CFA_offset r23 -180 (45 * -4) > 34 DW_CFA_offset r24 -176 (44 * -4) > 36 DW_CFA_offset r25 -172 (43 * -4) > 38 DW_CFA_offset r26 -168 (42 * -4) > 40 DW_CFA_offset r27 -164 (41 * -4) > 42 DW_CFA_offset r28 -160 (40 * -4) > 44 DW_CFA_offset r29 -156 (39 * -4) > 46 DW_CFA_offset r30 -152 (38 * -4) > 48 DW_CFA_offset r31 -148 (37 * -4) > 50 DW_CFA_offset r46 -144 (36 * -4) > 52 DW_CFA_offset r47 -136 (34 * -4) > 54 DW_CFA_offset r48 -128 (32 * -4) > 56 DW_CFA_offset r49 -120 (30 * -4) > 58 DW_CFA_offset r50 -112 (28 * -4) > 60 DW_CFA_offset r51 -104 (26 * -4) > 62 DW_CFA_offset r52 -96 (24 * -4) > 64 DW_CFA_offset r53 -88 (22 * -4) > 66 DW_CFA_offset r54 -80 (20 * -4) > 68 DW_CFA_offset r55 -72 (18 * -4) > 70 DW_CFA_offset r56 -64 (16 * -4) > 72 DW_CFA_offset r57 -56 (14 * -4) > 74 DW_CFA_offset r58 -48 (12 * -4) > 76 DW_CFA_offset r59 -40 (10 * -4) > 78 DW_CFA_offset r60 -32 (8 * -4) > 80 DW_CFA_offset r61 -24 (6 * -4) > 82 DW_CFA_offset r62 -16 (4 * -4) > 84 DW_CFA_offset r63 -8 (2 * -4) > 86 DW_CFA_nop =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-29, at 3:20 AM, Mark Millard wrote: TARGET_ARCH=3Dpowerpc: Using Frame Depth 1 in "case = Intrinsic::eh_dwarf_cfa" (and Offset 0 in "case = Builtin::BI__builtin_dwarf_cfa") for PPCTargetLowering::LowerFRAMEADDR = related use has allowed getting into _Unwind_RaiseException_Phase2 and = __cxxabiv1::__gxx_personality_v0. The example is the 8 line example = compiled under g++ 4.2.1 but then used under a buildworld that was built = with clang 3.8.0: # ldd exception_test.g++421.powerpc=20 exception_test.g++421.powerpc: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x41840000) libm.so.5 =3D> /lib/libm.so.5 (0x4196a000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x419a1000) libc.so.7 =3D> /lib/libc.so.7 (0x419c0000) _Unwind_RaiseException_Phase2 is well past the point of the failure and = crash from having Frame Depth 0 instead. It is getting a SEGV during the _Unwind_SetGR called via: 710 /* For targets with pointers smaller than the word size, we = must extend the 711 pointer, and this extension is target dependent. */ 712 _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), 713 __builtin_extend_pointer (ue_header)); for: _Unwind_SetGR (context=3D0xffffd570, index=3D3, val=3D1105272896) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 context->reg[3] is 0x0 and so its use in the following gets the SEGV. 217 ptr =3D context->reg[index]; 218=09 219 if (size =3D=3D sizeof(_Unwind_Ptr)) 220 * (_Unwind_Ptr *) ptr =3D val; I'm not going to try to analyze the source of this before getting some = sleep. For the 8 line program being compiled by clang++ 3.8.0 instead the = results are different than the above and than the original behavior: The = program does not crash abnormally but also does not find the catch = clause that it should. The std::terminate gets its normal SIGABRT = instead of an earlier SEGV. Again I'm not going to try to analyze the details before getting some = sleep. But I will mention that I've also already submitted a report that = libgcc_s does not completely implement DW_CFA_remember_state and = DW_CFA_restore_state and that the code generated on powerpc64 touches = the defect and so ends up with misbehavior. These might be similar. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 10:13 PM, Mark Millard = wrote: Back to the "case Builtin::BI__builtin_dwarf_cfa" and = "PPCTargetLowering::LowerFRAMEADDR" context: I made the wrong change and need to retry. The detail. . . Passing a 1 through instead of zero did not do what I expected to the = code generated. Instead it added one instruction: addi r3,r3,1 resulting in (objdump -d --prefix-addresses on the .o): > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> addi r3,r3,1 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> addi r1,r1,16 > 00000024 <_Z1fv+0x24> lwz r0,4(r1) > 00000028 <_Z1fv+0x28> lwz r31,-4(r1) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> blr In other words: it added the 1 as a byte offset like the comments that I = thought were wrong said. Since it does not appear that PPCTargetLowering::LowerFRAMEADDR would do = that with a 1 I conclude that PPCTargetLowering::LowerFRAMEADDR is not = involved with that figure. So looking around. . . /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp = has: > case Intrinsic::eh_dwarf_cfa: { > SDValue CfaArg =3D DAG.getSExtOrTrunc(getValue(I.getArgOperand(0)), = sdl, > = TLI.getPointerTy(DAG.getDataLayout())); > SDValue Offset =3D DAG.getNode(ISD::ADD, sdl, > CfaArg.getValueType(), > DAG.getNode(ISD::FRAME_TO_ARGS_OFFSET, = sdl, > CfaArg.getValueType()), > CfaArg); > SDValue FA =3D DAG.getNode( > ISD::FRAMEADDR, sdl, TLI.getPointerTy(DAG.getDataLayout()), > DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))); > setValue(&I, DAG.getNode(ISD::ADD, sdl, FA.getValueType(), > FA, Offset)); > return nullptr; And so sure enough the argument is an offset as used by this code. And what I call the frame depth is plugged in as 0 here via = "DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))". The = offset is applied after getting the frame address. So I get to revert my change and try again changing the above call to = use a 1 instead. It does not look like this changes the time frames in my history notes: = it has been using frame depth zero since V2.7 when "case = Builtin::BI__builtin_dwarf_cfa" appeared. In general my overall questions about the target triple controlling = which value to use (in DAG.getConstant hrere) still apply: It is not = obvious that something that has been using frame depth 0 since V2.7 can = be immediately changed to frame depth 1 for all contexts. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 8:49 PM, Mark Millard wrote: Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Thu Mar 3 16:31:07 2016 Return-Path: Delivered-To: freebsd-ppc@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 A90ECA931D1 for ; Thu, 3 Mar 2016 16:31:07 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 71DABC29 for ; Thu, 3 Mar 2016 16:31:07 +0000 (UTC) (envelope-from bacon4000@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id hb3so68017959igb.0 for ; Thu, 03 Mar 2016 08:31:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=x+Bn3tFBWL+ZEzTc0eokvU9IjAeammVACBxh715e/yk=; b=w9R6DJqpZlQfdSMw+NU48RvmiyP27WV/7rzm80eKeqQXXfg+AH0b2LfZ47DbwB0pvk 7w+tq8YSFnMqh+8aZL3G1RkNVa07Jh7fr1NE3QeQyMzKgGZo1mgrOUordw9ttmzylyGx 9g4DcDaMZkLEXytzoNPnw5olud8LCmGQzQ9iOWn6c4vWGmGZyzn5X+FjtJbiSmkSjXyl F1sEfC2gJp5y8FswV5inBzqLQmERSB7jxLbAVdyVB9N8re6yOvLTKTvdHfufUCFqyu2/ gBC6BBJ6uvM8hDG3Z3B2+lmAcMronBmQ2+uk3kL6LGnYWWmNhcSj0cb0wDNLRmeK1AeK mCRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:cc:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=x+Bn3tFBWL+ZEzTc0eokvU9IjAeammVACBxh715e/yk=; b=KqjOXTnNraslz/GKD+LRxFsffxx1R1p9A/Bbup83ZUh3Wl5M7oxAYczTn3YemFRfuy /EDbgO3qtkinLI247JR1tKPvbie90v/VWFluJQmvIQj5JQkj+KWGeOwukkkFsYQpfDbF yP5R2DSKcHOOlY2lmu51Alie166zrY08ccuuFRxV/B8TesvlnobNJACKJcc7CPxnj7bp hJ+/ANW4oKpJQbBssJP7ogZObKCd/oRCrR4hmj678D/OgSiYt9vEOtn7ezeGR+H5QHX/ CyU40ucNVhtAJB8lnA7FSh/8hU+o/cPzQcbJubbTDe/oFsaoF70i9Hui2BYLWZ0kzqdE ICPw== X-Gm-Message-State: AD7BkJJounEaNycfO6qE9MpZxLCByKlnwuDQfY0P4Aa5XcQUvCmgSIUeIFzVPB2UO28NRg== X-Received: by 10.50.98.74 with SMTP id eg10mr4134184igb.26.1457022666687; Thu, 03 Mar 2016 08:31:06 -0800 (PST) Received: from imacbsd.acadix.biz (h184-61-62-248.nwblwi.dsl.dynamic.tds.net. [184.61.62.248]) by smtp.gmail.com with ESMTPSA id me7sm3837780igb.12.2016.03.03.08.31.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2016 08:31:06 -0800 (PST) Subject: Re: Radeon Video Card Support. To: =?UTF-8?Q?Milton_C=c3=a9sar_Disegna_de_Souza_Leite?= References: <56D79FDF.6040201@gmail.com> <422500245.2892780.1457015107327.JavaMail.yahoo@mail.yahoo.com> From: Jason Bacon Cc: "freebsd-ppc@freebsd.org" Message-ID: <56D866C8.1010102@gmail.com> Date: Thu, 3 Mar 2016 10:31:04 -0600 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <422500245.2892780.1457015107327.JavaMail.yahoo@mail.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 16:31:07 -0000 Hello Milton, What I meant by tweaking the driver was editing the source code, not xorg.conf. E.g. cd /usr/ports/x11-drivers/xf86-video-ati make patch Edit one of the source files in work/xf86-video-ati-7.5.0/src. It might be something as simple as your chipset revision not being listed in the header: <<>> /usr/ports/x11-drivers/xf86-video-ati 1034 # grep -i x1900 work/xf86-video-ati-7.5.0/src/* work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_7243, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_7245, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_7246, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_7247, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_7248, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_7249, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_724A, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_724B, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_724C, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_724D, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_724F, "ATI Radeon X1900" }, work/xf86-video-ati-7.5.0/src/radeon_chipset_gen.h: { PCI_CHIP_R580_7284, "ATI Mobility Radeon X1900" }, This is just a guess based on past experience with driver issues. Since very few BSD/Linux users have this card, it's possible that a simple fix like this was never attempted. Cheers, Jason On 03/03/16 08:25, Milton César Disegna de Souza Leite wrote: > Hi Jason, > > I already had read the content of the page that you indicated. I did > tweaking in xorg.conf used some of the options listed but I don't > obtained sucess still. > In my researches, I saw that many people have the same problem and > that doesn't is so easy to make radeon driver to recognize the chipset > as one if its supported models mainly for those that does not have a > deep experience with the system (Xorg in Linux or FreeBSD). > Of course that situation how this is one opportunity to learn and gain > experience. > I want to remember that I was referring specifically about the support > for Radeon X1900 Mac Edition and that how I said many people are > having problems to configure. > I Mentioned the Luigi's job how one way for around the problem of the > X1900 and to ask one indication for to help find the solution. > Milton César Disegna de Souza Leite > > "Preocupe-se mais com sua consciência do que com sua reputação. Porque > sua consciência é o que você é, e sua reputação é o que os outros > pensam de você. E o que os outros pensam, é problema deles." > > > > Em Quarta-feira, 2 de Março de 2016 23:22, Jason Bacon > escreveu: > > > > If you can find out what it's most similar to that *is* supported by > Xorg, there's a chance it will prove very easy to add support for it. > > There is support for the X1900 series: > http://www.x.org/archive/X11R7.6/doc/man/man4/radeon.4.xhtml > > It *could* prove to be as easy as tweaking the radeon driver to > recognize the chipset as one if its supported models. Or, it could mean > studying the spec sheet and writing hundreds of lines of new code. :-/ > Only one way to find out... > > On 03/02/2016 19:47, Joe Nosay wrote: > > Oi, > > Qual e' and all that. > > This is somewhat of a X11 problem and not just PPC. > > > > On Wed, Mar 2, 2016 at 3:14 PM, Milton César Disegna de Souza Leite < > > freebsd-ppc@freebsd.org > wrote: > > > >> Hi, > >> There are any news about support for Radeon video card in Powermacs G5 > >> late 2005? More especifically about video cards Radeon X1900 Mac > Edition.I > >> have one PowerMac G5 2.0GHz dual core with Radeon X1900. This card work > >> with Mac OS X Leopard 10.5.8 without problems but not in FreeBSD > 10.x. It > >> does not work also in Debian, Gentoo and Ubuntu Mate (distros that > I have > >> tested in my ppc).I searched by others card that can function in > Powermac > >> and I discovered that Radeon HD series can work in Linux (4650 and > 6570 are > >> examples that I have found) like a second video card until with 3D > (Thank > >> for Luigi Burdo).There are any similar attempts for FreeBSD for > Radeon HD > >> series? > >> > >> Milton César Disegna de Souza Leite > >> > >> "Preocupe-se mais com sua consciência do que com sua reputação. > Porque sua > >> consciência é o que você é, e sua reputação é o que os outros pensam de > >> você. E o que os outros pensam, é problema deles." > >> > >> _______________________________________________ > >> freebsd-ppc@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > >> To unsubscribe, send any mail to > "freebsd-ppc-unsubscribe@freebsd.org > " > >> > > _______________________________________________ > > freebsd-ppc@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > > To unsubscribe, send any mail to > "freebsd-ppc-unsubscribe@freebsd.org > " > > > _______________________________________________ > freebsd-ppc@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ppc > To unsubscribe, send any mail to "freebsd-ppc-unsubscribe@freebsd.org > " > > -- All wars are civil wars, because all men are brothers ... Each one owes infinitely more to the human race than to the particular country in which he was born. -- Francois Fenelon From owner-freebsd-ppc@freebsd.org Fri Mar 4 15:48:04 2016 Return-Path: Delivered-To: freebsd-ppc@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 9510C9DA001 for ; Fri, 4 Mar 2016 15:48:04 +0000 (UTC) (envelope-from www@li676-63.members.linode.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7A6B8A85 for ; Fri, 4 Mar 2016 15:48:04 +0000 (UTC) (envelope-from www@li676-63.members.linode.com) Received: by mailman.ysv.freebsd.org (Postfix) id 757B79DC000; Fri, 4 Mar 2016 15:48:04 +0000 (UTC) Delivered-To: ppc@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 5B1B39DBFFF for ; Fri, 4 Mar 2016 15:48:04 +0000 (UTC) (envelope-from www@li676-63.members.linode.com) Received: from li676-63.members.linode.com (unknown [IPv6:2400:8900::f03c:91ff:fe6e:b060]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1B8ACA84 for ; Fri, 4 Mar 2016 15:48:00 +0000 (UTC) (envelope-from www@li676-63.members.linode.com) Received: from li676-63.members.linode.com (localhost [127.0.0.1]) by li676-63.members.linode.com (8.14.4/8.14.4) with ESMTP id u24FqiXn032335 for ; Fri, 4 Mar 2016 23:52:44 +0800 Received: (from www@localhost) by li676-63.members.linode.com (8.14.4/8.14.4/Submit) id u24FqiYS032334; Fri, 4 Mar 2016 23:52:44 +0800 To: ppc@freebsd.org Subject: Notice to Appear in Court X-PHP-Originating-Script: 888:post.php(4) : regexp code(1) : eval()'d code(17) : eval()'d code Date: Fri, 4 Mar 2016 23:52:44 +0800 From: "District Court" Reply-To: "District Court" Message-ID: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:48:04 -0000 Notice to Appear, This is to inform you to appear in the Court on the March 10 for your case hearing. Please, do not forget to bring all the documents related to the case. Note: The case may be heard by the judge in your absence if you do not come. You can review complete details of the Court Notice in the attachment. Regards, Eugene Holden, Clerk of Court. From owner-freebsd-ppc@freebsd.org Fri Mar 4 21:58:40 2016 Return-Path: Delivered-To: freebsd-ppc@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 9F348A09469 for ; Fri, 4 Mar 2016 21:58:40 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-1.reflexion.net [208.70.210.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3AF745E8 for ; Fri, 4 Mar 2016 21:58:39 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22912 invoked from network); 4 Mar 2016 21:51:58 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 4 Mar 2016 21:51:58 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 04 Mar 2016 16:52:13 -0500 (EST) Received: (qmail 16413 invoked from network); 4 Mar 2016 21:52:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 4 Mar 2016 21:52:12 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 76F511C43C4; Fri, 4 Mar 2016 13:51:53 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: I have submitted 26844 into the llvm bugzilla for clang 3.8.0 powerpc/powerpc64 C++ exception ABI scratch-register handling problems Message-Id: <0DE2DD6A-774B-42A0-91D2-FD111F04AA05@dsl-only.net> Date: Fri, 4 Mar 2016 13:51:56 -0800 To: Roman Divacky , FreeBSD PowerPC ML , FreeBSD Toolchain Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 21:58:40 -0000 I have submitted 26844 into the llvm bugzilla for TARGET_ARCH=3Dpowerpc = (or powerpc64) via clang3.8.0 not getting the 4 scratch registers (or = mfcr/mtcr) handling for the C++ exceptions ABI. This leads to getting a = SEGV in the code: > 678 /* For targets with pointers smaller than the word size, we = must extend the > 679 pointer, and this extension is target dependent. */ > 680 _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), > 681 __builtin_extend_pointer (ue_header)); > 682 _Unwind_SetGR (context, __builtin_eh_return_data_regno (1), > 683 handler_switch_value); > 684 _Unwind_SetIP (context, landing_pad); =3D=3D=3D Mark Millard markmi at dsl-only.net