Re: [edk2] Overhead MdePkg e MdeModulePkg

Subject: Re: [edk2] Overhead MdePkg e MdeModulePkg

From: Rafael Machado <rafaelrodrigues.machado@gmail.com>

To: edk2-devel@lists.sourceforge.net

Date: 2012-06-06 22:51:33

Thanks fr the tip about the build process. Doing what you suggested, here is the log:

Platform Summary

Platform Name: MdeModule

Platform DSC Path: c:\udk2010sr1\MdeModulePkg\MdeModulePkg.dsc

Architectures: X64

Tool Chain: MYTOOLS

Target: RELEASE

Output Path: c:\udk2010sr1\Build\MdeModule

Build Environment: Windows-XP-5.1.2600

Build Duration: 00:00:52

Report Content: PCD, LIBRARY, BUILD_FLAGS, DEPEX, FLASH, FIXED_ADDRESS

>======================================================================================================================<

Module Summary

Module Name: ErrorCode

Module INF Path: brancheFItFase2\ErrorCodeProtocolBootableInstall\ErrorCodeProtocol.inf

File GUID: 6987936E-ED34-44db-AE97-1FA5E4ED2116

Size: 0x2540 (9.31K)

Build Time Stamp: 1969-12-31 22:00:00

Driver Type: 0x7 (DRIVER)

========================================================================================================================

>----------------------------------------------------------------------------------------------------------------------<

PCD

------------------------------------------------------------------------------------------------------------------------

gEfiMdePkgTokenSpaceGuid

PcdVerifyNodeInList : FLAG (BOOLEAN) = 0

PcdDebugPrintErrorLevel : FIXED (UINT32) = 0x80000000

PcdMaximumLinkedListLength : FIXED (UINT32) = 1000000

PcdMaximumAsciiStringLength : FIXED (UINT32) = 1000000

PcdMaximumUnicodeStringLength : FIXED (UINT32) = 1000000

PcdDebugClearMemoryValue : FIXED (UINT8) = 0xAF

*P PcdDebugPropertyMask : FIXED (UINT8) = 0x0f

DEC DEFAULT = 0

<---------------------------------------------------------------------------------------------------------------------->

>----------------------------------------------------------------------------------------------------------------------<

Library

------------------------------------------------------------------------------------------------------------------------

c:\udk2010sr1\MdePkg\Library\BaseDebugPrintErrorLevelLib\BaseDebugPrintErrorLevelLib.inf

{DebugPrintErrorLevelLib}

c:\udk2010sr1\MdePkg\Library\BasePrintLib\BasePrintLib.inf

{PrintLib}

c:\udk2010sr1\MdePkg\Library\BaseMemoryLib\BaseMemoryLib.inf

{BaseMemoryLib}

c:\udk2010sr1\MdePkg\Library\BasePcdLibNull\BasePcdLibNull.inf

{PcdLib}

c:\udk2010sr1\MdePkg\Library\BaseLib\BaseLib.inf

{BaseLib}

c:\udk2010sr1\MdePkg\Library\UefiDebugLibConOut\UefiDebugLibConOut.inf

{DebugLib}

c:\udk2010sr1\MdePkg\Library\UefiBootServicesTableLib\UefiBootServicesTableLib.inf

{UefiBootServicesTableLib: C = UefiBootServicesTableLibConstructor}

c:\udk2010sr1\MdePkg\Library\UefiDriverEntryPoint\UefiDriverEntryPoint.inf

{UefiDriverEntryPoint: Depex = gEfiBdsArchProtocolGuid AND gEfiCpuArchProtocolGuid AND gEfiMetronomeArchProtocolGuid AND gEfiMonotonicCounterArchProtocolGuid AND gEfiRealTimeClockArchProtocolGuid AND gEfiResetArchProtocolGuid AND gEfiRuntimeArchProtocolGuid AND gEfiSecurityArchProtocolGuid AND gEfiTimerArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid AND gEfiVariableArchProtocolGuid AND gEfiWatchdogTimerArchProtocolGuid }

<---------------------------------------------------------------------------------------------------------------------->

>----------------------------------------------------------------------------------------------------------------------<

Dependency Expression (DEPEX) from INF

(gEfiBdsArchProtocolGuid AND gEfiCpuArchProtocolGuid AND gEfiMetronomeArchProtocolGuid AND
gEfiMonotonicCounterArchProtocolGuid AND gEfiRealTimeClockArchProtocolGuid AND gEfiResetArchProtocolGuid AND
gEfiRuntimeArchProtocolGuid AND gEfiSecurityArchProtocolGuid AND gEfiTimerArchProtocolGuid AND
gEfiVariableWriteArchProtocolGuid AND gEfiVariableArchProtocolGuid AND gEfiWatchdogTimerArchProtocolGuid)

------------------------------------------------------------------------------------------------------------------------

From Module INF: (None)

From Library INF: (gEfiBdsArchProtocolGuid AND gEfiCpuArchProtocolGuid AND gEfiMetronomeArchProtocolGuid AND
gEfiMonotonicCounterArchProtocolGuid AND gEfiRealTimeClockArchProtocolGuid AND gEfiResetArchProtocolGuid AND
gEfiRuntimeArchProtocolGuid AND gEfiSecurityArchProtocolGuid AND gEfiTimerArchProtocolGuid AND
gEfiVariableWriteArchProtocolGuid AND gEfiVariableArchProtocolGuid AND gEfiWatchdogTimerArchProtocolGuid)

<---------------------------------------------------------------------------------------------------------------------->

>----------------------------------------------------------------------------------------------------------------------<

Build Flags

Tool Chain Tag: MYTOOLS

------------------------------------------------------------------------------------------------------------------------

SLINK_FLAGS = /nologo /LTCG

------------------------------------------------------------------------------------------------------------------------

DLINK_FLAGS = /NOLOGO /NODEFAULTLIB /IGNORE:4001 /IGNORE:4254 /OPT:REF /OPT:ICF=10 /MAP /ALIGN:32 /SECTION:.xdata,D
/SECTION:.pdata,D /Machine:X64 /LTCG /DLL /ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /SAFESEH:NO
/BASE:0 /DRIVER /MERGE:.data=.text /MERGE:.rdata=.text

------------------------------------------------------------------------------------------------------------------------

CC_FLAGS = /nologo /c /WX /GS- /W4 /Gs32768 /Gy /D UNICODE /O1ib2 /GL /FIAutoGen.h /EHs-c- /GR- /GF

<---------------------------------------------------------------------------------------------------------------------->

<======================================================================================================================>


My doubt is, as I told some e-mails ago, I don't compiling the sample as release, and even with this, the following libs are still at the binary:

c:\udk2010sr1\MdePkg\Library\UefiDebugLibConOut\UefiDebugLibConOut.inf
{DebugLib}
c:\udk2010sr1\MdePkg\Library\BaseDebugPrintErrorLevelLib\BaseDebugPrintErrorLevelLib.inf
{DebugPrintErrorLevelLib}

Is there a way to remove this from my build ? To reduce the binary ?

Thanks for the Help
Rafael

2012/6/6 Andrew Fish <afish@apple.com>

On Jun 6, 2012, at 7:56 AM, Rafael Machado wrote:

Just to complete my checks.

Any idea about why do I have this at the map:

0001:00000388 ??_C@_0L@DJKNJKHM@TFTP?5Error?$AA@ 00000000000005e8 BasePrintLib:PrintLibInternal.obj
0001:00000398 ??_C@_0L@LKIFCMNO@ICMP?5Error?$AA@ 00000000000005f8 BasePrintLib:PrintLibInternal.obj

I don't use nothing related to FTP or ICMP.

You may want to search the code base, it is a good way to learn stuff.....

Print supports a format string of %r that prints out names for EFI return codes.

GLOBAL_REMOVE_IF_UNREFERENCED CONST CHAR8 *mStatusString[] = {
  "Success",                      //  RETURN_SUCCESS                = 0
  "Warning Unknown Glyph",        //  RETURN_WARN_UNKNOWN_GLYPH     = 1
  "Warning Delete Failure",       //  RETURN_WARN_DELETE_FAILURE    = 2
  "Warning Write Failure",        //  RETURN_WARN_WRITE_FAILURE     = 3
  "Warning Buffer Too Small",     //  RETURN_WARN_BUFFER_TOO_SMALL  = 4
  "Load Error",                   //  RETURN_LOAD_ERROR             = 1  | MAX_BIT
  "Invalid Parameter",            //  RETURN_INVALID_PARAMETER      = 2  | MAX_BIT
  "Unsupported",                  //  RETURN_UNSUPPORTED            = 3  | MAX_BIT
  "Bad Buffer Size",              //  RETURN_BAD_BUFFER_SIZE        = 4  | MAX_BIT
  "Buffer Too Small",             //  RETURN_BUFFER_TOO_SMALL,      = 5  | MAX_BIT
  "Not Ready",                    //  RETURN_NOT_READY              = 6  | MAX_BIT
  "Device Error",                 //  RETURN_DEVICE_ERROR           = 7  | MAX_BIT
  "Write Protected",              //  RETURN_WRITE_PROTECTED        = 8  | MAX_BIT
  "Out of Resources",             //  RETURN_OUT_OF_RESOURCES       = 9  | MAX_BIT
  "Volume Corrupt",               //  RETURN_VOLUME_CORRUPTED       = 10 | MAX_BIT
  "Volume Full",                  //  RETURN_VOLUME_FULL            = 11 | MAX_BIT
  "No Media",                     //  RETURN_NO_MEDIA               = 12 | MAX_BIT
  "Media changed",                //  RETURN_MEDIA_CHANGED          = 13 | MAX_BIT
  "Not Found",                    //  RETURN_NOT_FOUND              = 14 | MAX_BIT
  "Access Denied",                //  RETURN_ACCESS_DENIED          = 15 | MAX_BIT
  "No Response",                  //  RETURN_NO_RESPONSE            = 16 | MAX_BIT
  "No mapping",                   //  RETURN_NO_MAPPING             = 17 | MAX_BIT
  "Time out",                     //  RETURN_TIMEOUT                = 18 | MAX_BIT
  "Not started",                  //  RETURN_NOT_STARTED            = 19 | MAX_BIT
  "Already started",              //  RETURN_ALREADY_STARTED        = 20 | MAX_BIT
  "Aborted",                      //  RETURN_ABORTED                = 21 | MAX_BIT
  "ICMP Error",                   //  RETURN_ICMP_ERROR             = 22 | MAX_BIT
  "TFTP Error",                   //  RETURN_TFTP_ERROR             = 23 | MAX_BIT
  "Protocol Error"                //  RETURN_PROTOCOL_ERROR         = 24 | MAX_BIT
};
So this is part of the BasePrintLib, and if you notice the map file tells you this.

Thanks
Rafael

2012/6/6 Rafael Machado <rafaelrodrigues.machado@gmail.com>
I'm nor using any DebugLib Instance.
I don't use any debug function at this sample application, but at Autogen.c I have:

#include <Uefi.h>
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Library/UefiDriverEntryPoint.h>

Here is my .dsc:

[LibraryClasses]
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
BaseLib|MdePkg/Library/BaseLib/BaseLib.inf

# this was added as suggested at the previous tip, but no success
DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf

And I still have some unnespected thing at the .map for example:

0001:00000238 ??_C@_0BD@OMEPNDED@ASSERT?5?$CFa?$CI?$CFd?$CJ?3?5?$CFa?6?$AA@ 0000000000000498 UefiDebugLibConOut:DebugLib.obj

0001:00000378 ??_C@_0P@NCJHBCLM@Protocol?5Error?$AA@ 00000000000005d8 BasePrintLib:PrintLibInternal.obj
0001:00000388 ??_C@_0L@DJKNJKHM@TFTP?5Error?$AA@ 00000000000005e8 BasePrintLib:PrintLibInternal.obj
0001:00000398 ??_C@_0L@LKIFCMNO@ICMP?5Error?$AA@ 00000000000005f8 BasePrintLib:PrintLibInternal.obj

Any idea ?

Your are doing something wrong and only including fragments of stuff in the email, so we can't tell what it is.

The log file from the build will show you what libraries are included, and why.

Please remember the libraries have a tree structure. You driver/application is coded to use library class A, the DSC file maps library class A, to library A. Library A uses library class B, and the DSC maps library class B, to library B. And library B can require library class C.... As you can see this forms a tree, and the structure of the tree is rooted in what your application/driver depends on, but the DSC file controls how the tree of libraries gets filled out. This is why the build command has the log file, as otherwise it is hard to figure out what happened for a given build.

Thanks everyone



2012/6/5 Kinney, Michael D <michael.d.kinney@intel.com>

What DebugLib instance are you using?

The ASSERT() and DEBUG() macros use the API you reference. If you use the DebugLibNull instance or you use D MDEPKG_NDEBUG, then the DEBUG() and ASSERT() macros will be disabled and that API should not appear in the final image anymore.

Best regards,

Mike

From: Rafael Machado [mailto:rafaelrodrigues.machado@gmail.com]
Sent: Tuesday, June 05, 2012 12:41 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Overhead MdePkg e MdeModulePkg

I'm using the same compiler with the same parameters.

I've checked the .map files that both projects generated. It's strange because at the Autogen.c I have this:

VOID

EFIAPI

ProcessLibraryConstructorList (

IN EFI_HANDLE ImageHandle,

IN EFI_SYSTEM_TABLE *SystemTable

)

{

EFI_STATUS Status;

Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);

ASSERT_EFI_ERROR (Status);

}

And on the .map I have several strange things.

I don't have any print at my code, but at .map I have several lines with something similar to these ones:

0001:00000f3c UnicodeVSPrintAsciiFormat 000000000000119c f BasePrintLib:PrintLib.obj

or

0001:000004a8 ??_C@_0BB@EGELJFOB@Buffer?5Too?5Small?$AA@ 0000000000000708 BasePrintLib:PrintLibInternal.obj

Seems that just by adding "BaseLib|MdePkg/Library/BaseLib/BaseLib.inf" at my .dsc for some reason at my .map these "calls" are added, even not having any call to Print at my code.

Is there a way to hemove these "calls" ?

Thanks and Regards

Rafael

2012/6/5 Andrew Fish <afish@apple.com>

On Jun 5, 2012, at 6:53 AM, Rafael Machado wrote:



Now I tink I understand how it works.

But I have another doubt now.

I did an sample sample that just use:

[LibraryClasses]

UefiApplicationEntryPoint

BaseLib

On my Autogen.c I have:

VOID

EFIAPI

ProcessLibraryConstructorList (

IN EFI_HANDLE ImageHandle,

IN EFI_SYSTEM_TABLE *SystemTable

)

{

EFI_STATUS Status;

Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);

ASSERT_EFI_ERROR (Status);

}

This is what I would expect since the UefiApplicationEntryPoint library has the following in it's .inf file:

[LibraryClasses]
 UefiBootServicesTableLib
 DebugLib
 BaseLib



When I compile this sample I have an .efi 10Kb size.

On another sample that I did with the same code but coping the .c files I used from the UDK to my project (I know this is totally wrong, but it's just a test), I have an .efi 3Kb size.

Is there a way to reduce this size ?

You have not mentioned what compiler you are using? Are you using the same compiler flags in both cases. Is one case no optimization for debug, and the other case size optimized?

Size optimization is tricky. You generally have to look at the log file, the map file, the compiler flags, and the source to see what is going on. Also Visual Studio and clang seem to do better than gcc.



This sample is not an application, it's was some functions that are called by an Apllication.

At my .inf I use this:

MODULE_TYPE = UEFI_APPLICATION

Since it's not an application, if I change this to other type, will my compiled module size be reduced ?

The only build different for an application and a driver is the image type that gets placed into the PE/COFF header, and this has no impact on size.

The only use of the EFI image type in the PE/COFF header is used to decide what kind of memory to allocate for the image. Also the memory allocated for an application gets freed when the application returns, while a driver does not get freed as it is assumed the driver has published interfaces for others to use.

So if is not an application it is bad to use UEFI_APPLICATION as the module type.



Thanks

Rafael

2012/6/4 Andrew Fish <afish@apple.com>

On Jun 4, 2012, at 11:09 AM, Rafael Machado wrote:



Andrew

I've done what you told and have this:

"

c:\udk2010sr1\MdePkg\Library\UefiLib\UefiLib.inf

{UefiLib: C = UefiLibConstructor}

"

Just to be sure that I understand correctly.

Does this means that Just the FunctionUefiLibConstructor, fromUefiLib.c that was defined atUefiLib.inf was added to by final binary ?

Yes. If you look in the output directory you will see an AutoGen.c and AutoGen.h file. The AutoGen.c file wii contain a function calledProcessLibraryConstructorList() that represents the library constructors that are getting called prior to the entry point of you application. In the EDK the entry point in the INF file was the entry point to the PE/COFF image, in the edk2 the entry point to the PE/COFF image is the function __ModuleEntryPoint() that lives in a library, and this library calls the library constructors for you, and the entry point of the module by callout well known functions constructed in AutoGen.c. The AutoGen.h files are the platforms response, from .DSC file, to your applications .inf file requests.

So basically anything in the AutoGen.* files was requested by you, or a library instance you chose to be in the image.

Functions can call other functions and this causes these functions to be included too.



Thanks and Regards

Rafael

2012/6/4 Andrew Fish <afish@apple.com>

Rafael,

By overhead I assume you mean size of the executable EFI image? What compiler are you using?

Look at the .map file and see if you see items in there that you don't think should be there. Please remember that by specifying library classes in your INF file the .DSC picks which libraries get used, and changing which libraries get used will change the size of the image. You can get an idea of what got pulled into your executable base on .DSC file setting by adding -y Log.txt to your build command.

Andrew Fish






On Jun 4, 2012, at 10:32 AM, Rafael Machado wrote:

> Hi everyone
>
> I'm having a little problem with on UEFI application.
> The application was developed using MdePkg and MdeModulePkg.
> The problem is that when I compile and generate the .efi I have an overhead of some kb.
>
> I did a test here copying the .c from UDK2010SR1 that my application uses to my application's directory, and I saw that the overhead is smaller.
> Since copy the .c files to my project is really strange, is ther a way to 'eliminate' the overhead when using MdePkg and MdeModulePkg ?
>
> By the way, could some one explain me why does this overhead exists ? It seams to be when some variables are initialized at MdePkg and MdeModulePkg
>
> Thanks and Regards
> Rafael R. Machado

> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel