From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 4C0398178D for ; Wed, 15 Feb 2017 09:19:36 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id c7so67952039itd.1 for ; Wed, 15 Feb 2017 09:19:36 -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=zBczSiLnydgS1xQ2pt9a/JqtVGTtbGVJzCbznIblV8U=; b=KB/aXPOjKqjQDAHxJ285v9NWNOiy0TDoH/mvPA13hkv0lIQtySabHa63kWySutQvTt xCkYbhPtCto02vfaH4FAlK44Sx3dboR+82u/X9n/P9DbIsd41aY+ESsxzBD/NvZVikbI Kkt+Y28TFjZKbLRPJnv82wxRJlqNt1Rtc6l0KsEAITvbhbio/H8J8WbOBn5hhyfXODdP imjSH+pLp3AGjo69P/cxTKxLMVYkHYs6vvhuoQH4rSU42mK6i1rCQk6GLYg/TS/s68mu REleCQPFx7cy4wV333OLKyp3fM1d+WQTUuNt0LOEMLz00fWHvxud+fVTaD6Xr7w4yps6 hGvg== 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=zBczSiLnydgS1xQ2pt9a/JqtVGTtbGVJzCbznIblV8U=; b=EYSya+76WUhAGXdIaX2uK+o+75GgwbO0eiLoKxs0ZqjAV5xMspcNSKCL61rR0iPQzy tRMEkXfIIbGWu+uSWdQ36Tohk1Tnw06uUIkSeiToEPhwG+3+MwXwFRoryuypzHfXUm83 EKzeHFB13Og3NxWHPpO2tUB5WvSLXnqZGk0c2zvbRcdPKtyB9Ecco/FFQSqbuS78y1c5 74N8OSHNRFKzx3eZu5btMWaapidH4Im1mcisistQ23g+SKopPsmEujbHjvntJsqD7tLu XTURKCAf2XrqoqtJyRh5VS806drTfw3nhOQUgUxLznpzsWFVE3B7/5bhGhOt9pNoDREQ fxnA== X-Gm-Message-State: AMke39mBVGgGqkALpQxGx98XiauxU59hHVWEImImObwD8H0POvkTL/ryOhN9Tyu92Crot69G8br59al8OjVRpA== X-Received: by 10.36.135.74 with SMTP id f71mr10047578ite.101.1487179175402; Wed, 15 Feb 2017 09:19:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.241.204 with HTTP; Wed, 15 Feb 2017 09:19:34 -0800 (PST) In-Reply-To: <9699113b-6e45-cd5c-c60d-f500f2ef072f@redhat.com> References: <485eda84-7d3c-cbcf-6dbe-bc302aa8e3c0@redhat.com> <9699113b-6e45-cd5c-c60d-f500f2ef072f@redhat.com> From: Nikolay Bodunov Date: Wed, 15 Feb 2017 20:19:34 +0300 Message-ID: To: Laszlo Ersek Cc: "Kinney, Michael D" , "edk2-devel@ml01.01.org" X-Content-Filtered-By: Mailman/MimeDel 2.1.21 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: Wed, 15 Feb 2017 17:19:36 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Laszlo First of all, great thanks to you and all others for spending your time for explanations! I fixed it. A problem was, as you suggested, in setting different DebugLib implementarions in OVMF and my DXE driver. First, I compiled my DXE driver together with OVMF, to guarantee that DebugLib implementation will be the same (PlatformDebugLibIoPort), and got DEBUG()'s strings in output file. Second, I set same DebudLib implementation for MdeModulePkg and got same results. All I want now is to redirect DEBUG() output in other file, than one with kernel messages, for simplify reading, but I think it shouldn't be too complex now. Thank you one more time! With best regards, Nikolay 2017-02-15 13:13 GMT+03:00 Laszlo Ersek : > On 02/14/17 23:06, Nikolay Bodunov wrote: > > Thank you for the suggestions. > > > > I tried to use them: > > > >> (1) Please always terminate the debug message with a newline ("\n") > > Done. No changes. Of course, I usually do it, but in that case all I > > needed was to have any string on output. Sorry for bad programming styl= e. > > > >> (2) Please use DEBUG_ERROR as the symbolic constant for the error mask > > Done. I think you meant in DEBUG() macros. No changes. Question about > > style, too. > > > >> (3) DEBUG output from OVMF is by default not written to the serial por= t > > and > >> add -D DEBUG_ON_SERIAL_PORT > > Done. Recompiled OVMF with that option. I have now file "debug.log" > > 74415 bytes size that contains everything, include EFI Shell output, bu= t > > except my debug messages > > > > BTW, QEMU option "-debugcon file:debug.log -global > > isa-debugcon.iobase=3D0x402", recommended in OVMF README, did nothing - > > "debug.log was empty. > > I think you have it mixed up a little. The README covers this, but it > might not be very approachable. > > So: if you do *not* specify -D DEBUG_ON_SERIAL_PORT when you build OVMF, > then the debug messages will go to the QEMU debug port. And, if you want > to capture the QEMU debug port in a file, then you should pass > "-debugcon file:debug.log -global isa-debugcon.iobase=3D0x402" on the QEM= U > command line. > > Conversely, if you *do* specify -D DEBUG_ON_SERIAL_PORT when building > OVMF, then debug messages will go to the emulated serial port (and > they'll be intermixed with any serial terminal output, which is why this > setting is not the default). In this case, the -debugcon etc. settings > are useless, because the QEMU debug port is not used. > > > > > Based on results, I suppose that the problem is not on OVMF side. > > Hope you propose something else to try. Maybe I got something in a wron= g > > way. > > Are you sure that when you build your module, it links against the right > DebugLib instance? > > If you pass -D DEBUG_ON_SERIAL_PORT when you build OVMF, that switches > the library class resolution for DebugLib from the default > > DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/ > PlatformDebugLibIoPort.inf > > to > > DebugLib|MdePkg/Library/BaseDebugLibSerialPort/ > BaseDebugLibSerialPort.inf > > for all module types. However, for this library class resolution to take > effect for your own module as well, you should either add your module > directly to OvmfPkg*.dsc, or else implement the exact same library > resolution for your module (in the external DSC file where your module > is listed). Library instances are statically linked into driver and > application modules in edk2. > > In other words, if you *separately* build your driver or application > module with a DebugLib class resolution that points to, say, the > > MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf > > library instance, then you won't see any DEBUG output whatsoever, > regardless of how you build OVMF (*separately* again), and how you > configure QEMU. At that point, a "null" DebugLib instance will have been > statically linked into your driver or application, and it will produce > no output. > > Thanks > Laszlo > > > > > Nikolay > > > > 2017-02-14 21:28 GMT+03:00 Kinney, Michael D > >: > > > > If you prefer debug messages on a serial port, you can > > add -D DEBUG_ON_SERIAL_PORT > > > > Mike > > > > > -----Original Message----- > > > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org > > ] On Behalf Of Laszlo Ersek > > > Sent: Tuesday, February 14, 2017 10:17 AM > > > To: Nikolay Bodunov > >; edk2-devel@ml01.01.org > > > > > Subject: Re: [edk2] DEBUG() macros in DXE driver: can=E2=80=99t m= ake it > > work in QEMU > > > > > > Hi Nikolay, > > > > > > On 02/14/17 18:55, Nikolay Bodunov wrote: > > > > Hello > > > > > > > > > > > > I compiled DXE Driver, in DEBUG_GCC49 mode, but I can=E2=80=99t= print > > any debug > > > > message. > > > > DEBUG((-1, =E2=80=9CPrint test=E2=80=9D)) does nothing. Exact= ly as > > > > DebugPrint(EFI_D_ERROR, =E2=80=9CPrint Test); > > > > > > (1) Please always terminate the debug message with a newline > > ("\n") once > > > you are done with it. (It's okay to format a single message with > > several > > > DEBUG calls of course, and terminate only the last DEBUG with a > > newline.) > > > > > > (2) Please use DEBUG_ERROR as the symbolic constant for the error > > mask. > > > > > > > > > > > However, I see =E2=80=9CPrint Test=E2=80=9D string in my *.efi = binary. > > > > I use QEMU + OMVF (OVMF was also recompliled in DEBUG_GCC49 > > mode, to be > > > > sure). Serial port output is redirected to a file: > > > > qemu-system-x86_64 -L . --bios /=E2=80=A6/FV/OVMF.fd -hda hdd.i= mg -serial > > > > file:./serial_file > > > > > > (3) DEBUG output from OVMF is by default not written to the seria= l > > port, > > > it is written to the QEMU debug port. Please consult > > OvmfPkg/README for > > > specifics, namely under "Capturing OVMF debug messages on qemu". > > > > > > Hope this helps, > > > Laszlo > > > > > > > > > > > All I see in output file is EFI shell output messages, include > > one that my > > > > driver was succesfully loaded. But no messages from DEBUG(). > > > > > > > > > > > > My conditions: > > > > > > > > MODULE_TYPE =3D DXE_DRIVER > > > > > > > > > > > > Debug Print Library: > > > > > > > > > > DebugLib|MdePkg/Library/BaseDebugLibSerialPort/ > BaseDebugLibSerialPort.inf > > > > > > > > (BaseDebugLibNull.inf is commented, of course) > > > > > > > > > > > > DebugPrintEnabled() returns TRUE > > > > > > > > > > > > I also tried to set some key options manually in MdeModulePkg.d= sc > > > > afterwards, but result didn=E2=80=99t change: > > > > > > > > > > > > [Components] > > > > > > > > > > > > MdeModulePkg/CrScreenshotDxe/CrScreenshotDxe.inf { > > > > > > > > > > > > > > > > > > > > > > > > > > gEfiMdePkgTokenSpaceGuid.gEfiMdePkgTokenSpaceGuid. > PcdDebugPrintErrorLevel|0x07 > > > > > > > > gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2F > > > > > > > > gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel| > 0x80000042 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > DebugLib|MdePkg/Library/BaseDebugLibSerialPort/ > BaseDebugLibSerialPort.inf > > > > > > > > > > > > > > > > > > > > GCC:*_*_*_CC_FLAGS =3D -UMDEPKG_NDEBUG > > > > > > > > } > > > > > > > > > > > > Code (I used it as a base): > > https://github.com/LongSoft/CrScreenshotDxe > > > > > > > > > > Where I got wrong and what else could I try to make it work? > > > > > > > > > > _______________________________________________ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > > > > > > > > -- > > With best regards, > > Nikolay Bodunov > > --=20 With best regards, Nikolay Bodunov