From owner-freebsd-ppc@freebsd.org Sun Oct 29 00:04:01 2017 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 47CE7E518D0; Sun, 29 Oct 2017 00:04:01 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 BFC8B14B0; Sun, 29 Oct 2017 00:04:00 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id p184so10957947lfe.12; Sat, 28 Oct 2017 17:04:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UFBzB5yRggvmXSDA4i1Qx52O0bkv2bZ/nYuU+euMvgk=; b=fU3+b3N/Gmo/dkK922Q1iee9G1TFAsJEKAosUB1dunBsi8tDtd1oTyNATL4GCsFdn6 P5k9dGpI2aCYUGId0nxPbGHP0N6VyXf1yPc3aJMp97eqwldhLi2y7BGSYvLjKHS5x3Kj mitcpvoAoXk6rS0OECw5oldobLe11Neq/EKJzLQ01qOmt9CGfrpQgCk2VUI/zt8cne/G sbqSU+wFWv4+07OzU3rfFHMbhzT/v3hE5PhMfVevLqL3qZqpJbeJEKtnDyEjeTVmHt3b jXFwGfy1vqTIBHXFzxJ7neO+6a07GPI4xLXoWKGa792MmmzvJ80HgfNhJbfYuH6BOb+a 9N6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UFBzB5yRggvmXSDA4i1Qx52O0bkv2bZ/nYuU+euMvgk=; b=FBQzTkqmwfvLrfvNotlchJdip5FsGEzQXSGpoYBzZYM9ILMBiG9YwAAXtl6mNlVOkS xqO4g82KTsm232MZ4I5i13w21DwJfWdzFJy4KQLKExJva8oybokpMDIRR4FwjX7O3W10 gqqeSLbky8FKyiVWM+p6jZ3u3/hU2+q70ihETrQ6f1QQeqj/XJUh3BtBFYLcUJuJ9tsS bl3/bsoE9OwGXiu0VH9g3koBf61iK3pzWkwT7L4aASmdXNm+97/VK/L08Q3tSD8rZNCx aCfqvdzn5uxNdnL9MoVT8AVRUQc7HeJtpMufB0DaKMV+IBFSDtNvthsQT+9KTsUZoKHl x1VA== X-Gm-Message-State: AMCzsaUzEzqIxw4C/lCb5DLEwYQ20a/CswcN/CKAs8VHp7AwZCj0ja6u 17GOeILwwqi0KEJIb17AMSdTGymIG1id53MIU7A= X-Google-Smtp-Source: ABhQp+QQv5zVIkFek73MYXAU4RowfgEYqOlg6zKRWubY+fePD+NzHFjRLlACqPp1uakSFPO/9e5b+6wWQRoH6tf/HvM= X-Received: by 10.46.93.137 with SMTP id v9mr1796791lje.39.1509235438668; Sat, 28 Oct 2017 17:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.86.7 with HTTP; Sat, 28 Oct 2017 17:03:57 -0700 (PDT) Received: by 10.46.86.7 with HTTP; Sat, 28 Oct 2017 17:03:57 -0700 (PDT) In-Reply-To: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> From: Justin Hibbits Date: Sat, 28 Oct 2017 19:03:57 -0500 Message-ID: Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? To: Mark Millard Cc: FreeBSD PowerPC ML , freebsd-hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 00:04:01 -0000 Hi Mark On Oct 28, 2017 17:08, "Mark Millard" wrote: powerpc64 and powerpc have very different stack handling rules for FreeBSD. As an example, powerpc does not require red-zones for signal handling in the kernel but powerpc64 does. For lib32 support, what ABI is the powerpc code supposed to follow in the powerpc64 environment? What style of stack handling (and related register usage) is supposed to be in use? If it is distinct from powerpc native's ABI, what documentation should be looked at for the ABI? === Mark Millard markmi at dsl-only.net PowerPC via lib32 should be using the 32-bit svr4 ABI. If you see any discrepancy in that, it's a bug that needs fixed. - Justin From owner-freebsd-ppc@freebsd.org Sun Oct 29 00:54:32 2017 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 9BCE9E52F27 for ; Sun, 29 Oct 2017 00:54:32 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-116.reflexion.net [208.70.210.116]) (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 367CC2F38 for ; Sun, 29 Oct 2017 00:54:31 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13815 invoked from network); 29 Oct 2017 00:54:29 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 29 Oct 2017 00:54:29 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sat, 28 Oct 2017 20:54:29 -0400 (EDT) Received: (qmail 6974 invoked from network); 29 Oct 2017 00:54:29 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2017 00:54:29 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 77492EC8676; Sat, 28 Oct 2017 17:54:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: Date: Sat, 28 Oct 2017 17:54:27 -0700 Cc: FreeBSD PowerPC ML , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 00:54:32 -0000 Hello Justin > On 2017-Oct-28, at 5:03 PM, Justin Hibbits = wrote: >=20 >> On Oct 28, 2017 17:08, "Mark Millard" wrote: >> powerpc64 and powerpc have very different stack handling >> rules for FreeBSD. As an example, powerpc does not require >> red-zones for signal handling in the kernel but powerpc64 >> does. >>=20 >> For lib32 support, what ABI is the powerpc code supposed >> to follow in the powerpc64 environment? What style of >> stack handling (and related register usage) is supposed >> to be in use? If it is distinct from powerpc native's >> ABI, what documentation should be looked at for the ABI? >=20 > PowerPC via lib32 should be using the 32-bit svr4 ABI. If you see any = discrepancy in that, it's a bug that needs fixed. Then I expect that the reason that devel/powerpc64-gcc based buildworld's make a lib32 that fails in code that is from /usr/lib32/crtbeginS.o is because /usr/lib32/crtbeginS.o ends up not having the right ABI involved and, so, misuses at least one register. (I've not worked out if there is any special transition from one ABI to the other (and later back) that is needed vs. not. But the red-zoning for powerpc64 should be more than sufficient for powerpc code that does not require it.) An interesting point is: (all on a powerpc64 FreeBSD head -r324071 system) # clang -dumpmachine -m32 powerpc-unknown-freebsd12.0 # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine -m32 powerpc64-unknown-freebsd12.0 # gcc7 -dumpmachine -m32 powerpc64-portbld-freebsd12.0 # clang -dumpmachine powerpc64-unknown-freebsd12.0 # /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -dumpmachine powerpc64-unknown-freebsd12.0 # gcc7 -dumpmachine powerpc64-portbld-freebsd12.0 (But I'm not sure that these always reflect ABI variations in code generated.) I wonder if for gcc it takes a separate compiler to have powerpc-unknown-freebsd12.0 (intending to imply the FreeBSD 32-bit ABI is in use). bugzilla 206123 should probably have notes added about the probable ABI mismatch in /usr/lib32/crtbeginS.o. I may add this whole message but someone with better background information may able to submit more specific material. At this point I do not know how to control what ABI code is generated by devel/powerpc64-gcc in what becomes /usr/lib32/crtbeginS.o (or how other code interfaces with crtbeginS.o code). Its been a long time since I tried other gcc variations but all of them had the issue when I did try. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Oct 29 13:50:12 2017 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 165B0E63DBA for ; Sun, 29 Oct 2017 13:50:12 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-104.reflexion.net [208.70.210.104]) (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 BC9D77E84F for ; Sun, 29 Oct 2017 13:50:11 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 19252 invoked from network); 29 Oct 2017 13:50:10 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Oct 2017 13:50:10 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 29 Oct 2017 09:50:10 -0400 (EDT) Received: (qmail 6352 invoked from network); 29 Oct 2017 13:50:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2017 13:50:09 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 55C86EC7B89; Sun, 29 Oct 2017 06:50:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> Date: Sun, 29 Oct 2017 06:50:08 -0700 Cc: FreeBSD PowerPC ML , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 13:50:12 -0000 [Message history removed as this does not flow well with the prior material.] I've figured out the mismatch and, so, why/how lib32 fails for devel/powerpc64-gcc based builds: the .init code generation for devel/powerpc64-gcc is tied to the glibc crti.S for powerpc and that does not match what FreeBSD has for the interface between the two parts. As of 6 years ago or so glibc has code like (I'm only dealing with the init side of things as an example): .section .init,"ax",@progbits stwu r1, -16(r1) . . . bcl 29,31,.LMAGIC_LABEL .LMAGIC_LABEL: mflr r30 addis r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@ha addi r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@l . . . (some pre-init function code) . . . that comes before code that is from frame_dummy and __do_global_ctors_aux (that are from /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/libgcc/crtstuff.c = ). The code generated for frame_dummy and __do_global_ctors_aux expects r30 to already be set up for _GLOBAL_OFFSET_TABLE_ related use by the kind of code that I showed above. Instead FreeBSD has for powerpc just: (things are configured for devel/powerpc64-gcc to use it) #include __FBSDID("$FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 = 11:34:58Z kib $"); .section .init,"ax",@progbits .align 2 .globl _init .type _init,@function _init: stwu 1,-16(1) mflr 0 stw 31,12(1) stw 0,20(1) mr 31,1 The overall result ends up being (from an example .so): 0000214c <_init> stwu r1,-16(r1) 00002150 <_init+0x4> mflr r0 00002154 <_init+0x8> stw r31,12(r1) 00002158 <_init+0xc> stw r0,20(r1) 0000215c <_init+0x10> mr r31,r1 (The above is the FreeBSD crti.S code.) (Note the lack of initialization of r30 to the _GLOBAL_OFFSET_TABLE_ related value.) (The below is the crtstuff.c frame_dummy code inlined in a way that the function prolog code is not present here.) (Note the dependence on r30 having already been initialized.) 00002160 <_init+0x14> lwz r3,-712(r30) 00002164 <_init+0x18> lwz r9,0(r3) 00002168 <_init+0x1c> cmpwi cr7,r9,0 0000216c <_init+0x20> beq- cr7,00002184 <_init+0x38> 00002170 <_init+0x24> lwz r9,-16(r30) 00002174 <_init+0x28> cmpwi cr7,r9,0 00002178 <_init+0x2c> beq- cr7,00002184 <_init+0x38> 0000217c <_init+0x30> mtctr r9 00002180 <_init+0x34> bctrl (The below is the crtstuff.c __do_global_ctors_aux loop code but inlined. . .) 00002184 <_init+0x38> lwz r29,-36(r30) 00002188 <_init+0x3c> lwzu r9,-4(r29) 0000218c <_init+0x40> cmpwi cr7,r9,-1 00002190 <_init+0x44> beq- cr7,000021a8 <_init+0x5c> 00002194 <_init+0x48> mtctr r9 00002198 <_init+0x4c> bctrl 0000219c <_init+0x50> lwzu r9,-4(r29) 000021a0 <_init+0x54> cmpwi cr7,r9,-1 000021a4 <_init+0x58> bne+ cr7,00002194 <_init+0x48> (The rest of the .init code follows.) 000021a8 <_init+0x5c> lwz r11,0(r1) 000021ac <_init+0x60> lwz r0,4(r11) 000021b0 <_init+0x64> mtlr r0 000021b4 <_init+0x68> lwz r31,-4(r11) 000021b8 <_init+0x6c> mr r1,r11 000021bc <_init+0x70> blr The way the compiler's source code is structured and works it looks to me like the crti.S used needs to have the initialization code for r30. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sun Oct 29 22:46:56 2017 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 EB95FE4E492 for ; Sun, 29 Oct 2017 22:46:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-139.reflexion.net [208.70.210.139]) (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 A88E76A1ED for ; Sun, 29 Oct 2017 22:46:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 32598 invoked from network); 29 Oct 2017 22:46:48 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Oct 2017 22:46:48 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 29 Oct 2017 18:46:48 -0400 (EDT) Received: (qmail 20373 invoked from network); 29 Oct 2017 22:46:48 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 29 Oct 2017 22:46:48 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D1102EC8683; Sun, 29 Oct 2017 15:46:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> Date: Sun, 29 Oct 2017 15:46:47 -0700 Cc: FreeBSD PowerPC ML , freebsd-hackers Content-Transfer-Encoding: quoted-printable Message-Id: <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 22:46:57 -0000 [I add notes about what I see in the SysVR4 powerpc ABI document about r30 vs. _GLOBAL_OFFSET_TABLE_ use --and some notes about more modern Power Architecture=C2=AE 32-bit Application Binary Interface Supplement 1.0 material that does, by contrast, specify a type of context where r30 must be used for the purpose. Bugzilla 206123 now has this material as well.] On 2017-Oct-29, at 6:50 AM, Mark Millard wrote: > [Message history removed as this does not flow well with > the prior material.] >=20 > I've figured out the mismatch and, so, why/how lib32 > fails for devel/powerpc64-gcc based builds: the > .init code generation for devel/powerpc64-gcc is tied > to the glibc crti.S for powerpc and that does not > match what FreeBSD has for the interface between > the two parts. >=20 > As of 6 years ago or so glibc has code like (I'm > only dealing with the init side of things as an > example): >=20 > .section .init,"ax",@progbits > stwu r1, -16(r1) > . . . > bcl 29,31,.LMAGIC_LABEL > .LMAGIC_LABEL: > mflr r30 > addis r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@ha > addi r30, r30, _GLOBAL_OFFSET_TABLE_-.LMAGIC_LABEL@l > . . . (some pre-init function code) . . . >=20 > that comes before code that is from frame_dummy > and __do_global_ctors_aux (that are from > = /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.3.0/libgcc/crtstuff.c = ). >=20 > The code generated for frame_dummy and > __do_global_ctors_aux expects r30 to already > be set up for _GLOBAL_OFFSET_TABLE_ related > use by the kind of code that I showed above. >=20 >=20 > Instead FreeBSD has for powerpc just: > (things are configured for devel/powerpc64-gcc > to use it) >=20 > #include > __FBSDID("$FreeBSD: head/lib/csu/powerpc/crti.S 217399 2011-01-14 = 11:34:58Z kib $"); >=20 > .section .init,"ax",@progbits > .align 2 > .globl _init > .type _init,@function > _init: > stwu 1,-16(1) > mflr 0 > stw 31,12(1) > stw 0,20(1) > mr 31,1 >=20 > The overall result ends up being (from > an example .so): >=20 > 0000214c <_init> stwu r1,-16(r1) > 00002150 <_init+0x4> mflr r0 > 00002154 <_init+0x8> stw r31,12(r1) > 00002158 <_init+0xc> stw r0,20(r1) > 0000215c <_init+0x10> mr r31,r1 > (The above is the FreeBSD crti.S code.) > (Note the lack of initialization of r30 > to the _GLOBAL_OFFSET_TABLE_ related value.) >=20 > (The below is the crtstuff.c frame_dummy code > inlined in a way that the function prolog code > is not present here.) > (Note the dependence on r30 having already been > initialized.) > 00002160 <_init+0x14> lwz r3,-712(r30) > 00002164 <_init+0x18> lwz r9,0(r3) > 00002168 <_init+0x1c> cmpwi cr7,r9,0 > 0000216c <_init+0x20> beq- cr7,00002184 <_init+0x38> > 00002170 <_init+0x24> lwz r9,-16(r30) > 00002174 <_init+0x28> cmpwi cr7,r9,0 > 00002178 <_init+0x2c> beq- cr7,00002184 <_init+0x38> > 0000217c <_init+0x30> mtctr r9 > 00002180 <_init+0x34> bctrl >=20 > (The below is the crtstuff.c __do_global_ctors_aux > loop code but inlined. . .) > 00002184 <_init+0x38> lwz r29,-36(r30) > 00002188 <_init+0x3c> lwzu r9,-4(r29) > 0000218c <_init+0x40> cmpwi cr7,r9,-1 > 00002190 <_init+0x44> beq- cr7,000021a8 <_init+0x5c> > 00002194 <_init+0x48> mtctr r9 > 00002198 <_init+0x4c> bctrl > 0000219c <_init+0x50> lwzu r9,-4(r29) > 000021a0 <_init+0x54> cmpwi cr7,r9,-1 > 000021a4 <_init+0x58> bne+ cr7,00002194 <_init+0x48> >=20 > (The rest of the .init code follows.) > 000021a8 <_init+0x5c> lwz r11,0(r1) > 000021ac <_init+0x60> lwz r0,4(r11) > 000021b0 <_init+0x64> mtlr r0 > 000021b4 <_init+0x68> lwz r31,-4(r11) > 000021b8 <_init+0x6c> mr r1,r11 > 000021bc <_init+0x70> blr >=20 > The way the compiler's source code is structured > and works it looks to me like the crti.S used needs > to have the initialization code for r30. I've looked an a copy of the 1995 Sun Microsystems PPC SYSVR4 ABI document and its table 3-3 about processor register usage is not explicit about a specific register being used relative to _GLOBAL_OFFSET_TABLE_ handling. There are examples that say things like: Assumes GOT pointer in r31 but as far as I can tell no place requires that. In fact there is wording like: Combining the offset with the global offset table address in a general = register (for example, r31 loaded in the sample prologue in Figure 3-33) = gives the absolute address of the table entry holding the desired = address. which explicitly indicates "in a general register". It appears that crti.S type code for share libraries requires a local convention for the choice of register that the compiler and library must agree on. So r30 looks to be a valid choice but possibly compiler specific for a FreeBSD context. But there may be a reason to stick with r30. . . Looking in Power-Arch-32-bit-ABI-supp-1.0-Linux.pdf reports that: Under the Secure-PLT ABI, when using the Position-Independent Code (PIC) = addressing model, register r30 is used (by convention between compiler & = link editor) in nonleaf functions to hold the Global Offset Table (GOT) = pointer. . . . Using r30 to hold the address of the _GLOBAL_OFFSET_TABLE_ symbol is the = current convention used by the compiler and link-editor and is only required for nonleaf = routines which use the PIC addressing model. Leaf routines or code not = using the PIC addressing model may use any available unreserved = general-purpose register to hold the address of the = _GLOBAL_OFFSET_TABLE_ symbol. . . . The PIC call stub sequence requires that the compiler ensure that the = register used to hold the _GLOBAL_OFFSET_TABLE_ pointer is set before = any calls are made from the PLT. The current convention between the = compiler and link editor is that r30 be used for this purpose. This is a = change from the BSS-PLT ABI which only required GOT addressing to access = static storage. . . . For non-PIC code, r30 will not hold the GOT pointer; so the stubs must = be different, as shown in the following implementation. . . . Note: This ABI does not require a fixed GOT register, or even one = register used throughout a binary. Non-PIC code does not set the = _GLOBAL_OFFSET_TABLE_ pointer and does not need to reserve a register = for that purpose. Code under the PIC addressing model that accesses = static storage or calls nonlocal functions will need a register to hold = the _GLOBAL_OFFSET_TABLE_ pointer. However, leaf functions or functions = that only call other functions which are static (@local) may use any = general-purpose register within the constraints for the existing ABI. [End quotes.] By contrast Power-Arch-32-bit-ABI-supp-1.0-Embedded.pdf does not say much about r30 use, including not specifying the Secure-PLT ABI material. The referenced documents are examples of: Power Architecture=C2=AE 32-bit Application Binary Interface Supplement = 1.0 documents published in, for example, 2011 (Power.org copyright for that date but various other copyrights for various earlier dates). =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Oct 30 05:25:43 2017 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 E7659E546B2 for ; Mon, 30 Oct 2017 05:25:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-132.reflexion.net [208.70.210.132]) (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 A0E00743AC for ; Mon, 30 Oct 2017 05:25:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24349 invoked from network); 30 Oct 2017 02:38:56 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Oct 2017 02:38:56 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Sun, 29 Oct 2017 22:38:56 -0400 (EDT) Received: (qmail 1149 invoked from network); 30 Oct 2017 02:38:56 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Oct 2017 02:38:56 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 68E15EC9443; Sun, 29 Oct 2017 19:38:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> Date: Sun, 29 Oct 2017 19:38:54 -0700 Cc: freebsd-hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net> References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 05:25:44 -0000 I've found a way in which crti.o and crtbeginS.o and the like are broken for cross builds such as amd64 -> powerpc64 based builds: These first --print-file-name outputs are from on my amd64 -> powerpc64 cross build environment: # which clang /usr/bin/clang # clang --print-file-name=3Dcrti.o /usr/lib/crti.o # clang -m32 --print-file-name=3Dcrti.o /usr/lib32/crti.o # clang --print-file-name=3DcrtbeginS.o /usr/lib/crtbeginS.o # clang -m32 --print-file-name=3DcrtbeginS.o /usr/lib32/crtbeginS.o # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3Dcrti.o crti.o # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3Dcrti.o crti.o # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o crtbeginS.o # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.o = = crtbeginS.o (Note the lack of path prefixes above: they are not explicitly from /usr/local/lib/. . . for some reason. System ones would not be appropriate. Note that nothing differentiates -m32 use.) It looks like the path oddities cause lack of dining any crti.o or crtbeginS.o or the like, which causes the compiler/linker to work differently from different materials that are internal to devel/powerpc64-gcc . # gcc7 --print-file-name=3Dcrti.o /usr/lib/crti.o # gcc7 -m32 --print-file-name=3Dcrti.o /usr/lib/crti.o # gcc7 --print-file-name=3DcrtbeginS.o /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o # gcc7 -m32 --print-file-name=3DcrtbeginS.o = = = /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o (Odd mix of system and gcc7 materials above? Note the lack of -m32 having a distinct path as well.) On my (clang built) powerpc64 environment powerpc64-unknown-freebsd12.0-gcc ends up with different results: # clang --print-file-name=3Dcrti.o /usr/lib/crti.o # clang -m32 --print-file-name=3Dcrti.o /usr/lib32/crti.o # clang --print-file-name=3DcrtbeginS.o /usr/lib/crtbeginS.o # clang -m32 --print-file-name=3DcrtbeginS.o /usr/lib32/crtbeginS.o # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3Dcrti.o /usr/lib/crti.o # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3Dcrti.o /usr/lib/../lib32/crti.o # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o /usr/lib/crtbeginS.o # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.o /usr/lib/../lib32/crtbeginS.o (Path prefixes present above. Using system ones would not be likely to match using /usr/local/lib/. . . ones from a cross build environment. But to have builds from both hosts be equivalent would require the hosts to use the same files [by content].) # gcc7 --print-file-name=3Dcrti.o /usr/lib/crti.o # gcc7 -m32 --print-file-name=3Dcrti.o /usr/lib/../lib32/crti.o # gcc7 --print-file-name=3DcrtbeginS.o /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/crtbeginS.o # gcc7 -m32 --print-file-name=3DcrtbeginS.o = /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/32/crtbeginS.o= (Again the odd(?) system vs. gcc mix for gcc7. But the -m32 path is distinct in this context.) Does devel/powerpc64-gcc for cross builds require taking control of the crti.o and crtbeginS.o (and . . .) generation to force a match to what self-hosted would have on the target architecture? (nothing found.) Note that /usr/local/. . . does not even have the likes of crti.o or crtbeginS.o (or so on) for devel/powerpc64-gcc to use in cross builds: # find /usr/local/ -name "crtbeginS.o" -print | more = = =20 /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o (This also confirms that lack of a . . ./32/crtbeginS.o for the amd64 native gcc7 compiler.) It appears that devel/powerpc64-gcc used for cross builds is generating what would otherwise be crti.o and crtbeginS.o content on the fly as needed during its compiles: there are none around to use the contents of. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Mon Oct 30 07:24:04 2017 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 ADF69E5627C for ; Mon, 30 Oct 2017 07:24:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-117.reflexion.net [208.70.210.117]) (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 6F49D77742 for ; Mon, 30 Oct 2017 07:24:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 15023 invoked from network); 30 Oct 2017 07:23:57 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 30 Oct 2017 07:23:57 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Mon, 30 Oct 2017 03:23:57 -0400 (EDT) Received: (qmail 29873 invoked from network); 30 Oct 2017 07:23:57 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 30 Oct 2017 07:23:57 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D09CAEC8683; Mon, 30 Oct 2017 00:23:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Question for powerpc64 lib32 (powerpc) support: what ABI is the powerpc code supposed to be using? From: Mark Millard In-Reply-To: <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net> Date: Mon, 30 Oct 2017 00:23:56 -0700 Cc: freebsd-hackers , FreeBSD PowerPC ML Content-Transfer-Encoding: quoted-printable Message-Id: References: <618F5419-0BB7-496E-B1B8-DA8BE6D54A58@dsl-only.net> <299784B1-55F3-4C39-B07B-CE6C9E9BB2A8@dsl-only.net> <67C51163-D178-4CAC-AA3C-1178EDD22E01@dsl-only.net> <68CE11EB-1C94-4F3F-B593-162E0B9E0537@dsl-only.net> <8CF73C8D-19A7-407C-9538-6D02F8FBBD1C@dsl-only.net> To: Justin Hibbits X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Oct 2017 07:24:04 -0000 [It is not as bad as I was thinking as far as the --print-file-name output goes.] On 2017-Oct-29, at 7:38 PM, Mark Millard wrote: > I've found a way in which crti.o and crtbeginS.o and > the like are broken for cross builds such as > amd64 -> powerpc64 based builds: >=20 >=20 > These first --print-file-name > outputs are from on my > amd64 -> powerpc64 cross build > environment: >=20 > # which clang > /usr/bin/clang >=20 > # clang --print-file-name=3Dcrti.o > /usr/lib/crti.o > # clang -m32 --print-file-name=3Dcrti.o > /usr/lib32/crti.o >=20 > # clang --print-file-name=3DcrtbeginS.o > /usr/lib/crtbeginS.o > # clang -m32 --print-file-name=3DcrtbeginS.o > /usr/lib32/crtbeginS.o >=20 > # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3Dcrti.o > crti.o > # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3Dcrti.o > crti.o >=20 > # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o > crtbeginS.o > # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.o= = crtbeginS.o >=20 > (Note the lack of path prefixes above: they are not > explicitly from /usr/local/lib/. . . for some reason. > System ones would not be appropriate. Note that nothing > differentiates -m32 use.) >=20 > It looks like the path oddities cause lack of dining > any crti.o or crtbeginS.o or the like, which causes > the compiler/linker to work differently from > different materials that are internal to > devel/powerpc64-gcc . >=20 > # gcc7 --print-file-name=3Dcrti.o > /usr/lib/crti.o > # gcc7 -m32 --print-file-name=3Dcrti.o > /usr/lib/crti.o >=20 > # gcc7 --print-file-name=3DcrtbeginS.o > /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o > # gcc7 -m32 --print-file-name=3DcrtbeginS.o = = = /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o >=20 > (Odd mix of system and gcc7 materials above? > Note the lack of -m32 having a distinct path > as well.) >=20 > On my (clang built) powerpc64 environment > powerpc64-unknown-freebsd12.0-gcc ends > up with different results: >=20 > # clang --print-file-name=3Dcrti.o > /usr/lib/crti.o > # clang -m32 --print-file-name=3Dcrti.o > /usr/lib32/crti.o >=20 > # clang --print-file-name=3DcrtbeginS.o > /usr/lib/crtbeginS.o > # clang -m32 --print-file-name=3DcrtbeginS.o > /usr/lib32/crtbeginS.o >=20 > # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3Dcrti.o > /usr/lib/crti.o > # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3Dcrti.o > /usr/lib/../lib32/crti.o >=20 > # powerpc64-unknown-freebsd12.0-gcc --print-file-name=3DcrtbeginS.o > /usr/lib/crtbeginS.o > # powerpc64-unknown-freebsd12.0-gcc -m32 --print-file-name=3DcrtbeginS.o= > /usr/lib/../lib32/crtbeginS.o >=20 >=20 > (Path prefixes present above. Using system ones would > not be likely to match using /usr/local/lib/. . . ones > from a cross build environment. But to have builds > from both hosts be equivalent would require the hosts > to use the same files [by content].) >=20 > # gcc7 --print-file-name=3Dcrti.o > /usr/lib/crti.o > # gcc7 -m32 --print-file-name=3Dcrti.o > /usr/lib/../lib32/crti.o >=20 > # gcc7 --print-file-name=3DcrtbeginS.o > = /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/crtbeginS.o > # gcc7 -m32 --print-file-name=3DcrtbeginS.o > = /usr/local/lib/gcc7/gcc/powerpc64-portbld-freebsd12.0/7.2.0/32/crtbeginS.o= >=20 >=20 > (Again the odd(?) system vs. gcc mix for gcc7. > But the -m32 path is distinct in this context.) >=20 > Does devel/powerpc64-gcc for cross builds require > taking control of the crti.o and crtbeginS.o (and > . . .) generation to force a match to what > self-hosted would have on the target architecture? > (nothing found.) >=20 >=20 >=20 > Note that /usr/local/. . . does not even have > the likes of crti.o or crtbeginS.o (or so on) > for devel/powerpc64-gcc to use in cross builds: >=20 > # find /usr/local/ -name "crtbeginS.o" -print | more = = =20 > /usr/local/lib/gcc7/gcc/x86_64-portbld-freebsd12.0/7.2.0/crtbeginS.o >=20 > (This also confirms that lack of a . . ./32/crtbeginS.o > for the amd64 native gcc7 compiler.) >=20 > It appears that devel/powerpc64-gcc used for cross > builds is generating what would otherwise be > crti.o and crtbeginS.o content on the fly as needed > during its compiles: there are none around to > use the contents of. FYI: despite the lack of a path prefix from --print-file-name . . . It appears to me that what appears in the lib32 .so.* files for .init is from: = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crt*.o content. Apparently without the path prefix it is looking based on other path specifications to find something. It just can not report later what it actually found and used for the file requested. So, not as bad as I was thinking earlier. But these files show the r30 problem and the inlining. You may want to skip the following detail. # find /usr/src/* /usr/obj/powerpc64vtsc_xtoolchain-gcc/ -name = "*crt[in]*.*" -print | more . . . /usr/src/lib/csu/powerpc64/crti.S /usr/src/lib/csu/powerpc64/crtn.S . . . = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po= werpc64/crtn.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po= werpc64/crtn.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po= werpc64/crti.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib/csu/po= werpc64/crti.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/lib/csu/powerpc/crtn.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/lib/csu/powerpc/crtn.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/lib/csu/powerpc/crti.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/lib/csu/powerpc/crti.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li= b/crti.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li= b/crtn.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/= lib32/crti.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/= lib32/crtn.o # find /usr/src/* /usr/obj/powerpc64vtsc_xtoolchain-gcc/ -name = "*crt[be]*S.*" -print | more = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs= u/crtbeginS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs= u/crtendS.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs= u/crtendS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/gnu/lib/cs= u/crtbeginS.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crtbeginS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crtendS.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crtbeginS.o.meta = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/world32/us= r/src/gnu/lib/csu/crtendS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li= b/crtbeginS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/tmp/usr/li= b/crtendS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/= lib32/crtendS.o = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/lib32/usr/= lib32/crtbeginS.o Showing -m32 examples: -DCOMPAT_32BIT -mcpu=3Dpowerpc -m32 -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3D3 -g0 -DCRT_BEGIN -DCRTSTUFFS_O -DSHARED -fpic -c -o crtbeginS.o /usr/src/contrib/gcc/crtstuff.c -DCOMPAT_32BIT -mcpu=3Dpowerpc -m32 -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -DDT_CONFIG -D__GLIBC__=3D3 -g0 -DCRT_END -DCRTSTUFFS_O -DSHARED -fpic -o crtendS.o /usr/src/contrib/gcc/crtstuff.c =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Fri Nov 3 13:21:30 2017 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 6C5DCE5235D for ; Fri, 3 Nov 2017 13:21:30 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.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 F17E3644CB for ; Fri, 3 Nov 2017 13:21:29 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.com) X-MSFBL: 6ZrrICsrnrPOha6qNMDDCeEUfBl/PiNQJJs35UjLxu8=|eyJiIjoiU25zdGVsZWN vbV9kZWRpY2F0ZWRfcG9vbF83NF85MV84NV8yMzgiLCJyIjoiZnJlZWJzZC1wcGN AZnJlZWJzZC5vcmciLCJnIjoiU25zdGVsZWNvbV9kZWRpY2F0ZWRfcG9vbCJ9 Received: from [10.137.129.34] ([10.137.129.34:29258] helo=mtl-mtsp-c02-2.int.smtp) by mtl-mtsp-mta05-out1.smtp.com (envelope-from ) (ecelerity 4.2.1.55028 r(Core:4.2.1.12)) with ESMTP id 1D/15-26324-0A86CF95; Fri, 03 Nov 2017 13:01:20 +0000 Received: from 10.137.11.86 by Caffeine (mtl-mtsp-c02-2) with SMTP id 0dc19e56-08ea-4247-b989-001c2d7ff5a4 for freebsd-ppc@freebsd.org; Fri, 03 Nov 2017 13:01:15 +0000 (UTC) Received: from [65.49.242.4] ([65.49.242.4:35680] helo=gull-dhcp-65-49-242-4.bloombb.net) by mtl-mtsp-mta03-in2 (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id 7F/A5-04934-A986CF95; Fri, 03 Nov 2017 13:01:15 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snsresearchreports.com To: freebsd-ppc@freebsd.org Subject: 5G for FWA (Fixed Wireless Access): 2017 - 2030 - Opportunities, Challenges, Strategies & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Fri, 3 Nov 2017 09:01:15 -0400 Message-ID: <408388312976781313570@Ankur> X-SMTPCOM-Tracking-Number: 0dc19e56-08ea-4247-b989-001c2d7ff5a4 X-SMTPCOM-Sender-ID: 6008902 Feedback-ID: 6008902:SMTPCOM DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=snsresearchreports.com; i=@snsresearchreports.com; q=dns/txt; s=snskey; t=1509714077; h=MIME-Version : From : Reply-To : To : Subject : Content-Type : Date : Message-ID : From : Subject : Date; bh=vEmZ6OabLNpMzOgf/h267q3ukV20nZOVs/q7yd3UhpU=; b=suWMUCb54L1KjrYxlPG2hMIyM7foH/rFgVRS5YbOmJtzyLwO1kaDga/owj/lHm9NOqtDJD YwW0ln2eXqVeCS3DXLuZshA09evcN3DxMjBxPxW+GeKepWP+IaH/YF1rkWD0sxTycN7f+wVa GOkAsVqCcWPvSLqvuA22BbSAyZ0BH29XqVCo9al1eiPF6FPuUbdNYUhx8F3Nmv8hUjW9nciz kdWWdkSa+YDutoaJ/8+c7hrGglZDcbxhxwmn+tx4SQrc0ccZ2rmUYd7gOQhxWj2jm1YQ1iCc XjBlbmt4i3gPiaso0Beustn14CwJ5Y4S+p6wq6G4hAav1IY1/M3ZuDqA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=smtpserver.email; i=@smtpserver.email; q=dns/txt; s=smtpcustomer; t=1509714077; h=MIME-Version : From : Reply-To : To : Subject : Content-Type : Date : Message-ID : From : Subject : Date; bh=vEmZ6OabLNpMzOgf/h267q3ukV20nZOVs/q7yd3UhpU=; b=BeZOVdascaS4qSdk8yMexo+DPOUPV7uD4wdUOcDeAZ1l5AbwH71ueuFbSu/7IOMwe98rN9 NPB23VJ9fQkK2MmPLkWY2CFuuFIAA26rtX8uOHlkZlJ6e5upHOsNPTvCufG8QCigaCkFmq5v MQj/c7qbfuiHyZTUgQ+IKis+z6dtqVWWbN9/StXpTKTr15FrKuF5LYLqQokYbcxnqVaF6Fkq UQvyQegBtyHQd9YrSjb3zh8XZgA+bbkOb/03Rmkk69+Ckyq7pvqMbXoDtu0KPxkZ4QkyWLGJ WshrjvkoIDmQaxcBilVpEBBSfKXpnxCBlb0Zh4IVNIyxjTjATbqMdIjQ== X-Report-Abuse: SMTP.com is an email service provider. Our abuse team cares about your feedback. Please contact abuse@smtp.com for further investigation. Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 13:21:30 -0000 5G for FWA (Fixed Wireless Access): 2017 =96 2030 =96 Opportunities, Challe= nges, Strategies & Forecasts (Report) Hello Let me offer you the latest SNS Research report to you and your team, "5G f= or FWA (Fixed Wireless Access): 2017 =96 2030 =96 Opportunities, Challenges= , Strategies & Forecasts" Below is the report highlight and if you like I c= an send you sample pages for your details inside.=20 Commonly referred to as FWA, Fixed Wireless Access has emerged as one of th= e most predominant use cases for early 5G network rollouts. Multiple mobile= operators and service providers are initially seeking to capitalize on 5G = as a fixed wireless alternative to deliver last-mile connectivity =96 at mu= lti-hundred Megabit and Gigabit speeds =96 in areas with insufficient fiber= holdings. The very first standardized deployments of 5G-based FWA are expected to be = commercialized as early as 2019. Largely driven by early commercial rollout= s by Verizon Communications and AT&T in the United States, 5G-based FWA sub= scriptions are expected to account for $1 Billion in service revenue by the= end of 2019 alone. The market is further expected to grow at a CAGR of app= roximately 84% between 2019 and 2025, eventually accounting for more than $= 40 Billion. Report Information: Release date: August 2017 Number of Pages: 213 Number of Tables and Figures: 83 Key Questions Answered: How big is the opportunity for 5G-based FWA=3F What trends, challenges and barriers will influence the development and ado= ption of 5G-based FWA=3F How have advanced antenna and chip technologies made it possible to utilize= millimeter wave spectrum for 5G-based FWA=3F What are the key application scenarios for 5G-based FWA=3F Can 5G-based FWA enable mobile operators to tap into the pay TV market=3F How can mobile operators leverage early deployments of 5G-based FWA to bett= er prepare their networks for planned 5G mobile service rollouts=3F What will be the number of 5G-based FWA subscriptions in 2019 and at what r= ate will it grow=3F Which regions and countries will be the first to adopt 5G-based FWA=3F Which frequency bands are most likely to be utilized by 5G-based FWA deploy= ments=3F What is the cost saving potential of 5G-based FWA for last-mile connectivit= y=3F Who are the key market players and what are their strategies=3F What strategies should 5G-based FWA vendors and service providers adopt to = remain competitive=3F Key Findings: The report has the following key findings: 5G-based FWA subscriptions are expected to account for $1 Billion in servic= e revenue by the end of 2019 alone. The market is further expected to grow = at a CAGR of approximately 84% between 2019 and 2025, eventually accounting= for more than $40 Billion. SNS Research estimates that 5G-based FWA can reduce the initial cost of est= ablishing last-mile connectivity by as much as 40% =96 in comparison to FTT= P (Fiber-to-the-Premises). In addition, 5G can significantly accelerate rol= lout times by eliminating the need to lay cables as required for FTTP rollo= uts. The 28 GHz frequency band is widely preferred for early 5G-based FWA deploy= ments, as many vendors have already developed 28 GHz-capable equipment =96 = driven by demands for early field trials in multiple markets including the = United States and South Korea. Millimeter wave wireless connectivity specialists are well-positioned to ca= pitalize on the growing demand for 5G-based FWA. However, in order to compe= te effectively against existing mobile infrastructure giants, they will nee= d to closely align their multi-gigabit capacity FWA solutions with 3GPP spe= cifications. While many industry analysts believe that 5G-based FWA is only suitable for= densely populated urban areas, a number of rural carriers =96 including C= Spire and U.S. Cellular =96 are beginning to view 5G as a means to deliver= last-mile broadband connectivity to underserved rural communities. The report covers the following topics: 5G architecture, requirements and applications Market drivers and barriers to the adoption of 5G Key enabling technologies and complementary concepts Business case and application scenarios for 5G-based FWA Analysis of spectrum availability and allocation for 5G-based FWA Case studies of 13 FWA deployments based on 5G and other wireless technolog= ies Company profiles and strategies of 80 FWA vendors Strategic recommendations for vendors and service providers Market analysis and forecasts till 2030 Forecast Segmentation: =20 5G Infrastructure Investments 5G NR (New Radio) Infrastructure NextGen (Next Generation) Core Network Fronthaul & Backhaul Networking 5G-Based FWA User Equipment Investments Unit Shipments Unit Shipment Revenue 5G-Based FWA Operator Services Subscriptions Service Revenue Application Scenario Segmentation Broadband Internet Pay TV IoT & Other Applications User Base Segmentation Residential Business Regional Segmentation Asia Pacific Eastern Europe Latin & Central America Middle East & Africa North America Western Europe =20 Report Pricing: =20 Single User License: USD 2,500 Company Wide License: USD 3,500 =20 Ordering Process: =20 Please provide the following information: Report Title - Report License - (Single User/Company Wide) Name - Email - Job Title - Company - 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 in report are given below for= more inside. I look forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom andy.silva@snsresearchreports.com _________________________________________________________________________ Table of Contents: =20 1 Chapter 1: Introduction 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 2 Chapter 2: An Overview of 5G 2.1 What is 5G=3F 2.2 High-Level Architecture of 5G Networks 2.2.1 5G NR (New Radio) Access Network 2.2.2 NextGen (Next Generation) Core Network 2.3 5G Performance Requirements 2.3.1 Data Volume 2.3.2 Data Rate 2.3.3 Bandwidth 2.3.4 Spectral Efficiency 2.3.5 Response Time & Latency 2.3.6 Connection Density 2.3.7 Reliability 2.3.8 Mobility 2.3.9 Availability & Coverage 2.3.10 Energy Efficiency 2.4 Target Application Areas 2.4.1 eMBB (Enhanced Mobile Broadband) 2.4.2 URLCC (Ultra-Reliable and Low Latency Communications) 2.4.3 mMTC (Massive Machine-Type Communications) 2.5 Key Enabling Technologies 2.5.1 Air Interface Design Enhancements 2.5.2 Centimeter & Millimeter Wave Radio Access 2.5.3 Advanced Antenna Technologies 2.5.4 D2D (Device-to-Device) Connectivity & Communication 2.5.5 Self-Backhauling & Mesh Networking 2.5.6 Spectrum Sharing & Aggregation 2.5.7 Multi-Site & Multi-RAN Connectivity 2.5.8 Control and User Plane Separation 2.5.9 Network Slicing 2.5.10 Service Based Architecture 2.5.11 Other Complementary Technologies & Concepts 2.6 Market Drivers 2.6.1 Why the Need for a 5G Standard=3F 2.6.2 Improving Spectrum Utilization 2.6.3 Advances in Key Enabling Technologies 2.6.4 Gigabit Wireless Connectivity: Supporting Future Services 2.6.5 Extreme Device Densities with the IoT (Internet of Things) 2.6.6 Moving Towards a Flatter Network Architecture 2.6.7 Role of Vertical Sectors & the 4th Industrial Revolution 2.7 Challenges & Inhibitors 2.7.1 Standardization Challenges: Too Many Stakeholders 2.7.2 Spectrum Regulation & Complexities 2.7.3 Massive MIMO, Beamforming & Antenna Technology Issues 2.7.4 Higher Frequencies Mean New Infrastructure 2.7.5 Complex Performance Requirements 2.7.6 Energy Efficiency & Technology Scaling =20 3 Chapter 3: Business Case, Applications & Spectrum for 5G-Based FWA 3.1 Overview & Revenue Potential 3.2 Segment-Specific Market Growth Drivers 3.3 Segment-Specific Market Barriers 3.4 Key Application Scenarios 3.4.1 Broadband Internet 3.4.2 Pay TV 3.4.3 IoT & Other Applications 3.5 Spectrum for 5G-Based FWA =20 4 Chapter 4: Case Studies of FWA Deployments 4.1 5G-Based FWA Networks 4.1.1 Arqiva 4.1.2 AT&T 4.1.3 C Spire 4.1.4 Hammer Fiber 4.1.5 Now Corporation 4.1.6 U.S. Cellular 4.1.7 Verizon Communications 4.2 FWA Networks Based on Other Technologies 4.2.1 Facebook 4.2.2 Google 4.2.3 NBN Co 4.2.4 Prairie Hills Wireless 4.2.5 Redzone Wireless 4.2.6 Starry =20 5 Chapter 5: Market Analysis & Forecasts 5.1 Pre-Standards 5G Network Investments 5.1.1 Segmentation by Submarket 5.1.2 Base Stations 5.1.3 User Equipment 5.1.4 Transport Networking & Other Investments 5.2 Global Outlook for Standardized 5G Infrastructure 5.2.1 Segmentation by Submarket 5.2.2 5G NR 5.2.2.1 Macrocell Base Stations 5.2.2.2 Small Cells 5.2.2.3 RRHs (Remote Radio Heads) 5.2.2.4 C-RAN BBUs (Baseband Units) 5.2.3 NextGen Core Network 5.2.4 Fronthaul & Backhaul Networking 5.2.5 Segmentation by Region 5.3 Global Outlook for Standardized 5G-Based FWA User Equipment 5.3.1 5G-Based FWA CPEs 5.3.2 Segmentation by Region 5.4 Global Outlook for 5G-Based FWA Operator Services 5.4.1 5G-Based FWA Subscriptions 5.4.2 5G-Based FWA Service Revenue 5.4.3 Application Scenario Segmentation 5.4.3.1 Broadband Internet 5.4.3.2 Pay TV 5.4.3.3 IoT & Other Applications 5.4.4 User Base Segmentation 5.4.4.1 Residential 5.4.4.2 Business 5.4.5 Regional Segmentation 5.5 Asia Pacific 5.5.1 5G Infrastructure 5.5.2 5G-Based FWA User Equipment 5.5.3 5G-Based FWA Subscriptions 5.5.4 5G-Based FWA Service Revenue 5.6 Eastern Europe 5.6.1 5G Infrastructure 5.6.2 5G-Based FWA User Equipment 5.6.3 5G-Based FWA Subscriptions 5.6.4 5G-Based FWA Service Revenue 5.7 Latin & Central America 5.7.1 5G Infrastructure 5.7.2 5G-Based FWA User Equipment 5.7.3 5G-Based FWA Subscriptions 5.7.4 5G-Based FWA Service Revenue 5.8 Middle East & Africa 5.8.1 5G Infrastructure 5.8.2 5G-Based FWA User Equipment 5.8.3 5G-Based FWA Subscriptions 5.8.4 5G-Based FWA Service Revenue 5.9 North America 5.9.1 5G Infrastructure 5.9.2 5G-Based FWA User Equipment 5.9.3 5G-Based FWA Subscriptions 5.9.4 5G-Based FWA Service Revenue 5.10 Western Europe 5.10.1 5G Infrastructure 5.10.2 5G-Based FWA User Equipment 5.10.3 5G-Based FWA Subscriptions 5.10.4 5G-Based FWA Service Revenue =20 6 Chapter 6: Vendor Profiles 6.1 3Roam 6.2 4RF 6.3 Advantech Wireless 6.4 Airspan Networks 6.5 ALCOMA 6.6 Aviat Networks 6.7 Blu Wireless Technology 6.8 BluWan 6.9 BridgeWave Communications 6.10 CableFree (Wireless Excellence) 6.11 Cambium Networks 6.12 Carlson Wireless Technologies 6.13 CBNL (Cambridge Broadband Networks Ltd.) 6.14 CCI (Communication Components, Inc.) 6.15 CCS (Cambridge Communication Systems) 6.16 Ceragon Networks 6.17 Cielo Networks 6.18 Cohere Technologies 6.19 Collinear Networks 6.20 DragonWave 6.21 E-Band Communications 6.22 EBlink 6.23 ELVA-1 6.24 Ericsson 6.25 Exalt Wireless 6.26 FastBack Networks 6.27 Filtronic 6.28 Fujitsu 6.29 GlobalFoundries 6.30 Huawei 6.31 HXI 6.32 IBM Corporation 6.33 IDT (Integrated Device Technology) 6.34 Imec International 6.35 InfiNet Wireless 6.36 Intel Corporation 6.37 InterDigital 6.38 Intracom Telecom 6.39 JRC (Japan Radio Company) 6.40 KMW 6.41 Lattice Semiconductor 6.42 LightPointe Communications 6.43 LigoWave 6.44 Loea Corporation 6.45 Maja Systems 6.46 MAX4G 6.47 MaxLinear 6.48 Microwave Networks 6.49 Mimosa Networks 6.50 MIMOtech 6.51 MTI (Microelectronics Technology, Inc.) 6.52 NEC Corporation 6.53 NexxCom Wireless 6.54 Nokia 6.55 PHAZR 6.56 Polewall 6.57 Proxim Wireless Corporation 6.58 Qualcomm 6.59 RACOM 6.60 Radio Gigabit 6.61 RADWIN 6.62 Redline Communications 6.63 REMEC Broadband Wireless Networks 6.64 SAF Tehnika 6.65 Samsung Electronics 6.66 SIAE Microelectronica 6.67 Siklu Communication 6.68 Sivers IMA 6.69 SkyFiber 6.70 Solectek Corporation 6.71 Spectronite 6.72 Star Microwave 6.73 Tarana Wireless 6.74 Trango Systems 6.75 Vubiq Networks 6.76 Wave1 6.77 Wavesight 6.78 Wytec International 6.79 Xilinx 6.80 ZTE =20 7 Chapter 7: Conclusion & Strategic Recommendations 7.1 Why is the Market Poised to Grow=3F 7.2 Review of Ongoing 5G-Based FWA Deployments 7.3 Prospects for Millimeter Wave Wireless Connectivity Specialists 7.4 28 GHz Spectrum to Lead Early Deployments 7.5 Preparing Networks for 5G Mobile Services 7.6 What is the Cost Saving Potential of 5G-Based FWA for Last Mile-Connect= ivity=3F 7.7 Strategic Recommendations 7.7.1 Vendors 7.7.2 Service Providers =20 List of Figures: =20 Figure 1: 5G Network Architecture & Interaction with Other Networks Figure 2: 5G Performance Requirements Figure 3: Conceptual Architecture for End-to-End Network Slicing in Mobile = Networks Figure 4: Service Based Architecture for 5G Figure 5: Leading 5G Use Cases Figure 6: Distribution of 5G-Based FWA Service Revenue, by Application Scen= ario: 2019 (%) Figure 7: 5G-Based FWA Application Scenarios Figure 8: Convergence of 5G with Wireline Networks Figure 9: LTE-Based FWA TV Service Architecture Figure 10: Key Characteristics of Verizon's 5G Specifications Figure 11: Facebook's Terragraph Network Figure 12: NBN's FWA Equipment Setup Figure 13: Global Pre-Standards 5G Network Investments: 2016 - 2018 ($ Mill= ion) Figure 14: Global Pre-Standards 5G Network Investments by Submarket: 2016 -= 2018 ($ Million) Figure 15: Global Pre-Standards 5G Base Station Shipments: 2016 - 2018 (Uni= ts) Figure 16: Global Pre-Standards 5G Base Station Shipment Revenue: 2016 - 20= 18 ($ Million) Figure 17: Global Pre-Standards 5G User Equipment Shipments: 2016 - 2018 (U= nits) Figure 18: Global Pre-Standards 5G User Equipment Shipment Revenue: 2016 - = 2018 ($ Million) Figure 19: Global Transport Networking & Other Investments for Pre-Standard= s 5G Networks: 2016 - 2018 ($ Million) Figure 20: Global 5G Infrastructure Investments: 2019 - 2030 ($ Million) Figure 21: Global 5G Infrastructure Investments by Submarket: 2019 - 2030 (= $ Million) Figure 22: Global 5G NR Investments: 2019 - 2030 ($ Million) Figure 23: Global 5G NR Investments by Submarket: 2019 - 2030 ($ Million) Figure 24: Global 5G Macrocell Base Station Shipments: 2019 - 2030 (Thousan= ds of Units) Figure 25: Global 5G Macrocell Base Station Shipment Revenue: 2019 - 2030 (= $ Million) Figure 26: Global 5G Small Cell Shipments: 2019 - 2030 (Thousands of Units) Figure 27: Global 5G Small Cell Shipment Revenue: 2019 - 2030 ($ Million) Figure 28: Global 5G RRH Shipments: 2019 - 2030 (Thousands of Units) Figure 29: Global 5G RRH Shipment Revenue: 2019 - 2030 ($ Million) Figure 30: Global 5G C-RAN BBU Shipments: 2019 - 2030 (Thousands of Units) Figure 31: Global 5G C-RAN BBU Shipment Revenue: 2019 - 2030 ($ Million) Figure 32: Global NextGen Core Network Investments: 2019 - 2030 ($ Million) Figure 33: Global 5G Fronthaul & Backhaul Investments: 2019 - 2030 ($ Milli= on) Figure 34: 5G Infrastructure Investments by Region: 2019 - 2030 ($ Million) Figure 35: Global 5G-Based FWA CPE Unit Shipments: 2019 - 2030 (Millions of= Units) Figure 36: Global 5G-Based CPE Unit Shipment Revenue: 2019 - 2030 ($ Billio= n) Figure 37: 5G-Based FWA CPE Unit Shipments by Region: 2019 - 2030 (Millions= of Units) Figure 38: 5G-Based FWA CPE Unit Shipment Revenue by Region: 2019 - 2030 ($= Billion) Figure 39: Global 5G-Based FWA Subscriptions: 2019 - 2030 (Millions) Figure 40: Global 5G-Based FWA Service Revenue: 2019 - 2030 ($ Billion) Figure 41: 5G-Based FWA Service Revenue by Application Scenario: 2019 - 203= 0 ($ Billion) Figure 42: 5G-Based FWA Service Revenue for Broadband Internet: 2019 - 2030= ($ Billion) Figure 43: 5G-Based FWA Service Revenue for Pay TV: 2019 - 2030 ($ Billion) Figure 44: 5G-Based FWA Service Revenue for IoT & Other Applications: 2019 = - 2030 ($ Billion) Figure 45: 5G-Based FWA Subscriptions by User Base: 2019 - 2030 (Millions) Figure 46: 5G-Based FWA Service Revenue by User Base: 2019 - 2030 ($ Billio= n) Figure 47: 5G-Based FWA Subscriptions for Residential Users: 2019 - 2030 (M= illions) Figure 48: 5G-Based FWA Service Revenue for Residential Users: 2019 - 2030 = ($ Billion) Figure 49: 5G-Based FWA Subscriptions for Business Users: 2019 - 2030 (Mill= ions) Figure 50: 5G-Based FWA Service Revenue for Business Users: 2019 - 2030 ($ = Billion) Figure 51: 5G-Based FWA Subscriptions by Region: 2019 - 2030 (Millions) Figure 52: 5G-Based FWA Service Revenue by Region: 2019 - 2030 ($ Billion) Figure 53: Asia Pacific 5G Infrastructure Investments: 2019 - 2030 ($ Milli= on) Figure 54: Asia Pacific 5G-Based FWA CPE Unit Shipments: 2019 - 2030 (Milli= ons of Units) Figure 55: Asia Pacific 5G-Based FWA CPE Unit Shipment Revenue: 2019 - 2030= ($ Billion) Figure 56: Asia Pacific 5G-Based FWA Subscriptions: 2019 - 2030 (Millions) Figure 57: Asia Pacific 5G-Based FWA Service Revenue: 2019 - 2030 ($ Billio= n) Figure 58: Eastern Europe 5G Infrastructure Investments: 2019 - 2030 ($ Mil= lion) Figure 59: Eastern Europe 5G-Based FWA CPE Unit Shipments: 2019 - 2030 (Mil= lions of Units) Figure 60: Eastern Europe 5G-Based FWA CPE Unit Shipment Revenue: 2019 - 20= 30 ($ Billion) Figure 61: Eastern Europe 5G-Based FWA Subscriptions: 2019 - 2030 (Millions) Figure 62: Eastern Europe 5G-Based FWA Service Revenue: 2019 - 2030 ($ Bill= ion) Figure 63: Latin & Central America 5G Infrastructure Investments: 2019 - 20= 30 ($ Million) Figure 64: Latin & Central America 5G-Based FWA CPE Unit Shipments: 2019 - = 2030 (Millions of Units) Figure 65: Latin & Central America 5G-Based FWA CPE Unit Shipment Revenue: = 2019 - 2030 ($ Billion) Figure 66: Latin & Central America 5G-Based FWA Subscriptions: 2019 - 2030 = (Millions) Figure 67: Latin & Central America 5G-Based FWA Service Revenue: 2019 - 203= 0 ($ Billion) Figure 68: Middle East & Africa 5G Infrastructure Investments: 2019 - 2030 = ($ Million) Figure 69: Middle East & Africa 5G-Based FWA CPE Unit Shipments: 2019 - 203= 0 (Millions of Units) Figure 70: Middle East & Africa 5G-Based FWA CPE Unit Shipment Revenue: 201= 9 - 2030 ($ Billion) Figure 71: Middle East & Africa 5G-Based FWA Subscriptions: 2019 - 2030 (Mi= llions) Figure 72: Middle East & Africa 5G-Based FWA Service Revenue: 2019 - 2030 (= $ Billion) Figure 73: North America 5G Infrastructure Investments: 2019 - 2030 ($ Mill= ion) Figure 74: North America 5G-Based FWA CPE Unit Shipments: 2019 - 2030 (Mill= ions of Units) Figure 75: North America 5G-Based FWA CPE Unit Shipment Revenue: 2019 - 203= 0 ($ Billion) Figure 76: North America 5G-Based FWA Subscriptions: 2019 - 2030 (Millions) Figure 77: North America 5G-Based FWA Service Revenue: 2019 - 2030 ($ Billi= on) Figure 78: Western Europe 5G Infrastructure Investments: 2019 - 2030 ($ Mil= lion) Figure 79: Western Europe 5G-Based FWA CPE Unit Shipments: 2019 - 2030 (Mil= lions of Units) Figure 80: Western Europe 5G-Based FWA CPE Unit Shipment Revenue: 2019 - 20= 30 ($ Billion) Figure 81: Western Europe 5G-Based FWA Subscriptions: 2019 - 2030 (Millions) Figure 82: Western Europe 5G-Based FWA Service Revenue: 2019 - 2030 ($ Bill= ion) Figure 83: Cost Comparison Between 5G-Based FWA and FTTP for Last-Mile Conn= ectivity Establishment ($ per Premises) =20 Thank you once again and looking forward to hearing from you. =20 Kind Regards =20 Andy Silva Marketing Executive Signals and Systems Telecom =20 To unsubscribe send an email with unsubscribe in the subject line to: remov= e@snsreports.com =20