From owner-freebsd-ppc@freebsd.org Sun Jan 15 21:24:25 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 86E0FCB1E1A for ; Sun, 15 Jan 2017 21:24:25 +0000 (UTC) (envelope-from tgl@sss.pgh.pa.us) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) (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 5229F1C44; Sun, 15 Jan 2017 21:24:25 +0000 (UTC) (envelope-from tgl@sss.pgh.pa.us) Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id v0FLGPum021670; Sun, 15 Jan 2017 16:16:25 -0500 From: Tom Lane To: Justin Hibbits cc: Tamiji Homma , freebsd-ppc@freebsd.org Subject: Re: FreeBSD 11 on PowerBook G4 In-reply-to: <20161108205349.1b5b26a6@zhabar.knownspace> References: <9421DD34-95A4-4435-84CB-D9C3A1D52DC5@me.com> <20161108205349.1b5b26a6@zhabar.knownspace> Comments: In-reply-to Justin Hibbits message dated "Tue, 08 Nov 2016 20:53:49 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-ID: <21668.1484514985.1@sss.pgh.pa.us> Content-Transfer-Encoding: 8bit Date: Sun, 15 Jan 2017 16:16:25 -0500 Message-ID: <21669.1484514985@sss.pgh.pa.us> 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, 15 Jan 2017 21:24:25 -0000 Justin Hibbits writes: > Tamiji Homma wrote: >> Since it reboots spontaneously, I couldn’t write it down. I >> video-captured screen and took a snapshot. >> Here is screenshot fatal kernel trap. >> http://www.pbase.com/tammyhomma/image/164488840/original >> >> Anyone seen this? > Unfortunately, you're in good company with that panic. I've seen that > since at least February on my PowerBook, but haven't made the time to > track it down (11-CURRENT from mid-October 2015 worked fine). On the > bright side, though, 12-CURRENT as of October 31 works fine on my > PowerBook. I still don't have the time to bisect and track down the > cause of the problem or the fix, but if you feel like bisecting and > trying to find the snapshot that fixes the problem, that could help > narrow down where it got fixed, and a fix could be backported to > 11-STABLE. I took up the challenge of bisecting this, and it appears to be a two-year-old fault in the ofwfb screen driver. It is *NOT* fixed in CURRENT, at least not as of yesterday. Details at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216123 regards, tom lane From owner-freebsd-ppc@freebsd.org Mon Jan 16 08:08:05 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 B13BECB2DA1 for ; Mon, 16 Jan 2017 08:08:05 +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 63DA917AE for ; Mon, 16 Jan 2017 08:08:05 +0000 (UTC) (envelope-from andy.silva@snsresearchreports.com) X-MSFBL: ZuBM1Iqt3HEQiOeE3wSOusAIjBRcfH73ePoVs5+c96E=|eyJiIjoiNzRfOTFfODV fMjM4IiwiciI6ImZyZWVic2QtcHBjQGZyZWVic2Qub3JnIiwiZyI6IlNuc3RlbGV jb21fZGVkaWNhdGVkX3Bvb2wifQ== Received: from [192.168.80.12] ([192.168.80.12:54632] helo=rs-ord-mta01-in2.smtp.com) by rs-ord-mta03-4.smtp.com (envelope-from ) (ecelerity 4.2.1.55028 r(Core:4.2.1.12)) with ESMTP id BC/CB-01129-1AA7C785; Mon, 16 Jan 2017 07:47:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; d=smtp.com; s=smtpcomcustomers; c=relaxed/simple; q=dns/txt; i=@smtp.com; t=1484552865; h=From:Subject:To:Date:MIME-Version:Content-Type; bh=/i8wAfmzVvxhTnB/r1vYxizLLftfhDYe1sx6BfIbq9s=; b=b1OTwQoyrtuao5ANXoFUNymA9uqmCVEApUxa5sXcBxOO6tziSY3X26rYz37BnqOf lV7DXTluwYQ8PX3tYE5qmyOCvOr+rdYBnEit/tH1GhrDUUcCd95vdqLHETN/BXdT 9ouF8ZeL/Tfi+1FC15HnBHoPW4E7xRiDM7R8PURkgFM=; Received: from [70.79.69.78] ([70.79.69.78:35008] helo=S01061c1b689e28c7.vc.shawcable.net) by rs-ord-mta01-in2.smtp.com (envelope-from ) (ecelerity 4.1.0.46749 r(Core:4.1.0.4)) with ESMTPA id 7E/3E-19046-0AA7C785; Mon, 16 Jan 2017 07:47:45 +0000 MIME-Version: 1.0 From: "Andy Silva" Reply-To: andy.silva@snsresearchreports.com To: freebsd-ppc@freebsd.org Subject: The vRAN (Virtualized Radio Access Network) Ecosystem: 2017 - 2030 - Opportunities, Challenges, Strategies & Forecasts (Report) X-Mailer: Smart_Send_2_0_138 Date: Sun, 15 Jan 2017 23:47:31 -0800 Message-ID: <6483994748002496425158@Ankur> 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. X-SMTPCOM-Tracking-Number: ea95d9a0-295c-4438-8648-e81f24566e82 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.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: Mon, 16 Jan 2017 08:08:05 -0000 The vRAN (Virtualized Radio Access Network) Ecosystem: 2017 =96 2030 =96 Op= portunities, Challenges, Strategies & Forecasts (Report) Hello Let me offer you the latest SNS Research report to you and your team, "The = vRAN (Virtualized Radio Access Network) Ecosystem: 2017 =96 2030 =96 Opport= unities, Challenges, Strategies & Forecasts" Below is the report highlight = and if you like I can send you sample pages for more inside details. The re= port comes with an associated Excel datasheet suite covering quantitative d= ata from all numeric forecasts presented in the report. vRAN (Virtualized Radio Access Network) refers to a RAN (Radio Access Netwo= rk) implementation where some or all baseband functions are separated from = the remote radio unit and run as VNFs (Virtualized Network Functions) on co= mmodity hardware. This approach results in multiple operational benefits in= cluding but not limited to TCO (Total Cost of Ownership) reduction, perform= ance gains and scalability. In addition, vRAN enables mobile operators to f= uture-proof their networks for 5G upgrades. The vRAN market is presently at a nascent stage with most investments focus= ed on virtualized small cells for targeted greenfield deployments and pilot= engagements for macrocell coverage. However, as mobile operators realize t= he benefits of RAN virtualization, the market is expected to grow at a CAGR= of approximately 125% over the next three year period. By the end of 2020,= SNS Research estimates that vRAN deployments will account for a market wor= th $2.6 Billion. The report also presents forecasts for vRAN investments fr= om 2017 till 2030. The forecasts cover multiple submarkets and 6 regions. Report Information: Release Date: Jan 2017 Number of Pages: 220 Number of Tables and Figures: 86 Key Questions Answered: How big is the vRAN opportunity=3F What trends, challenges and barriers are influencing its growth=3F How is the ecosystem evolving by segment and region=3F What will the market size be in 2020 and at what rate will it grow=3F Which submarkets will see the highest percentage of growth=3F Is centralization a pre-requisite for vRAN implementation=3F What are the benefits and drawbacks of each baseband functional split optio= n=3F How can vRAN reduce the TCO of RAN deployments=3F How can mobile operators future-proof their RAN investments for 5G upgrades=3F Who are the key market players and what are their strategies=3F What strategies should vRAN solution providers and mobile operators adopt t= o remain competitive=3F Key Findings: The report has the following key findings: vRAN investments are expected to grow at a CAGR of approximately 125% over = the next three year period. By the end of 2020, SNS Research estimates that= vRAN deployments will account for a market worth $2.6 Billion. At present, most vRAN investments are focused on virtualized small cells fo= r targeted greenfield deployments and pilot engagements for macrocell cover= age. Mobile operators are exploring multiple baseband functional split options f= or vRAN implementation, as they seek to ease the transition to 5G networks = while reducing fronthaul costs. The ongoing 5G race is expected to significantly boost vRAN investments ove= r the coming years. SNS Research estimates that approximately $900 Million = of all vRAN investments will be directed towards 5G networks by the end of = 2020. The report covers the following topics: vRAN ecosystem Market drivers and barriers vRAN architecture and key functional elements Baseband functional splitting for vRAN implementation Fronthaul networking technologies and interface options Key trends including RAN slicing, RANaaS (RAN as a Service), neutral hostin= g and MEC (Mobile Edge Computing) TCO comparison between vRAN and conventional RAN architectures vRAN deployment models including Cloud RAN and virtualized small cells Mobile operator case studies Regulatory landscape, collaborative initiatives and standardization Industry roadmap and value chain Profiles and strategies of over 60 leading ecosystem players including vRAN= solution providers Strategic recommendations for ecosystem players including vRAN solution pro= viders and mobile operators Market analysis and forecasts from 2017 till 2030 Forecast Segmentation: =20 Market forecasts are provided for each of the following submarkets and thei= r subcategories: Submarkets vRAN Radio Units vBBUs (Virtualized Baseband Units) Air Interface Technology Segmentation LTE & 3G 5G NR (New Radio) Deployment Model Segmentation Virtualized Small Cells Virtualized Macrocells Regional Markets Asia Pacific Eastern Europe Middle East & Africa Latin & Central America 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 =20 _________________________________________________________________________ Table of Contents & page number =20 1 Chapter 1: Introduction 12 1.1 Executive Summary 12 1.2 Topics Covered 14 1.3 Forecast Segmentation 15 1.4 Key Questions Answered 16 1.5 Key Findings 17 1.6 Methodology 18 1.7 Target Audience 19 1.8 Companies & Organizations Mentioned 20 =20 2 Chapter 2: An Overview of vRAN 22 2.1 C-RAN (Centralized Radio Access Network): Opening the Door to RAN Virtu= alization 22 2.1.1 Decoupling the Base Station 22 2.1.2 Brief History 23 2.1.3 Outlook on Future Investments 23 2.2 What is vRAN=3F 24 2.2.1 Leveraging Commodity Technologies 25 2.2.2 Moving RAN to the Cloud 25 2.3 Key Functional Elements of vRAN 27 2.3.1 Remote Radio Unit 27 2.3.2 vBBU (Virtualized Baseband Unit) 27 2.3.2.1 Baseband VNFs (Virtualized Network Functions) 28 2.3.2.2 RTOS (Real-Time Operating System) & Virtualization Environment 29 2.3.2.3 GPP (General Purpose Processor) Platform 30 2.3.2.4 Dedicated Programmable Hardware 30 2.3.2.5 External Interactions 31 2.3.3 Fronthaul 32 2.3.3.1 Technologies 32 2.3.3.2 Interface Options 34 2.4 Baseband Functional Split Approaches 36 2.4.1 Fully Virtualized Baseband Processing: PHY-RF Split 37 2.4.2 Partially Virtualized Functional Splits 38 2.4.2.1 Intra-PHY Split 39 2.4.2.2 MAC-PHY Split 40 2.4.2.3 Intra-MAC Split 40 2.4.2.4 RLC-MAC Split 41 2.4.2.5 Intra-RLC Split 41 2.4.2.6 PDCP-RLC Split 41 2.4.2.7 RRC-PDCP Split 42 2.5 Market Growth Drivers 42 2.5.1 Capacity & Coverage Improvement: Addressing the Mobile Data Traffic T= sunami 42 2.5.2 Bringing Intelligence to the Edge: MEC (Mobile Edge Computing) 44 2.5.3 OpEx Reduction: Reducing Energy & Maintenance Costs 44 2.5.4 CapEx Reduction: BBU Resource Pooling & Commodity IT Hardware 45 2.5.5 Agile & Flexible Network Architecture 45 2.5.6 Enhanced Support for Advanced RAN Coordination Features 46 2.5.7 Multi-Tenancy & RAN Sharing 46 2.5.8 Enabling Painless Migration Towards Future RAN Technologies 47 2.5.9 Impact of 5G Rollouts 47 2.6 Market Barriers 47 2.6.1 Fronthaul Investments 48 2.6.2 Virtualization Challenges 48 2.6.3 Vendor Proprietary Functional Splits 48 2.6.4 Migration from Legacy Architectures 49 =20 3 Chapter 3: Standardization, Regulatory & Collaborative Initiatives 50 3.1 3GPP (3rd Generation Partnership Project) 50 3.1.1 Functional Splits for vRAN Implementation in 5G Networks 50 3.1.2 Management of Virtualized Mobile Networks 51 3.2 Broadband Forum 52 3.2.1 TR-069 for PNF Management 52 3.3 CPRI Initiative 53 3.3.1 eCPRI for 5G Fronthaul Networks 53 3.4 ETSI (European Telecommunications Standards Institute) 54 3.4.1 ORI for Fronthaul 54 3.4.2 NFV (Network Functions Virtualization) for vRAN 54 3.4.3 MEC (Mobile Edge Computing) 56 3.5 IEEE (Institute of Electrical and Electronics Engineers) 57 3.5.1 IEEE 802.1CM: TSN (Time-Sensitive Networking) for Fronthaul 57 3.5.2 IEEE P1904.3: Standard for RoE (Radio over Ethernet) Encapsulations a= nd Mappings 57 3.5.3 IEEE 1914: NGFI (Next Generation Fronthaul Interface) Working Group 58 3.5.4 Other Standards & Work Groups 59 3.6 ITU (International Telecommunications Union) 60 3.6.1 Focus Group on IMT-2020 60 3.7 MEF (Metro Ethernet Forum) 61 3.7.1 Ethernet Transport 61 3.8 NGMN (Next Generation Mobile Networks) Alliance 62 3.8.1 P-CRAN (Project Centralized RAN) 62 3.9 ONF (Open Networking Foundation) & ON.Lab (Open Networking Lab) 63 3.9.1 M-CORD (Mobile Central Office Re-architected as a Datacenter) 63 3.10 OSA (OpenAirInterface Software Alliance) 65 3.10.1 LTE vRAN Implementation 65 3.11 SCF (Small Cell Forum) 66 3.11.1 Release 8: Small Cell Virtualization with nFAPI 66 3.12 TIP (Telecom Infra Project) 68 3.12.1 OpenCellular Access Platform 68 3.13 xRAN Consortium 69 3.13.1 xRAN Architecture 69 =20 4 Chapter 4: vRAN Deployment Models & Case Studies 70 4.1 Deployment Models 70 4.1.1 Distributed vRAN 70 4.1.2 Centralized vRAN: Cloud RAN 71 4.1.3 Virtualized Small Cells 73 4.2 Mobile Operator Case Studies 74 4.2.1 BT Group 74 4.2.2 China Mobile 75 4.2.3 China Unicom 77 4.2.4 KT Corporation 78 4.2.5 NTT DoCoMo 79 4.2.6 Orange 81 4.2.7 SK Telecom 82 4.2.8 SoftBank Group 84 4.2.9 Telef=F3nica Group 86 4.2.10 TIM (Telecom Italia Mobile) 87 4.2.11 Vodafone Group 88 =20 5 Chapter 5: vRAN Industry Roadmap & Value Chain 90 5.1 Industry Roadmap 90 5.1.1 2017 =96 2020: Growing Adoption of Virtualized Small Cells 90 5.1.2 2020 =96 2025: The Cloud RAN Era - Moving vRAN to the Data Center 91 5.1.3 2025 =96 2030: Continued Investments with 5G Network Rollouts 91 5.2 Value Chain 92 5.2.1 Enabling Technology Providers 92 5.2.2 Radio Equipment Suppliers 93 5.2.3 vBBU Vendors 93 5.2.4 Fronthaul Networking Vendors 93 5.2.5 Mobile Operators 94 5.2.6 Test, Measurement & Performance Specialists 94 =20 6 Chapter 6: Key Market Players 95 6.1 6WIND 95 6.2 ADLINK Technology 96 6.3 Advantech 97 6.4 Airspan Networks 98 6.5 Altiostar Networks 99 6.6 Amarisoft 100 6.7 Argela 101 6.8 Aricent 102 6.9 ARM Holdings 103 6.10 Artemis Networks 104 6.11 Artesyn Embedded Technologies 105 6.12 ASOCS 106 6.13 ASTRI (Hong Kong Applied Science and Technology Research Institute) 107 6.14 Broadcom 108 6.15 Casa Systems 109 6.16 Cavium 110 6.17 Cisco Systems 112 6.18 Clavister 113 6.19 Cobham Wireless 114 6.20 Comcores 115 6.21 CommAgility 116 6.22 CommScope 117 6.23 Contela 118 6.24 Dali Wireless 119 6.25 Dell Technologies 120 6.26 eASIC Corporation 121 6.27 Ericsson 122 6.28 Facebook 123 6.29 Fujitsu 124 6.30 Hitachi 125 6.31 HPE (Hewlett Packard Enterprise) 126 6.32 Huawei 127 6.33 IBM Corporation 128 6.34 IDT (Integrated Device Technology) 129 6.35 Intel Corporation 130 6.36 ip.access 131 6.37 IS-Wireless 132 6.38 JMA Wireless 133 6.39 Kathrein-Werke KG 134 6.40 Mellanox Technologies 135 6.41 Microsemi Corporation 136 6.42 Mobiveil 137 6.43 MTI Mobile 138 6.44 NEC Corporation 139 6.45 Nokia 140 6.46 NXP Semiconductors 141 6.47 Octasic 142 6.48 Parallel Wireless 143 6.49 Phluido 144 6.50 Qualcomm 145 6.51 Quortus 146 6.52 Radisys Corporation 147 6.53 Red Hat 148 6.54 Samsung Electronics 149 6.55 SOLiD (SOLiD Technologies) 150 6.56 SpiderCloud Wireless 151 6.57 Sumitomo Electric Industries 152 6.58 Sunnada (Fujian Sunnada Communication Company) 153 6.59 Sunwave Communications 154 6.60 TI (Texas Instruments) 155 6.61 Xilinx 156 6.62 Xura 157 6.63 ZTE 158 =20 7 Chapter 7: Market Analysis & Forecasts 159 7.1 Global Outlook on vRAN Investments 159 7.2 Segmentation by Deployment Model 160 7.2.1 Virtualized Small Cells 160 7.2.2 Virtualized Macrocells 161 7.3 Segmentation by Air Interface Technology 161 7.3.1 LTE & 3G 162 7.3.2 5G NR (New Radio) 162 7.4 Segmentation by Submarket 163 7.4.1 vRAN Radio Units 163 7.4.1.1 Virtualized Small Cell Radio Units 165 7.4.1.2 Virtualized Macrocell Radio Units 166 7.4.2 vBBUs (Virtualized Baseband Units) 167 7.4.2.1 Virtualized Small Cell BBUs 169 7.4.2.2 Virtualized Macrocell BBUs 170 7.5 Segmentation by Region 172 7.5.1 vRAN Radio Units 172 7.5.2 vBBUs 173 7.6 Asia Pacific 175 7.6.1 vRAN Radio Units 175 7.6.2 vBBUs 176 7.7 Eastern Europe 178 7.7.1 vRAN Radio Units 178 7.7.2 vBBUs 179 7.8 Middle East & Africa 181 7.8.1 vRAN Radio Units 181 7.8.2 vBBUs 182 7.9 Latin & Central America 184 7.9.1 vRAN Radio Units 184 7.9.2 vBBUs 185 7.10 North America 187 7.10.1 vRAN Radio Units 187 7.10.2 vBBUs 188 7.11 Western Europe 190 7.11.1 vRAN Radio Units 190 7.11.2 vBBUs 191 =20 8 Chapter 8: Expert Opinion =96 Interview Transcripts 193 8.1 Ericsson 193 8.2 Nokia Networks 196 8.3 ASOCS 201 8.4 SpiderCloud Wireless 204 8.5 Parallel Wireless 206 =20 9 Chapter 9: Conclusion & Strategic Recommendations 210 9.1 Why is the Market Poised to Grow=3F 210 9.2 Competitive Industry Landscape: Acquisitions, Alliances & Consolidation= 210 9.3 Is Centralization a Pre-Requisite for vRAN Implementation=3F 211 9.4 Setting the Foundation for 5G NR (New Radio) Upgrades 211 9.5 What is the Cost Saving Potential of vRAN=3F 212 9.6 Integration with MEC (Mobile Edge Computing) 213 9.7 Moving Towards a Cloud Operating Model 213 9.8 Prospects of Neutral Hosting with vRAN 214 9.9 Enabling RAN Slicing 215 9.10 Unlicensed Spectrum: Impact on Virtualized Small Cell Design 217 9.11 Geographic Outlook: Which Countries Offer the Highest Growth Potential= =3F 218 9.12 Strategic Recommendations 219 9.12.1 vRAN Solution Providers 219 9.12.2 Mobile Operators 220 =20 List of Figures & Page number:s =20 Figure 1: C-RAN Architecture 23 Figure 2: vRAN Architecture 25 Figure 3: Key Remote Radio Unit & vBBU Functions 29 Figure 4: VM vs. Container Virtualization 31 Figure 5: CPRI Protocol Layers 34 Figure 6: Baseband Functional Split Options for vRAN 37 Figure 7: Examples of Maximum Required Bitrate on a Fronthaul Link for Poss= ible PHY-RF Split 38 Figure 8: Performance Comparison of Baseband Functional Split Options for v= RAN 40 Figure 9: Annual Global Throughput of Mobile Network Data Traffic by Region= : 2017 =96 2030 (Exabytes) 44 Figure 10: ETSI NFV Architecture 56 Figure 11: M-CORD Focus Areas 65 Figure 12: nFAPI Interfaces 67 Figure 13: Distributed vRAN Deployment Model 72 Figure 14: Cloud RAN Deployment Model 73 Figure 15: Virtualized Small Cell Deployment Model 74 Figure 16: China Mobile=92s Cloud RAN Vision 77 Figure 17: NTT DoCoMo=92s Advanced C-RAN Architecture 80 Figure 18: SK Telecom's SDRAN (Software Defined RAN) Architecture 84 Figure 19: SoftBank's Virtualized Small Cell Trial 86 Figure 20: vRAN Industry Roadmap 91 Figure 21: vRAN Value Chain 93 Figure 22: Global vRAN Revenue: 2017 =96 2030 ($ Million) 160 Figure 23: Global vRAN Revenue by Deployment Model: 2017 =96 2030 ($ Millio= n) 161 Figure 24: Global Virtualized Small Cell RAN Revenue: 2017 =96 2030 ($ Mill= ion) 161 Figure 25: Global Virtualized Macrocell RAN Revenue: 2017 =96 2030 ($ Milli= on) 162 Figure 26: Global vRAN Revenue by Air Interface Technology: 2017 =96 2030 (= $ Million) 162 Figure 27: Global Virtualized LTE & 3G RAN Revenue: 2017 =96 2030 ($ Millio= n) 163 Figure 28: Global Virtualized 5G NR RAN Revenue: 2017 =96 2030 ($ Million) = 163 Figure 29: Global vRAN Revenue by Submarket: 2016 - 2030 ($ Million) 164 Figure 30: Global vRAN Radio Unit Shipments: 2017 =96 2030 (Thousands of Un= its) 164 Figure 31: Global vRAN Radio Unit Shipment Revenue: 2017 =96 2030 ($ Millio= n) 165 Figure 32: Global vRAN Radio Unit Shipments by Deployment Model: 2017 =96 2= 030 (Units) 165 Figure 33: Global vRAN Radio Unit Shipment Revenue by Deployment Model: 201= 7 =96 2030 ($ Million) 166 Figure 34: Global Virtualized Small Cell Radio Unit Shipments: 2017 =96 203= 0 (Units) 166 Figure 35: Global Virtualized Small Cell Radio Unit Shipment Revenue: 2017 = =96 2030 ($ Million) 167 Figure 36: Global Virtualized Macrocell Radio Unit Shipments: 2017 =96 2030= (Units) 167 Figure 37: Global Virtualized Macrocell Radio Unit Shipment Revenue: 2017 = =96 2030 ($ Million) 168 Figure 38: Global vBBU Shipments: 2017 =96 2030 (Units) 168 Figure 39: Global vBBU Shipment Revenue: 2017 =96 2030 ($ Million) 169 Figure 40: Global vBBU Shipments by Deployment Model: 2017 =96 2030 (Units)= 169 Figure 41: Global vBBU Shipment Revenue by Deployment Model: 2017 =96 2030 = ($ Million) 170 Figure 42: Global Virtualized Small Cell BBU Shipments: 2017 =96 2030 (Unit= s) 170 Figure 43: Global Virtualized Small Cell BBU Shipment Revenue: 2017 =96 203= 0 ($ Million) 171 Figure 44: Global Virtualized Macrocell BBU Shipments: 2017 =96 2030 (Units= ) 171 Figure 45: Global Virtualized Macrocell BBU Shipment Revenue: 2017 =96 2030= ($ Million) 172 Figure 46: vRAN Revenue by Region: 2017 =96 2030 ($ Million) 173 Figure 47: vRAN Radio Unit Shipments by Region: 2017 =96 2030 (Thousands of= Units) 173 Figure 48: vRAN Radio Unit Shipment Revenue by Region: 2017 =96 2030 ($ Mil= lion) 174 Figure 49: vBBU Shipments by Region: 2017 =96 2030 (Units) 174 Figure 50: vBBU Shipment Revenue by Region: 2017 =96 2030 ($ Million) 175 Figure 51: Asia Pacific vRAN Revenue: 2017 =96 2030 ($ Million) 176 Figure 52: Asia Pacific vRAN Radio Unit Shipments: 2017 =96 2030 (Thousands= of Units) 176 Figure 53: Asia Pacific vRAN Radio Unit Shipment Revenue: 2017 =96 2030 ($ = Million) 177 Figure 54: Asia Pacific vBBU Shipments: 2017 =96 2030 (Units) 177 Figure 55: Asia Pacific vBBU Shipment Revenue: 2017 =96 2030 ($ Million) 178 Figure 56: Eastern Europe vRAN Revenue: 2017 =96 2030 ($ Million) 179 Figure 57: Eastern Europe vRAN Radio Unit Shipments: 2017 =96 2030 (Thousan= ds of Units) 179 Figure 58: Eastern Europe vRAN Radio Unit Shipment Revenue: 2017 =96 2030 (= $ Million) 180 Figure 59: Eastern Europe vBBU Shipments: 2017 =96 2030 (Units) 180 Figure 60: Eastern Europe vBBU Shipment Revenue: 2017 =96 2030 ($ Million) = 181 Figure 61: Middle East & Africa vRAN Revenue: 2017 =96 2030 ($ Million) 182 Figure 62: Middle East & Africa vRAN Radio Unit Shipments: 2017 =96 2030 (T= housands of Units) 182 Figure 63: Middle East & Africa vRAN Radio Unit Shipment Revenue: 2017 =96 = 2030 ($ Million) 183 Figure 64: Middle East & Africa vBBU Shipments: 2017 =96 2030 (Units) 183 Figure 65: Middle East & Africa vBBU Shipment Revenue: 2017 =96 2030 ($ Mil= lion) 184 Figure 66: Latin & Central America vRAN Revenue: 2017 =96 2030 ($ Million) = 185 Figure 67: Latin & Central America vRAN Radio Unit Shipments: 2017 =96 2030= (Thousands of Units) 185 Figure 68: Latin & Central America vRAN Radio Unit Shipment Revenue: 2017 = =96 2030 ($ Million) 186 Figure 69: Latin & Central America vBBU Shipments: 2017 =96 2030 (Units) 186 Figure 70: Latin & Central America vBBU Shipment Revenue: 2017 =96 2030 ($ = Million) 187 Figure 71: North America vRAN Revenue: 2017 =96 2030 ($ Million) 188 Figure 72: North America vRAN Radio Unit Shipments: 2017 =96 2030 (Thousand= s of Units) 188 Figure 73: North America vRAN Radio Unit Shipment Revenue: 2017 =96 2030 ($= Million) 189 Figure 74: North America vBBU Shipments: 2017 =96 2030 (Units) 189 Figure 75: North America vBBU Shipment Revenue: 2017 =96 2030 ($ Million) 1= 90 Figure 76: Western Europe vRAN Revenue: 2017 =96 2030 ($ Million) 191 Figure 77: Western Europe vRAN Radio Unit Shipments: 2017 =96 2030 (Thousan= ds of Units) 191 Figure 78: Western Europe vRAN Radio Unit Shipment Revenue: 2017 =96 2030 (= $ Million) 192 Figure 79: Western Europe vBBU Shipments: 2017 =96 2030 (Units) 192 Figure 80: Western Europe vBBU Shipment Revenue: 2017 =96 2030 ($ Million) = 193 Figure 81: Centralization & Virtualization of RAN Functions 197 Figure 82: Centralized vs. Distributed Cloud RAN Architecture 200 Figure 83: Nokia's Cloud Based Radio Architecture 201 Figure 84: TCO Comparison Between vRAN and Conventional RAN Architecture ($= per GB) 213 Figure 85: Conceptual Architecture for Network Slicing in Mobile Networks 2= 16 Figure 86: nFAPI support for LAA=92s LBT Functionality 218 =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@snsresearchreports.com =20 =20 To unsubscribe send an email with unsubscribe in the subject line to: remov= e@snsreports.com =20 From owner-freebsd-ppc@freebsd.org Mon Jan 16 21:06: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 94C8ACB3309 for ; Mon, 16 Jan 2017 21:06:04 +0000 (UTC) (envelope-from eekee57@fastmail.fm) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (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 6C9D31ECD for ; Mon, 16 Jan 2017 21:06:04 +0000 (UTC) (envelope-from eekee57@fastmail.fm) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 403F820AE4 for ; Mon, 16 Jan 2017 15:57:24 -0500 (EST) Received: from web6 ([10.202.2.216]) by compute1.internal (MEProxy); Mon, 16 Jan 2017 15:57:24 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=HiULwHW1QVGI0vY1bz1OeZd2yc s=; b=pannG72eNPncOeOkR3RAVFy45EdjSir5z1ANYzBaLqDJOp9FQ5NAWm88RA rTn3T1Qe9/AKsBeQGxIUvVKFoi6js0uKlVUYy6+jIS+XGFW8pPxWkJnsFjpoL59C 0tErljw8vv8E3bP2yq6f+V7TYfGpTc+SLhwDo90Rn3lhAt/k0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=smtpout; bh=Hi ULwHW1QVGI0vY1bz1OeZd2ycs=; b=dp7JinMKqkEDsECQavD7tESmuWe+Kwzjlm EotE44Jr0grb8h/GGTPlDFvV2C2v6rlwdm5I67TDkrz5EeIDQgoO+q+0jINowLdP MY9wlWY27X40O7r4funI6rhYnLodS8k8q4Fn4H39KuS4kOFJTWy9BdHxmpeAy0xH l/nL106iY= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 24BEF48001; Mon, 16 Jan 2017 15:57:24 -0500 (EST) Message-Id: <1484600244.52996.849632072.1063E517@webmail.messagingengine.com> From: Ethan Grammatikidis To: freebsd-ppc@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-d492654e In-Reply-To: <6483994748002496425158@Ankur> Subject: Re: The vRAN (Virtualized Radio Access Network) Ecosystem: 2017 - 2030 - Opportunities, Challenges, Strategies & Forecasts (Report) Date: Mon, 16 Jan 2017 20:57:24 +0000 References: <6483994748002496425158@Ankur> 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, 16 Jan 2017 21:06:04 -0000 On Mon, Jan 16, 2017, at 07:47 AM, Andy Silva wrote: > The vRAN (Virtualized Radio Access Network) Ecosystem: 2017 =E2=80=93 203= 0 =E2=80=93 Opportunities, Challenges, Strategies & Forecasts (Report) This seems cool (but a bit beyond my level), but why is it on the ppc list?= I'm new here, forgive me if I don't know what the usual usage is. From owner-freebsd-ppc@freebsd.org Tue Jan 17 02:47:15 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 D7E89CB24E9; Tue, 17 Jan 2017 02:47:15 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (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 9F1221119; Tue, 17 Jan 2017 02:47:15 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-io0-x244.google.com with SMTP id c80so14494492iod.1; Mon, 16 Jan 2017 18:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=cc:message-id:from:to:in-reply-to:content-transfer-encoding :mime-version:subject:date:references; bh=ZrGTEk/NIEaj+Nj09uEDG0cVV60iSM0wIwK5oj+Gh4c=; b=C5g4OHl02xHFxeIBc+RqZkNonCGPoxAZn6HRTx4P25H758TOM/lV4vr9MVv00HGSap a+BqeWT8pS9MJIDFH6nkpnLwuVKzB4bsbQjR7vJJIEf/Yt/NH0XX/tGuvu38whQg3CWw Ufq02xl9kmboWJ5DiX/pn3ZkGvvuZ1b/IdzdXJrjE1HHQIEWMxXMMmEXV5gsOGMFkzTw HbOt4ANEZ4wI+VxGfia7KjB3cNm8VZo+g2p1WoTzsqD2fFeKbOuHRfeVUArsOekLKUYs IWlh2fRa+KxGFoTvxP8gXJorSlGJm90nzERe7iS6JbZVx5etN37c3UHDjg9Q+EHvcJw5 s/+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:cc:message-id:from:to:in-reply-to :content-transfer-encoding:mime-version:subject:date:references; bh=ZrGTEk/NIEaj+Nj09uEDG0cVV60iSM0wIwK5oj+Gh4c=; b=XzIWgfzB8tUtRGRFwqkWaA/IojV//AFHQyH84uZUcAk1aPRd8myw3jLmp8sU+fuTLh U9INjaI9Zddrh9mG42KUz1hcRyNYV7O9nLaxeFqf/K0pAnxjyy9P65Qj+m4y+1zvcFDm dEkDY5fQnkrt3PRZ4ZZPbsWdaAoB5A3YjJSe9ovg3DhYQyZ/PQZt+makdnNaQd5ifcsh 1AXtak4x7rtua6Ln7ZFCj3Po7tXVMQK0fka6X0lxDMT3KKbcM3vPN0fPbjC6VmC4avVH cZ6Woul1zg1ZYmNNdi9eJCdrx23bOA4KC0a/uFhEXK4bGVHFtFMNqSBR4f5UydkAsqqu t7ug== X-Gm-Message-State: AIkVDXIBxDU7OIVKf68Wv9/jv5NiFKF2DE5g4xLubapcZT4BtsvriDhxa6Ls9n5lvETXqQ== X-Received: by 10.107.132.81 with SMTP id g78mr34507293iod.227.1484621234933; Mon, 16 Jan 2017 18:47:14 -0800 (PST) Received: from blackstar.knownspace (50-80-150-234.client.mchsi.com. [50.80.150.234]) by smtp.gmail.com with ESMTPSA id 191sm12310850ioe.37.2017.01.16.18.47.13 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 16 Jan 2017 18:47:14 -0800 (PST) Cc: Mark Millard , FreeBSD Toolchain , FreeBSD PowerPC ML Message-Id: From: Justin Hibbits To: Roman Divacky In-Reply-To: <20161205161904.GA7889@vlakno.cz> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Date: Mon, 16 Jan 2017 20:45:58 -0600 References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> X-Mailer: Apple Mail (2.936) 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: Tue, 17 Jan 2017 02:47:15 -0000 The patch is incorrect, the 'xo' values are off by one bit (inline change): On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote: > Can you try this patch? > > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > =================================================================== > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > @@ -2373,6 +2373,12 @@ > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > "mftb $RT, $SPR", IIC_SprMFTB>; > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), 334 should be 167 > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > + > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; 462 should be 231. > + > // A pseudo-instruction used to implement the read of the 64-bit > cycle counter > // on a 32-bit target. > let hasSideEffects = 1, usesCustomInserter = 1 in > I'll have a patch ready for LLVM review within a week or so, including some level of scheduling. - Justin From owner-freebsd-ppc@freebsd.org Tue Jan 17 19:49:28 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 27A02CB4B91; Tue, 17 Jan 2017 19:49:28 +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 E3CAF1E6D; Tue, 17 Jan 2017 19:49:27 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 9C74F12CB9F; Tue, 17 Jan 2017 20:46:51 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1484682411; bh=3Ml3gY/QKFO0dHMw4929LDJXxsyMwi2dL9NiY46f0x8=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=PjzjUGWmJly+QO0Oc+NIavGY+ZlKO2+Cut1BqYK5QRgX+66gvFe7uSW64laLb8omW A18mvJ2iSBsjk2Z58ucMZLHJZZl6mS/kMbjop1JaBYc5u2enIoMKM0y5Mb17BTok7j Im7J80qcdMc9wooBm0GYOfI/joDZttfA1iw8OeK8= Date: Tue, 17 Jan 2017 20:46:51 +0100 From: Roman Divacky To: Justin Hibbits Cc: Mark Millard , FreeBSD Toolchain , FreeBSD PowerPC ML Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . Message-ID: <20170117194651.GA88907@vlakno.cz> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) 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: Tue, 17 Jan 2017 19:49:28 -0000 Are you sure? My coy of PowerISA lists the numbers that I used? What makes you think it should be shifted by one bit? On Mon, Jan 16, 2017 at 08:45:58PM -0600, Justin Hibbits wrote: > The patch is incorrect, the 'xo' values are off by one bit (inline > change): > > > On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote: > > > Can you try this patch? > > > > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > > =================================================================== > > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > @@ -2373,6 +2373,12 @@ > > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > > "mftb $RT, $SPR", IIC_SprMFTB>; > > > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > > 334 should be 167 > > > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > > + > > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > > 462 should be 231. > > > + > > // A pseudo-instruction used to implement the read of the 64-bit > > cycle counter > > // on a 32-bit target. > > let hasSideEffects = 1, usesCustomInserter = 1 in > > > > I'll have a patch ready for LLVM review within a week or so, including > some level of scheduling. > > - Justin From owner-freebsd-ppc@freebsd.org Tue Jan 17 20:33:05 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 4C327CB4175; Tue, 17 Jan 2017 20:33:05 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 05F331CAB; Tue, 17 Jan 2017 20:33:05 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-qt0-x233.google.com with SMTP id l7so178981807qtd.1; Tue, 17 Jan 2017 12:33:04 -0800 (PST) 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=ZUiLChI8TlZJAnT7zw1vn7TLWt0FJRL6MChrvjmtE54=; b=kG7ewu1jYA2XQrWr3tbtxcuxD4f4kiQuLiQBx5jL1n71QYMussuTavaqJqLkj57/P8 53YUStFHeJTYH4EV91gy9di/jVkzO1nVa/H55j+/u1U8x4bA+wIRePivu4TtwEJlV9PY Pfxs6N06JFXIHcGr3F2UwnSIJL4Jp4+z3uCE0zYLF4+JwYQXv3OKRMCZPB4ZRopz4R17 eRUk0RPtVInpimxZ7QuqV+drTi+rEakDp8ww5PPO4NLQ0jV1lOsyD4iybNm4v46CEUm2 yA03O7uBOjQ9JnAdB0XcLBGmES2Zp8JpEoMqTKAaE+jbyepwC9qzR81Nwe2RvVWxhPI/ 2cEA== 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=ZUiLChI8TlZJAnT7zw1vn7TLWt0FJRL6MChrvjmtE54=; b=iQGAVIuFf+z/OTdJt7uK3gKKNvWGXBsJcFBUgA6q3XJHnJkJEsEG7oxccbvQ9Nfp8H Ie9jEw6ltJk1ELQAn+QNd5Xjpxi2L//vtzLxcDvE8bd4d8b6S+L7fUzf6BOhUUw1wjKI Ayz8fIf3B7/69KnlZ0Iky9LkLCw4hmZ3bGYgcWrstZFkscR+vWnt+PUPU7z/f98aU70F JxQY9YagKxbjrZU7E+dMeGqWKxC8VoMpx4ttB0Or1qc+bNMzf7yXwjGxkQuUk5C3xpV3 JybEV1jK/T0xfqw6S3l6CVTqAXeeJ8BjV7e/hR1A526gkprQoG4+Y6ZxpT33tllv04AX PfCg== X-Gm-Message-State: AIkVDXKFoinzw5Zn/21uTaZkWngcSFzzRWbmU8lbUuTWAEb4YgffN3hSXQboIVyDKbnRShOXhw7fDO4u3Yec7Q== X-Received: by 10.200.56.76 with SMTP id r12mr35423342qtb.2.1484685184102; Tue, 17 Jan 2017 12:33:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.157.69 with HTTP; Tue, 17 Jan 2017 12:33:03 -0800 (PST) In-Reply-To: <20170117194651.GA88907@vlakno.cz> References: <300CB7A2-34BB-407F-B2E9-D263B119A989@dsl-only.net> <20161205161904.GA7889@vlakno.cz> <20170117194651.GA88907@vlakno.cz> From: Justin Hibbits Date: Tue, 17 Jan 2017 14:33:03 -0600 Message-ID: Subject: Re: clang 3.9.0 buildkernel on old powerpc64's vs. trying to build hwpmc_e500.o and the like. . . To: Roman Divacky Cc: FreeBSD Toolchain , Mark Millard , FreeBSD PowerPC ML 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: Tue, 17 Jan 2017 20:33:05 -0000 I was incorrect. The Freescale reference actually lists both numbers in the instruction list (167/231 in A.1 and A.5, 334/462 in A.2). The values you listed are correct, and match what GCC generates as well. - Justin On Jan 17, 2017 13:49, "Roman Divacky" wrote: > Are you sure? My coy of PowerISA lists the numbers that I used? What makes > you > think it should be shifted by one bit? > > On Mon, Jan 16, 2017 at 08:45:58PM -0600, Justin Hibbits wrote: > > The patch is incorrect, the 'xo' values are off by one bit (inline > > change): > > > > > > On Dec 5, 2016, at 10:19 AM, Roman Divacky wrote: > > > > > Can you try this patch? > > > > > > Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td > > > =================================================================== > > > --- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675) > > > +++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy) > > > @@ -2373,6 +2373,12 @@ > > > def MFTB : XFXForm_1<31, 371, (outs gprc:$RT), (ins i32imm:$SPR), > > > "mftb $RT, $SPR", IIC_SprMFTB>; > > > > > > +def MFPMR : XFXForm_1<31, 334, (outs gprc:$RT), (ins i32imm:$PMRN), > > > > 334 should be 167 > > > > > + "mfpmr $RT, $PMRN", IIC_IntGeneral>; > > > + > > > +def MTPMR : XFXForm_1<31, 462, (outs), (ins i32imm:$PMRN, gprc:$RS), > > > + "mtpmr $PMRN, $RS", IIC_IntGeneral>; > > > > 462 should be 231. > > > > > + > > > // A pseudo-instruction used to implement the read of the 64-bit > > > cycle counter > > > // on a 32-bit target. > > > let hasSideEffects = 1, usesCustomInserter = 1 in > > > > > > > I'll have a patch ready for LLVM review within a week or so, including > > some level of scheduling. > > > > - Justin > From owner-freebsd-ppc@freebsd.org Wed Jan 18 03:42: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 CA757CB47C4 for ; Wed, 18 Jan 2017 03:42:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (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 B8F161E86 for ; Wed, 18 Jan 2017 03:42:43 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v0I3ghmo073164 for ; Wed, 18 Jan 2017 03:42:43 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ppc@FreeBSD.org Subject: [Bug 215681] head -r310854: TARGET_ARCH=powerpc buildkernel via clang 3.9.1: sys/powerpc/aim/trap_subr32.S:409:2: error: too few operands for instruction Date: Wed, 18 Jan 2017 03:42:43 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ppc@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 18 Jan 2017 03:42:43 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D215681 --- Comment #5 from commit-hook@freebsd.org --- A commit references this bug: Author: jhibbits Date: Wed Jan 18 03:42:21 UTC 2017 New revision: 312369 URL: https://svnweb.freebsd.org/changeset/base/312369 Log: Use the explicit expanded form of cmp. Clang apparently requires the explicit form of this instruction, and reje= cts uses which ignore the optional cmpD register. This was the only use of t= he shorthand form of the instruction, so just fix it up to match the others. PR: kern/215681 Submitted by: Mark Millard Reported by: Mark Millard MFC after: 2 weeks Changes: head/sys/powerpc/aim/trap_subr32.S --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ppc@freebsd.org Wed Jan 18 12:00: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 9ACDCCB5A8A for ; Wed, 18 Jan 2017 12:00:56 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 4FF491392 for ; Wed, 18 Jan 2017 12:00:55 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10910 invoked from network); 18 Jan 2017 12:02:22 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 18 Jan 2017 12:02:22 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Wed, 18 Jan 2017 07:00:49 -0500 (EST) Received: (qmail 22378 invoked from network); 18 Jan 2017 12:00:49 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 18 Jan 2017 12:00:49 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 9BDCCEC9092; Wed, 18 Jan 2017 04:00:48 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Bug 216229 - head: (e.g. -r312009): kernel-toolchain: bootstrap-tools stage libllvmminimal can fail for lack of -I options Message-Id: <395F73EA-4544-4239-861F-7EF8386A419D@dsl-only.net> Date: Wed, 18 Jan 2017 04:00:47 -0800 To: FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) 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: Wed, 18 Jan 2017 12:00:56 -0000 I have reported the following as bugzilla 216229. . . [powerpc64 may not be essential but it is the environment I found this in.] Background information: libllvmminimal has C++ code, not (just) C code. [Note that CFLAGS has things like -std=3Dgnu99 that are not appropriate = to c++ (clang++).] So the lines from /usr/src/lib/clang/llvm.build.mk for CFLAGS: CFLAGS+=3D -I${SRCTOP}/lib/clang/include CFLAGS+=3D -I${LLVM_SRCS}/include CFLAGS+=3D -DLLVM_ON_UNIX CFLAGS+=3D -DLLVM_ON_FREEBSD CFLAGS+=3D -D__STDC_LIMIT_MACROS CFLAGS+=3D -D__STDC_CONSTANT_MACROS #CFLAGS+=3D -DNDEBUG . . . CFLAGS+=3D -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"${TARGET_TRIPLE}\" CFLAGS+=3D -DLLVM_HOST_TRIPLE=3D\"${BUILD_TRIPLE}\" CFLAGS+=3D -DDEFAULT_SYSROOT=3D\"${TOOLS_PREFIX}\" do not contribute to the C++ compiles for libllvmminimal. (See the later meta file content from such a failure: no -I options at all.) Thus unless the system compiler is in use so that no bootstrap compiler is to be built. . . The lack of -I definitions for C++ ends up with build failures such as below (from a first-time kernel-toolchain example): (this was a on-powerpc64, targeting powerpc64, example, not a cross-build) # Meta data file = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= tmp/usr/src/lib/clang/libllvmminimal/_usr_obj_powerpc64vtsc_clang_altbinut= ils_kernel_powerpc.powerpc64_usr_src_tmp_usr_src_lib_clang_libllvmminimal_= Support_APInt.o.meta CMD clang++ -B/usr/local/powerpc64-freebsd/bin/ -std=3Dc++11 = -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wno-c++11-extensions -c = /usr/src/contrib/llvm/lib/Support/APInt.cpp -o Support/APInt.o CWD = /usr/obj/powerpc64vtsc_clang_altbinutils_kernel/powerpc.powerpc64/usr/src/= tmp/usr/src/lib/clang/libllvmminimal TARGET Support/APInt.o -- command output -- /usr/src/contrib/llvm/lib/Support/APInt.cpp:15:10: fatal error: = 'llvm/ADT/APInt.h' file not found #include "llvm/ADT/APInt.h" ^ 1 error generated. *** Error code 1 libllvmminimal is not necessarily the only problem but it is the first = one and it is very early (bootstrap-tools stage). -I is not necessarily the only compile option type that is missing for libllvmminimal. [Note: I've a couple of poudriere-devel submittals that may actually = trace back to such issues --so poudriere might not be essential to the actual = issue.] =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Jan 21 20:19: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 C7921CBB431 for ; Sat, 21 Jan 2017 20:19:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-11.reflexion.net [208.70.210.11]) (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 8C718942 for ; Sat, 21 Jan 2017 20:19:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 2117 invoked from network); 21 Jan 2017 20:19:23 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Jan 2017 20:19:23 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 21 Jan 2017 15:19:23 -0500 (EST) Received: (qmail 17572 invoked from network); 21 Jan 2017 20:19:23 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jan 2017 20:19:23 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 75150EC8257; Sat, 21 Jan 2017 12:19:22 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: I have submitted llvm bugzilla 31716 for lld 3.9.1's incoherent .plt vs. .got.plt content for powerpc64 Message-Id: Date: Sat, 21 Jan 2017 12:19:21 -0800 Cc: Roman Divacky , Justin Hibbits , Nathan Whitehorn To: Ed Maste , FreeBSD Toolchain , FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) 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: Sat, 21 Jan 2017 20:19:30 -0000 I've copied the submittal information later below. I've also added 31716 to llvm bugzilla 25780 (the meta-submittal for using clang as the FreeBSD/ppc system context). If this is wrong for some reason fell free to delete the item from the Depends On list. I did reference: > I've not found any powerpc family documentation > for .got.plt use: No such powerpc64 ABI yet? What I wrote in the submittal was: > powerpc64 context for: >=20 > # more main.c > static volatile char big_area[67001] =3D "This is a test"; >=20 > int main () > { > big_area[67000] =3D '9'; > } >=20 > via: >=20 > clang -fuse-ld=3Dlld -g main.c >=20 > The code that is put in the .plt that does not > match the .got.plt layout used (expecting function > descriptors when there are only single addresses per > function as a .got.plt entry) is: >=20 > void PPC64TargetInfo::writePlt(uint8_t *Buf, uint64_t GotEntryAddr, > uint64_t PltEntryAddr, int32_t Index, > unsigned RelOff) const { > uint64_t Off =3D GotEntryAddr - getPPC64TocBase(); >=20 > // FIXME: What we should do, in theory, is get the offset of the = function > // descriptor in the .opd section, and use that as the offset from %r2 = (the > // TOC-base pointer). Instead, we have the GOT-entry offset, and that = will > // be a pointer to the function descriptor in the .opd section. Using > // this scheme is simpler, but requires an extra indirection per PLT = dispatch. >=20 > write32be(Buf, 0xf8410028); // std %r2, 40(%r1) > write32be(Buf + 4, 0x3d620000 | applyPPCHa(Off)); // addis %r11, %r2, = X@ha > write32be(Buf + 8, 0xe98b0000 | applyPPCLo(Off)); // ld %r12, = X@l(%r11) > write32be(Buf + 12, 0xe96c0000); // ld %r11,0(%r12) > write32be(Buf + 16, 0x7d6903a6); // mtctr %r11 > write32be(Buf + 20, 0xe84c0008); // ld %r2,8(%r12) > write32be(Buf + 24, 0xe96c0010); // ld %r11,16(%r12) > write32be(Buf + 28, 0x4e800420); // bctr > } >=20 > But what ld.lld generated for relocation was: >=20 > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name = + r_addend > 000010030038 000300000015 R_PPC64_JMP_SLOT 0000000000000000 atexit = + 0 > 000010030040 000200000015 R_PPC64_JMP_SLOT 0000000000000000 = _init_tls + 0 > 000010030048 000500000015 R_PPC64_JMP_SLOT 0000000000000000 exit + = 0 >=20 > These r_offset's are in the .got.plt area, not in the .plt area: >=20 > 0x0000000010030020 - 0x0000000010030050 is .got.plt >=20 > The increment is 0x8 between entries, not 0x18 (or more) that > would be needed for function descriptors: There is no > function descriptor space here. >=20 > It looks like the other side of this that is not establishing > space for function descriptors is in the code in: >=20 > /usr/src/contrib/llvm/tools/lld/ELF/Relocations.cpp >=20 > in its scanRelocs : >=20 > // At this point we are done with the relocated position. Some = relocations > // also require us to create a got or plt entry. >=20 > // If a relocation needs PLT, we create a PLT and a GOT slot for = the symbol. > if (needsPlt(Expr)) { > if (Body.isInPlt()) > continue; > Out::Plt->addEntry(Body); >=20 > uint32_t Rel; > if (Body.isGnuIFunc() && !Preemptible) > Rel =3D Target->IRelativeRel; > else > Rel =3D Target->PltRel; >=20 > Out::GotPlt->addEntry(Body); > Out::RelaPlt->addReloc({Rel, Out::GotPlt, > Body.getGotPltOffset(), = !Preemptible, > &Body, 0}); > continue; > } >=20 > The code is explicitly targeting creating GotPlt space, not > .opd space, as well., not matching the earlier comment in > PPC64TargetInfo::writePlt . >=20 > The effect of such code and the wrtPlt code need to be > correctly matching but currently are not. >=20 > For ld.lld's a.out its .plt (not .got.plt) is code, > unlike in the ld.bfd generated a.out: >=20 > Disassembly of section .plt: > 0000000010010550 <.plt> std r2,40(r1) > 0000000010010554 <.plt+0x4> addis r11,r2,0 > 0000000010010558 <.plt+0x8> ld r12,32512(r11) Note: = r12=3D=3D0x000010030038 results > 000000001001055c <.plt+0xc> ld r11,0(r12) > 0000000010010560 <.plt+0x10> mtctr r11 > 0000000010010564 <.plt+0x14> ld r2,8(r12) Note: accesses = 0x000010030040 see .plt+0x28 > 0000000010010568 <.plt+0x18> ld r11,16(r12) Note: accesses = 0x000010030048 see .plt+0x48 > 000000001001056c <.plt+0x1c> bctr >=20 > Note: The code expects 0(12), 8(12), and 16(r12) storage > but not such structure is present: 8(r12) above is > equivalent to 0(r12) below as an example. >=20 > 0000000010010570 <.plt+0x20> std r2,40(r1) > 0000000010010574 <.plt+0x24> addis r11,r2,0 > 0000000010010578 <.plt+0x28> ld r12,32520(r11) Note: = r12=3D=3D0x000010030040 results > 000000001001057c <.plt+0x2c> ld r11,0(r12) > 0000000010010580 <.plt+0x30> mtctr r11 > 0000000010010584 <.plt+0x34> ld r2,8(r12) Note: accesses = 0x000010030048 see .plt+0x48 > 0000000010010588 <.plt+0x38> ld r11,16(r12) Note: accesses = 0x000010030050 > 000000001001058c <.plt+0x3c> bctr >=20 > Note: 0x000010030050 is from: >=20 > 0x0000000010030050 - 0x00000000100300a0 is .toc >=20 > 0000000010010590 <.plt+0x40> std r2,40(r1) > 0000000010010594 <.plt+0x44> addis r11,r2,0 > 0000000010010598 <.plt+0x48> ld r12,32528(r11) Note: = r12=3D=3D0x000010030048 results > 000000001001059c <.plt+0x4c> ld r11,0(r12) > 00000000100105a0 <.plt+0x50> mtctr r11 > 00000000100105a4 <.plt+0x54> ld r2,8(r12) Note: accesses = 0x000010030050 > 00000000100105a8 <.plt+0x58> ld r11,16(r12) Note: accesses = 0x000010030058 > 00000000100105ac <.plt+0x5c> bctr >=20 > Note: 0x000010030050 and 0x000010030058 are from: >=20 > 0x0000000010030050 - 0x00000000100300a0 is .toc >=20 > Either the .got.plt entry layout changes to have room > for 8(r12) and 16(r12) positions (size change to 0x18 > Bytes per entry) or this code (and possibly other > code) changes --presuming .got.plt style is used at > all. (I've not found any powerpc family documentation > for .got.plt use: No such powerpc64 ABI yet?) >=20 > By contrast the -fuse-ld=3Dbfd ends up with: >=20 > Relocation section with addend (.rela.plt): > r_offset r_info r_type st_value st_name = + r_addend > 0000100218b0 000300000015 R_PPC64_JMP_SLOT 0000000000000000 atexit = + 0 > 0000100218c8 000400000015 R_PPC64_JMP_SLOT 0000000000000000 = _init_tls + 0 > 0000100218e0 000600000015 R_PPC64_JMP_SLOT 0000000000000000 exit + = 0 >=20 > is an increment of 0x18 between entries (room for the > function descriptors). The r_offset's are from the > ld.bfd generated .plt section: >=20 > 0x0000000010021898 - 0x00000000100218f8 is .plt >=20 > NOTE: For the FreeBSD ld.bfd context the .plt does not have > blocks of code for such, just the function descriptors. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-ppc@freebsd.org Sat Jan 21 22:16:42 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 20F1AC6DBEE for ; Sat, 21 Jan 2017 22:16:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-10.reflexion.net [208.70.210.10]) (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 CA59ADA for ; Sat, 21 Jan 2017 22:16:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14118 invoked from network); 21 Jan 2017 22:18:10 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 21 Jan 2017 22:18:10 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.1) with SMTP; Sat, 21 Jan 2017 17:16:34 -0500 (EST) Received: (qmail 27459 invoked from network); 21 Jan 2017 22:16:34 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 21 Jan 2017 22:16:34 -0000 Received: from [192.168.1.111] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id B57E5EC7888 for ; Sat, 21 Jan 2017 14:16:33 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: 3.9.1's lld and powerpc64 for -pie use: can't create dynamic relocation R_PPC64_REL24 against readonly segment Message-Id: <5FF1F3C4-E169-4967-9B08-F97A52B33E6F@dsl-only.net> Date: Sat, 21 Jan 2017 14:16:33 -0800 To: FreeBSD PowerPC ML X-Mailer: Apple Mail (2.3259) 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: Sat, 21 Jan 2017 22:16:42 -0000 For: # more main.c = = static volatile = char big_area[67001] =3D "This is a test"; int main () { big_area[67000] =3D '9'; } I get (the -fPIE is not required for the behavior): # clang -fuse-ld=3Dlld -Wl,-t -pie -fPIE main.c /usr/lib/Scrt1.o /usr/lib/crti.o /usr/lib/crtbeginS.o /tmp/main-c6f752.o /usr/lib/libgcc_s.so /lib/libc.so.7 /usr/lib/libgcc_s.so /usr/lib/crtendS.o /usr/lib/crtn.o can't create dynamic relocation R_PPC64_REL24 against readonly segment can't create dynamic relocation R_PPC64_REL24 against readonly segment can't create dynamic relocation R_PPC64_REL24 against readonly segment can't create dynamic relocation R_PPC64_REL24 against readonly segment can't create dynamic relocation R_PPC64_REL24 against readonly segment can't create dynamic relocation R_PPC64_REL24 against readonly segment clang: error: linker command failed with exit code 1 (use -v to see = invocation) (This is difficult to study because it does not leave even a partial a.out and it does not report the specifics of what segment or what symbol or the like.) Even an empty source produces that, but also including the expected: undefined symbol: main in /usr/lib/Scrt1.o It appears that the R_PPC64_REL24's are some subset of. . . /usr/lib/Scrt1.o : 00000000000000cc R_PPC64_REL24 atexit 00000000000000d8 R_PPC64_REL24 _init_tls 00000000000000f8 R_PPC64_REL24 atexit 00000000000001b4 R_PPC64_REL24 _init 0000000000000240 R_PPC64_REL24 main 0000000000000248 R_PPC64_REL24 exit 00000000000002fc R_PPC64_REL24 _fini (That would be 6 by ignoring main, matching the message count.) /usr/lib/crtbeginS.o : 0000000000000040 R_PPC64_REL24 __cxa_finalize 0000000000000000 R_PPC64_REL24 .opd 0000000000000000 R_PPC64_REL24 .opd+0x0000000000000018 /usr/lib/crtendS.o : 0000000000000000 R_PPC64_REL24 .opd main.o , if I have it produced, does not have R_PPC64_REL24 in it. =3D=3D=3D Mark Millard markmi at dsl-only.net