From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 7CC07820F6 for ; Thu, 16 Feb 2017 10:59:07 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C165D624CD; Thu, 16 Feb 2017 18:59:07 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-72.phx2.redhat.com [10.3.116.72]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1GIx6B4017343; Thu, 16 Feb 2017 13:59:06 -0500 To: Andrew Fish , "David A. Van Arnem" References: <485eda84-7d3c-cbcf-6dbe-bc302aa8e3c0@redhat.com> <09003614-2953-3c06-2b7d-b0fdb81fd581@cmlab.biz> <8d78b23b-8b0a-399f-0f9f-014099ed545b@cmlab.biz> <2e03bfce-ef30-44cb-4da8-b90d23c6ec1b@cmlab.biz> Cc: "edk2-devel@lists.01.org" From: Laszlo Ersek Message-ID: <58a753b5-77f5-fa9e-2691-900af38fe0bc@redhat.com> Date: Thu, 16 Feb 2017 19:59:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 16 Feb 2017 18:59:08 +0000 (UTC) Subject: =?UTF-8?B?UmU6IERFQlVHKCkgbWFjcm9zIGluIERYRSBkcml2ZXI6IGNhbuKAmXQgbWFrZSBpdCB3b3JrIGluIFFFTVU=?= X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:59:07 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 02/16/17 19:05, Andrew Fish wrote: > >> On Feb 15, 2017, at 4:39 AM, Laszlo Ersek > > wrote: >> >> On 02/15/17 01:00, David A. Van Arnem wrote: >>> >>> >>> On 02/14/2017 04:46 PM, Nikolay Bodunov wrote: >>>> Hi >>>> >>>> I red this topic before asking the question in the maillist. >>>> Unfortunately, >>>> it's not for DXE phase. >>>> I even tried to use it and recieved expected compiler error: >>>> >>>> error 1001: Module type [PEIM] is not supported by library instance >>>> [/home/nick/src/edk2/MdePkg/Library/UefiDebugLibConOut/ >>>> UefiDebugLibConOut.inf] >>>> consumed by [/home/nick/src/edk2/MdeModulePkg/Bus/Pci/ >>>> SdMmcPciHcPei/SdMmcPciHcPei.inf] >>> >>> Hi, >>> >>> MdePkg/Library/UefiDebugLibConOut/UefiDebugLibConOut.inf lists >>> DXE_DRIVER in its [Defines] section under LIBRARY_CLASS, so it is >>> compatible with DXE_DRIVER module types (I have used it this way). >>> However, if I'm reading your output correctly, you are trying to build a >>> PEI module which is why you are getting the error. PEI is outside of my >>> knowledge. >> >> In the PEI phase, no such thing exists as "system console" (that's a >> UEFI construct), hence the fact that UefiDebugLibConOut (which prints to >> said console) rejects being linked into PEIMs (PEI modules) is justified. >> >> Again, a suitable DebugLib instance should be chosen (in the DSC file >> where the PEIM in question is listed too, resolving the DebugLib class >> for PEIMs), and DEBUG() macros should be used for logging. >> > > The build system is very flexible and can be a bit confusing. I find it > useful to generate a report by passing --report-file=REPORTFILE to the > build command. This will generate a report that will tell you per driver > what libraries actually got linked (include libraries that libraries > depend on). it will show all the fixed PCD settings as visible to the > driver. If an FV was constructed it will also show the Depex that > determines dispatch order, and again this can be changed by the > libraries that get used. > > The idea behind the flexibility was that a chip or card vendor could > write code using #include and link against DebugLib > and it would work for any platform. Actually you could have multiple > platforms in a single repository that share that code that all use > different debug strategies, without the need to change chip or card > vendor code. Thus we kind of had a push the configuration choices into > the platform build kind of mind set. > > Well the problem with flexibility is complexity, and that is what the > build logs help with. I agree. I don't know why I failed to mention the report file, as it is part of my OvmfPkg / ArmVirtPkg build wrapper scripts. The report file is super useful; I frequently consult it. (For PCDs too.) Thanks! Laszlo