From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=209.132.183.28; helo=mx1.redhat.com; envelope-from=lersek@redhat.com; receiver=edk2-devel@lists.01.org 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 0A2EF223CCEE8 for ; Thu, 1 Feb 2018 08:18:23 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE72078244; Thu, 1 Feb 2018 16:24:00 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-121-206.rdu2.redhat.com [10.10.121.206]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3F97F5D9C7; Thu, 1 Feb 2018 16:24:00 +0000 (UTC) To: krishnaLee , edk2-devel@lists.01.org References: <20478935.ac13.16150c3aa05.Coremail.sssky307@163.com> From: Laszlo Ersek Message-ID: Date: Thu, 1 Feb 2018 17:23:59 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20478935.ac13.16150c3aa05.Coremail.sssky307@163.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 01 Feb 2018 16:24:00 +0000 (UTC) Subject: Re: Why the DEBUG can't output the full string? X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 16:18:24 -0000 Content-Type: text/plain; charset=UTF-8 Content-Language: en-US Content-Transfer-Encoding: 8bit On 02/01/18 10:47, krishnaLee wrote: > Hi, > For example,the follow code: > //-code-start > ConfigRequestHdr = HiiConstructConfigHdr (&mBlankDrvFormSetGuid, VariableName, PrivateData1->DriverHandle[0]); > Size = (StrLen (ConfigRequestHdr) + 32 + 1) * sizeof (CHAR16); > ConfigRequest = AllocateZeroPool (Size); > ASSERT (ConfigRequest != NULL); > AllocatedRequest = TRUE; > UnicodeSPrint (ConfigRequest, Size, L"%s&OFFSET=0&WIDTH=%016LX", ConfigRequestHdr, (UINT64)BufferSize); > FreePool (ConfigRequestHdr); > //-code-end > > > I add a debug message at the end of code: > DEBUG((EFI_D_INFO,"construct-ConfigRequest:%s",ConfigRequest)); > DEBUG((EFI_D_INFO,"\r\n")); > > > and the output will be: > construct-ConfigRequest:GUID=db3b005aa15068459170ebd49e16c47c&NAME=00420044004d0079004900660072004e00560044006100740061&PATH=01041400db3b005aa15068459170ebd49e16c47c7fff0400&OFFSET=0&WIDTH=0000000000 > > > If I add another debug message at the end of code: > DEBUG((EFI_D_INFO,"construct-ConfigRequest:")); > for(UINTN i=0;i { > DEBUG((EFI_D_INFO,"%c",ConfigRequest[i])); > } > DEBUG((EFI_D_INFO,"\r\n")); > > > and the output will be: > construct-ConfigRequest:GUID=db3b005aa15068459170ebd49e16c47c&NAME=00420044004d0079004900660072004e00560044006100740061&PATH=01041400db3b005aa15068459170ebd49e16c47c7fff0400&OFFSET=0&WIDTH=0000000000000052 pa?pr╝ <_<_  > > > my platform: > win10_x64 + udk2017 + vs2015 Umm, I'm a bit confused by your query. * First, most DebugLib instances have an internal buffer with fixed size (for the DebugPrint() function). If you try to log longer messages, they will be truncated. For example, in "MdePkg/Library/BaseDebugLibSerialPort/DebugLib.c", there is: #define MAX_DEBUG_MESSAGE_LENGTH 0x100 (I don't really understand your situation because the first debug message that you pasted does *not* look truncated.) * Second, regarding the trailing garbage. You set "Size" to the number of *bytes* required for a NUL-terminated CHAR16 config request string, plus 32 CHAR16 objects. This is then correctly passed to both AllocateZeroPool() and UnicodeSPrint(). However, in the loop where you print individual CHAR16 objects, you also count up to the number of *bytes* -- that's incorrect, the limit should be the number of CHAR16 objects (or the NUL-terminator, of course). Laszlo