Re: [edk2] [tianocore/edk2] Stdlib: Add calling convention to completion callbacks (#123)
Marco, The tools definitions for the newer versions of GCC must not be setting the option to force the EFIAPI calling conventions. We relied upon the compiler option for StdLib in order to enhance portability for POSIX sources. I’ll research what the tools definitions are for the newer GCC versions then readdress your patches. Thank you, Daryl McDaniel From: Marco Guerri [mailto:marco.guerri@fastmail.com] Sent: Thursday, January 18, 2018 9:28 AM To: Daryl McDaniel (EDK2 Lists) ; edk2-devel@lists.01.org Subject: Re: [tianocore/edk2] Stdlib: Add calling convention to completion callbacks (#123) Hi Daryl, First, sorry for not having RTFM and submitting the patch via github. I was planning to read your workflow during the weekend and re-submit via the mailing list. Second, I am using gcc. I tried gcc 4.8 and 5.2 and with both, my applications using Stdlib badly hang. I dug a bit and discovered that the signatures of the completion callbacks are missing EFIAPI, so necessarily under Unix systems they are using the wrong ABI. When the functions arguments are pointers, the machine ends up in a triple fault I guess (I can clearly see that the first two integer parameters are fetched from %rdi and %rsi, which is the SysV ABI). I was a bit surprised to see this bug, as the buildscripts are pretty comprehensive in terms of compilers support. Does this make sense to you? Cheers, Marco -- Marco Guerri marco.guerri@fastmail.com <mailto:marco.guerri@fastmail.com> On Thu, Jan 18, 2018, at 11:12 AM, Daryl McDaniel (EDK2 Lists) wrote: Marco, Thank you for your submission. Can you please tell me which compiler you are using? Thank you, Daryl McDaniel From: Marco Guerri [mailto:notificati...@github.com] Sent: Wednesday, January 17, 2018 7:22 AM To: tianocore/edk2 mailto:e...@noreply.github.com> > Cc: Subscribed mailto:subscri...@noreply.github.com> > Subject: [tianocore/edk2] Stdlib: Add calling convention to completion callbacks (#123) When compiling in Unix environments, the ABI defaults to SysV. Callbacks are invoked directly by the system firmware so they must necessarily use MS ABI. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marco Guerri marco.guerri@fastmail.com <mailto:marco.guerri@fastmail.com> _ You can view, comment on, or merge this pull request online at: https://github.com/tianocore/edk2/pull/123 Commit Summary * Stdlib: Add calling convention to completion callbacks File Changes * M StdLib/EfiSocketLib/Ip4.c <https://github.com/tianocore/edk2/pull/123/files#diff-0> (10) * M StdLib/EfiSocketLib/Socket.h <https://github.com/tianocore/edk2/pull/123/files#diff-1> (24) * M StdLib/EfiSocketLib/Tcp4.c <https://github.com/tianocore/edk2/pull/123/files#diff-2> (11) * M StdLib/EfiSocketLib/Tcp6.c <https://github.com/tianocore/edk2/pull/123/files#diff-3> (3) * M StdLib/EfiSocketLib/Udp4.c <https://github.com/tianocore/edk2/pull/123/files#diff-4> (30) * M StdLib/EfiSocketLib/Udp6.c <https://github.com/tianocore/edk2/pull/123/files#diff-5> (20) Patch Links: * https://github.com/tianocore/edk2/pull/123.patch * https://github.com/tianocore/edk2/pull/123.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/tianocore/edk2/pull/123> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AM0XkaIxBOrC6Kacm-Vqq6z4tgQFar04ks5tLhAHgaJpZM4RhgXz> . <https://www.fastmailusercontent.com/proxy/f37b3dc5910ce7528e4a533ff667a08359273c5576df3e81fc020a90540143e0/8647470737a3f2f2769647865726e236f6d6f2e6f64796669636164796f6e637f226561636f6e6f214d40385b666c41393a757367466769555b475a6369663e4948357d645f41616b6375347c48614847616a407a5d44325867685a7e2769666/AM0XkfL19zucGfgYUKWjci6NI8umTOaaks5tLhAHgaJpZM4RhgXz.gif> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [tianocore/edk2] Stdlib: Add calling convention to completion callbacks (#123)
Marco, Thank you for your submission. Can you please tell me which compiler you are using? Thank you, Daryl McDaniel From: Marco Guerri [mailto:notificati...@github.com] Sent: Wednesday, January 17, 2018 7:22 AM To: tianocore/edk2 Cc: Subscribed Subject: [tianocore/edk2] Stdlib: Add calling convention to completion callbacks (#123) When compiling in Unix environments, the ABI defaults to SysV. Callbacks are invoked directly by the system firmware so they must necessarily use MS ABI. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Marco Guerri marco.guerri@fastmail.com <mailto:marco.guerri@fastmail.com> _ You can view, comment on, or merge this pull request online at: https://github.com/tianocore/edk2/pull/123 Commit Summary * Stdlib: Add calling convention to completion callbacks File Changes * M StdLib/EfiSocketLib/Ip4.c <https://github.com/tianocore/edk2/pull/123/files#diff-0> (10) * M StdLib/EfiSocketLib/Socket.h <https://github.com/tianocore/edk2/pull/123/files#diff-1> (24) * M StdLib/EfiSocketLib/Tcp4.c <https://github.com/tianocore/edk2/pull/123/files#diff-2> (11) * M StdLib/EfiSocketLib/Tcp6.c <https://github.com/tianocore/edk2/pull/123/files#diff-3> (3) * M StdLib/EfiSocketLib/Udp4.c <https://github.com/tianocore/edk2/pull/123/files#diff-4> (30) * M StdLib/EfiSocketLib/Udp6.c <https://github.com/tianocore/edk2/pull/123/files#diff-5> (20) Patch Links: * https://github.com/tianocore/edk2/pull/123.patch * https://github.com/tianocore/edk2/pull/123.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/tianocore/edk2/pull/123> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AM0XkaIxBOrC6Kacm-Vqq6z4tgQFar04ks5tLhAHgaJpZM4RhgXz> . <https://github.com/notifications/beacon/AM0XkfL19zucGfgYUKWjci6NI8umTOaaks5tLhAHgaJpZM4RhgXz.gif> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] AppPkg/WebServer: Fix build failure.
Looks good.
Reviewed-by: Daryl McDaniel
> -Original Message-
> From: Eric Dong [mailto:eric.d...@intel.com]
> Sent: Wednesday, September 13, 2017 3:10 AM
> To: edk2-devel@lists.01.org
> Cc: Daryl McDaniel ; Jaben Carsey
> ; Ruiyu Ni
> Subject: [Patch] AppPkg/WebServer: Fix build failure.
>
> Fix build failure caused by UefiCpuPkg/MtrrLib removes deprecated macros.
>
> Cc: Daryl McDaniel
> Cc: Jaben Carsey
> Cc: Ruiyu Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong
> ---
> AppPkg/Applications/Sockets/WebServer/Mtrr.c | 31
> +++
> AppPkg/Applications/Sockets/WebServer/WebServer.h | 1 +
> 2 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/AppPkg/Applications/Sockets/WebServer/Mtrr.c
> b/AppPkg/Applications/Sockets/WebServer/Mtrr.c
> index 92f90b0..54356bd 100644
> --- a/AppPkg/Applications/Sockets/WebServer/Mtrr.c
> +++ b/AppPkg/Applications/Sockets/WebServer/Mtrr.c
> @@ -146,12 +146,12 @@ MemoryTypeRegistersPage (
> {
>UINT64 Addr;
>BOOLEAN bValid;
> - UINT64 Capabilities;
> + MSR_IA32_MTRRCAP_REGISTER Capabilities;
>UINTN Count;
> - UINT64 DefType;
> + MSR_IA32_MTRR_DEF_TYPE_REGISTER DefType;
>UINTN Index;
>UINT64 Mask;
> - UINT64 MaxMtrrs;
> +
>CONST UINT64 mFixedAddresses [( 8 * MTRR_NUMBER_OF_FIXED_MTRR ) + 1 ] = {
> 0ULL,
> 0x1ULL,
> @@ -302,8 +302,8 @@ MemoryTypeRegistersPage (
>//
>// Get the capabilities
>//
> - Capabilities = AsmReadMsr64 ( MTRR_LIB_IA32_MTRR_CAP );
> - DefType = AsmReadMsr64 ( MTRR_LIB_IA32_MTRR_DEF_TYPE );
> + Capabilities.Uint64 = AsmReadMsr64 ( MSR_IA32_MTRRCAP );
> + DefType.Uint64 = AsmReadMsr64 ( MSR_IA32_MTRR_DEF_TYPE );
>
>//
>// Display the capabilities
> @@ -316,7 +316,7 @@ MemoryTypeRegistersPage (
>}
>Status = HttpSendHexValue ( SocketFD,
>pPort,
> - Capabilities );
> + Capabilities.Uint64 );
>if ( EFI_ERROR ( Status )) {
> break;
>}
> @@ -338,7 +338,7 @@ MemoryTypeRegistersPage (
>}
>Status = HttpSendHexValue ( SocketFD,
>pPort,
> - DefType );
> + DefType.Uint64);
>if ( EFI_ERROR ( Status )) {
> break;
>}
> @@ -350,7 +350,7 @@ MemoryTypeRegistersPage (
>}
>Status = HttpSendAnsiString ( SocketFD,
> pPort,
> -( 0 != ( DefType &
> MTRR_LIB_CACHE_MTRR_ENABLED ))
> +( 0 != DefType.Bits.E )
> ? "Enabled"
> : "Disabled" );
>if ( EFI_ERROR ( Status )) {
> @@ -364,7 +364,7 @@ MemoryTypeRegistersPage (
>}
>Status = HttpSendAnsiString ( SocketFD,
> pPort,
> -( 0 != ( DefType &
> MTRR_LIB_CACHE_FIXED_MTRR_ENABLED ))
> +( 0 != DefType.Bits.FE )
> ? "Enabled"
> : "Disabled" );
>if ( EFI_ERROR ( Status )) {
> @@ -376,7 +376,7 @@ MemoryTypeRegistersPage (
>if ( EFI_ERROR ( Status )) {
> break;
>}
> - Type = DefType & 0xff;
> + Type = DefType.Uint64 & 0xff;
>Status = HttpSendAnsiString ( SocketFD,
> pPort,
> ( DIM ( mMemoryType ) > Type )
> @@ -395,7 +395,7 @@ MemoryTypeRegistersPage (
>//
>// Determine if MTRRs are enabled
>//
> - if ( 0 == ( DefType & MTRR_LIB_CACHE_MTRR_ENABLED )) {
> + if ( 0 == DefType.Bits.E ) {
> Status = HttpSendAnsiString ( SocketFD,
>pPort,
>"All memory is uncached!\r\n" );
> @@ -412,8 +412,8 @@ MemoryTypeRegistersPage (
> //
> // Determine if the fixed MTRRs are supported
> //
> -if (( 0 != ( Capabilities & 0x100 ))
> - && ( 0 != ( DefType & MTRR_LIB_CACHE_FIXED_MTRR_ENABLED ))) {
> +if (( 0 != Capabilities.Bits.FIX )
> + && ( 0 != DefType.Bits.FE)) {
>
>//
>// Beginning of table
Re: [edk2] [PATCH 1/1] StdLib/EfiSocketLib: Fix ABI mismatch for 2 event functions
Thomas,
I'll take a look at this.
Have you determined what the impact of changing the signature of the functions
(adding/removing parameters) will be? Can it
adversely affect existing code?
Sincerely,
Daryl McDaniel
> -Original Message-
> From: Palmer, Thomas [mailto:thomas.pal...@hpe.com]
> Sent: Monday, September 11, 2017 12:35 PM
> To: Carsey, Jaben ; edk2-devel@lists.01.org; edk2-
> li...@mc2research.org
> Cc: edk2-li...@mc2research.org; Shifflett, Joseph
> Subject: RE: [PATCH 1/1] StdLib/EfiSocketLib: Fix ABI mismatch for 2 event
> functions
>
> Daryl?
>
> I haven't seen a comment on this patch since 8/10
>
>
> Regards,
>
> Thomas Palmer
>
> "I have only made this letter longer because I have not had the time to make
> it
> shorter" - Blaise Pascal
>
>
> -Original Message-
> From: Carsey, Jaben [mailto:jaben.car...@intel.com]
> Sent: Thursday, August 10, 2017 5:59 PM
> To: Palmer, Thomas ; edk2-devel@lists.01.org
> Cc: edk2-li...@mc2research.org; Shifflett, Joseph
> Subject: RE: [PATCH 1/1] StdLib/EfiSocketLib: Fix ABI mismatch for 2 event
> functions
>
> Looks good to me.
>
> Daryl?
>
> > -Original Message-
> > From: Thomas Palmer [mailto:thomas.pal...@hpe.com]
> > Sent: Thursday, August 10, 2017 3:35 PM
> > To: edk2-devel@lists.01.org
> > Cc: edk2-li...@mc2research.org; Carsey, Jaben
> > ; joseph.shiffl...@hpe.com; Thomas Palmer
> >
> > Subject: [PATCH 1/1] StdLib/EfiSocketLib: Fix ABI mismatch for 2 event
> > functions
> > Importance: High
> >
> > The gBS->CreateEvent expects a EFI_EVENT_NOTIFY function as the third
> > argument. The EFIAPI token is an important component of that
> > prototype. Its absence can cause unexpected issues on DEBUG systems
> > built with GCC due to ABI mismatches.
> >
> > Both EslTcp4ConnectComplete and EslTcp6ConnectComplete did not have
> > the EFIAPI token required of a EFI_EVENT_NOTIFY function. GCC did not
> > catch this because of the explicit EFI_EVENT_NOTIFY cast. By removing
> > the cast, a build error ensues.
> >
> > This patch removes the cast and updates both functions to comply with
> > EFI_EVENT_NOTIFY.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Thomas Palmer
> > ---
> > StdLib/EfiSocketLib/Tcp4.c | 8 ++-- StdLib/EfiSocketLib/Tcp6.c |
> > 8 ++--
> > 2 files changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/StdLib/EfiSocketLib/Tcp4.c b/StdLib/EfiSocketLib/Tcp4.c
> > index 68477fba6e70..8125a8d4f5ad 100644
> > --- a/StdLib/EfiSocketLib/Tcp4.c
> > +++ b/StdLib/EfiSocketLib/Tcp4.c
> > @@ -2,6 +2,7 @@
> >Implement the TCP4 driver support for the socket layer.
> >
> >Copyright (c) 2011 - 2015, Intel Corporation. All rights
> > reserved.
> > + (C) Copyright 2017 Hewlett Packard Enterprise Development LP
> >This program and the accompanying materials are licensed and made
> > available
> >under the terms and conditions of the BSD License which accompanies this
> >distribution. The full text of the license may be found at @@
> > -192,9 +193,10 @@ EslTcp4Accept (
> >
> > **/
> > VOID
> > +EFIAPI
> > EslTcp4ConnectComplete (
> >IN EFI_EVENT Event,
> > - IN ESL_PORT * pPort
> > + IN VOID *Context
> >)
> > {
> >BOOLEAN bRemoveFirstPort;
> > @@ -203,12 +205,14 @@ EslTcp4ConnectComplete (
> >ESL_SOCKET * pSocket;
> >ESL_TCP4_CONTEXT * pTcp4;
> >EFI_STATUS Status;
> > + ESL_PORT * pPort;
> >
> >DBG_ENTER ( );
> >
> >//
> >// Locate the TCP context
> >//
> > + pPort = Context;
> >pSocket = pPort->pSocket;
> >pTcp4 = &pPort->Context.Tcp4;
> >
> > @@ -1288,7 +1292,7 @@ EslTcp4PortAllocate (
> > //
> > Status = gBS->CreateEvent ( EVT_NOTIFY_SIGNAL,
> > TPL_SOCKETS,
> > - (EFI_EVENT_NOTIFY)EslTcp4ConnectComplete,
> > + EslTcp4ConnectComplete,
> > pPort,
> >
> > &pTcp4->ConnectToken.CompletionToken.Event);
> > if ( EFI_ERROR ( Status )) {
> > diff --git a/StdLib/EfiSocketLib/Tcp6.c b/StdLib/EfiSocketLib/Tcp6.c
> > index 0f6d2d6ac93c..9f9c00f6dc57 100644
> > --- a/StdLib/EfiSocketLib/Tcp6.c
> > +++ b/StdLib/EfiSocketLib/Tcp6.c
> > @@ -2,6 +2,7
[edk2] Possible Bug in build tools?
Hello, I've run into a problem with using INF files for specifying binary components. According to the INF specification, v1.26, a specification such as: [Binaries.X64] PE32|DEBUG/X64/MyDbgDriver.efi|DEBUG PE32|RELEASE/X64/MyDriver.efi|RELEASE Should cause "MyDbgDriver.efi" to be included for DEBUG builds, and "MyDriver.efi" to be included for RELEASE builds. What I am seeing is that, given the above specification, "MyDriver" is included for both DEBUG and RELEASE builds. The last entry specified seems to be the one selected, regardless of the target. Am I doing something wrong, or is this really a bug? Daryl McDaniel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] AppPkg: Update email and URL V2.
Reviewed-by: Daryl McDaniel Daryl McDaniel > -Original Message- > From: Jaben Carsey [mailto:jaben.car...@intel.com] > Sent: Tuesday, October 25, 2016 10:06 AM > To: edk2-devel@lists.01.org > Cc: Daryl McDaniel ; Zhu; Yonghong > > Subject: [Patch] AppPkg: Update email and URL V2. > > Cc: Daryl McDaniel > CC: Zhu, Yonghong > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Jaben Carsey > --- > AppPkg/Applications/Python/Ia32/pyconfig.h | 6 +++--- > AppPkg/Applications/Python/Ipf/pyconfig.h| 6 +++--- > AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h | 4 ++-- > AppPkg/Applications/Python/Python-2.7.10/X64/pyconfig.h | 4 ++-- > AppPkg/Applications/Python/X64/pyconfig.h| 4 ++-- > 5 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/AppPkg/Applications/Python/Ia32/pyconfig.h > b/AppPkg/Applications/Python/Ia32/pyconfig.h > index 7970f14..46e29e2 100644 > --- a/AppPkg/Applications/Python/Ia32/pyconfig.h > +++ b/AppPkg/Applications/Python/Ia32/pyconfig.h > @@ -1,7 +1,7 @@ > /** @file > Manually generated Python Configuration file for EDK II. > > -Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved. > +Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved. > This program and the accompanying materials are licensed and made > available > under > the terms and conditions of the BSD License that accompanies this > distribution. > The full text of the license may be found at > @@ -932,7 +932,7 @@ > #undef MVWDELCH_IS_EXPRESSION > > /* Define to the address where bug reports for this package should be sent. > */ > -#define PACKAGE_BUGREPORT "edk2-de...@lists.sourceforge.net" > +#define PACKAGE_BUGREPORT "edk2-devel@lists.01.org" > > /* Define to the full name of this package. */ > #define PACKAGE_NAME"EDK II Python Package" > @@ -944,7 +944,7 @@ > #define PACKAGE_TARNAME "EADK_Python" > > /* Define to the home page for this package. */ > -#define PACKAGE_URL "http://edk2.tianocore.org/toolkit/python"; > +#define PACKAGE_URL > "https://github.com/tianocore/edk2/tree/master/AppPkg/Applications/Python"; > > /* Define to the version of this package. */ > #define PACKAGE_VERSION "V0.8" > diff --git a/AppPkg/Applications/Python/Ipf/pyconfig.h > b/AppPkg/Applications/Python/Ipf/pyconfig.h > index 5b06024..3da9280 100644 > --- a/AppPkg/Applications/Python/Ipf/pyconfig.h > +++ b/AppPkg/Applications/Python/Ipf/pyconfig.h > @@ -1,7 +1,7 @@ > /** @file > Manually generated Python Configuration file for EDK II. > > -Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved. > +Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved. > This program and the accompanying materials are licensed and made > available > under > the terms and conditions of the BSD License that accompanies this > distribution. > The full text of the license may be found at > @@ -928,7 +928,7 @@ > #undef MVWDELCH_IS_EXPRESSION > > /* Define to the address where bug reports for this package should be sent. > */ > -#define PACKAGE_BUGREPORT "edk2-de...@lists.sourceforge.net" > +#define PACKAGE_BUGREPORT "edk2-devel@lists.01.org" > > /* Define to the full name of this package. */ > #define PACKAGE_NAME"EDK II Python Package" > @@ -940,7 +940,7 @@ > #define PACKAGE_TARNAME "EADK_Python" > > /* Define to the home page for this package. */ > -#define PACKAGE_URL "http://edk2.tianocore.org/toolkit/python"; > +#define PACKAGE_URL > "https://github.com/tianocore/edk2/tree/master/AppPkg/Applications/Python"; > > /* Define to the version of this package. */ > #define PACKAGE_VERSION "V0.8" > diff --git a/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h > b/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h > index b86cfa5..5aa936c 100644 > --- a/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h > +++ b/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h > @@ -2,7 +2,7 @@ > Manually generated Python Configuration file for EDK II. > > Copyright (c) 2015, Daryl McDaniel. All rights reserved. > -Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved. > +Copyright (c) 2011 - 2016, Intel Corporation. All rights reserved. > This program and the accompanying materials are licensed and made > available > under > the terms and conditions of the BSD License that accompanies t
Re: [edk2] [PATCH 06/16] StdLib: Series of patches to fix typos - availabe to available
Someone should also check the UEFI file where these return values are defined and make sure that the typo isn't there too. Reviewed-by: Daryl McDaniel Daryl McDaniel > -Original Message- > From: Carsey, Jaben [mailto:jaben.car...@intel.com] > Sent: Thursday, July 07, 2016 7:47 AM > To: Mudusuru, Giri P ; edk2-devel@lists.01.org > Cc: Daryl McDaniel ; Carsey, Jaben > > Subject: RE: [edk2] [PATCH 06/16] StdLib: Series of patches to fix typos - > availabe to available > > Reviewed-by: Jaben Carsey > > > -Original Message- > > From: Mudusuru, Giri P > > Sent: Thursday, July 07, 2016 12:48 AM > > To: edk2-devel@lists.01.org > > Cc: Carsey, Jaben ; Daryl McDaniel > li...@mc2research.org> > > Subject: [edk2] [PATCH 06/16] StdLib: Series of patches to fix typos - > > availabe > > to available > > Importance: High > > > > Cc: Jaben Carsey > > Cc: Daryl McDaniel > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Giri P Mudusuru > > --- > > StdLib/EfiSocketLib/DxeSupport.c | 2 +- > > StdLib/Include/Efi/EfiSocketLib.h | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/StdLib/EfiSocketLib/DxeSupport.c > > b/StdLib/EfiSocketLib/DxeSupport.c > > index 808b710..9630aed 100644 > > --- a/StdLib/EfiSocketLib/DxeSupport.c > > +++ b/StdLib/EfiSocketLib/DxeSupport.c > > @@ -32,7 +32,7 @@ > > > >@retval EFI_SUCCESS The protocol was added to ChildHandle. > >@retval EFI_INVALID_PARAMETER ChildHandle is NULL. > > - @retval EFI_OUT_OF_RESOURCES There are not enough resources > > availabe to create > > + @retval EFI_OUT_OF_RESOURCES There are not enough resources > > available to create > > the child > >@retval other The child handle was not created > > > > diff --git a/StdLib/Include/Efi/EfiSocketLib.h > > b/StdLib/Include/Efi/EfiSocketLib.h > > index 7618d02..73288af 100644 > > --- a/StdLib/Include/Efi/EfiSocketLib.h > > +++ b/StdLib/Include/Efi/EfiSocketLib.h > > @@ -185,7 +185,7 @@ extern CONST UINTN cEslSocketBindingEntries; > > ///< Number of network serv > > > >@retval EFI_SUCCESS The protocol was added to ChildHandle. > >@retval EFI_INVALID_PARAMETER ChildHandle is NULL. > > - @retval EFI_OUT_OF_RESOURCES There are not enough resources > > availabe to create > > + @retval EFI_OUT_OF_RESOURCES There are not enough resources > > available to create > > the child > >@retval other The child handle was not created > > > > -- > > 2.9.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] StdLib usage for drivers?
Breaking the Shell file-system dependency is very easy, if you don’t need file system support from StdLib. All you have to do is make sure that you don’t list DevMedia in your driver or application’s .inf file. That way no file system support is included. A similar thing can be done to remove the interactive console support: remove DevConsole from the list of libraries in LibC.inf. StdLib/LibC/Main/Main.c could then be modified to remove the command-line argument support and standard I/O initialization (stdin, stdout, stderr). Once that is all done, you can change from ShellCEntryLib style entry point to a standard pure UEFI entry point. Then, go through all of the .inf files and remove ShellCEntryLib from the LibraryClass lists and I believe that you will have removed all Shell dependencies. At that point, you will have all of the StdLIb functionality except for command-line, console I/O and file system support. Those modifications will get a version of StdLIb that should be safe for use in drivers. There will still be “excessive” run-time memory usage in some cases because of the MainData structure. Because of the (often unnecessary) interdependencies between functional groupings and sub-libraries within StdLib, you can end up with a lot more code built in than you might want. This is sort of OK for applications, but not so good for drivers where you could possibly have several drivers using StdLib which would mean that you would have to fit several copies of the StdLib code within your available flash space. (one copy of StdLib for each driver that uses it) Daryl McDaniel From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] Sent: Wednesday, July 06, 2016 2:04 PM To: Tim Lewis Cc: Carsey, Jaben ; af...@apple.com; edk2-devel@lists.01.org; Daryl McDaniel (edk2-li...@mc2research.org) Subject: Re: [edk2] StdLib usage for drivers? The daShell problem is easy to solve since it's just a StdLib internal "driver" that's registered among others like stdout,stderr,stdin. We can just stop it from registering to StdLib if we don't have the Shell available. If we disable PcdShellLibAutoInitialize, we'd have to be very careful to find all usages of the ShellProtocol and add NULL pointer checks so StdLib won't crash. A good way to find them all is to make UefiShellLib.c an empty file and disable linker-GC. Thanks Michael On Wed, Jul 6, 2016 at 10:57 PM, Tim Lewis mailto:tim.le...@insyde.com> > wrote: Jaben -- I can certainly recall instances where drivers that publish HII setup pages load things from the disk (such as when checking for specific file names). I also seem to recall that the original EDK shell library was designed to that volume names were simply ignored if the shell protocol was not present. This is essentially what the Shell APIs do, right? They just convert mapping names into device path snippets. Tim -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org <mailto:edk2-devel-boun...@lists.01.org> ] On Behalf Of Carsey, Jaben Sent: Wednesday, July 06, 2016 1:53 PM To: af...@apple.com <mailto:af...@apple.com> Cc: Carsey, Jaben mailto:jaben.car...@intel.com> >; edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> ; Michael Zimmermann mailto:sigmaepsilo...@gmail.com> >; Daryl McDaniel (edk2-li...@mc2research.org <mailto:edk2-li...@mc2research.org> ) mailto:edk2-li...@mc2research.org> > Subject: Re: [edk2] StdLib usage for drivers? The thing that I am trying to figure out is what LibC APIs is really needed by the driver? UEFI Drivers are not supposed to do things like FILE I/O, so who cares if they would fail if they were called… Sidenote: I think that daShell.c is only used when you ask LibC for things that come from the shell… This snippet makes standard APIs point to shell specific ones… LibC/Uefi/Devices/UefiShell/daShell.c:814: Stream->Abstraction.fo_close= &da_ShellClose; LibC/Uefi/Devices/UefiShell/daShell.c:815: Stream->Abstraction.fo_read = &da_ShellRead; LibC/Uefi/Devices/UefiShell/daShell.c:816: Stream->Abstraction.fo_write= &da_ShellWrite; LibC/Uefi/Devices/UefiShell/daShell.c:818: Stream->Abstraction.fo_poll = &da_ShellPoll; LibC/Uefi/Devices/UefiShell/daShell.c:820: Stream->Abstraction.fo_stat = &da_ShellStat; LibC/Uefi/Devices/UefiShell/daShell.c:821: Stream->Abstraction.fo_ioctl= &da_ShellIoctl; LibC/Uefi/Devices/UefiShell/daShell.c:822: Stream->Abstraction.fo_delete = &da_ShellDelete; LibC/Uefi/Devices/UefiShell/daShell.c:823: Stream->Abstraction.fo_rmdir= &da_ShellRmdir; LibC/Uefi/Devices/UefiShell/daShell.c:824: Stream->Abstraction.fo_mkdir= &da_ShellMkdir; LibC/Uefi/Devices/UefiShell/daShell.c:825: Stream->Abstraction.fo_rename = &da_S
Re: [edk2] StdLib usage for drivers?
Marvin, Personally, I would be happy for any contributions you could make for StdLib. The only remaining Shell dependencies should be: * File system support. * One or two functions in PosixLib The next big area is breaking up the MainData structure and moving its members into the sub-libraries that they are relevant to. Once that is done, I had planned on trying to break as many of the library’s interdependencies as possible. As long as StdLib continues to pass the ISO C95 compliance tests, and gets smaller instead of larger, just about anything is fair game. I had pretty much decided to abandon using the FreeBSD / NetBSD code since it is not the best suited for the EDK II environment. As Michael surmised, I’ve been traveling a lot and too busy lately to devote as much attention to StdLib as I wish I could. Please remember for your contributions; compatibility with both GCC and Microsoft compilers and both IA32 and X64 is required. If you can also retain or provide support for ARM then that would be great. I can’t speak for Jaben, so I will have to wait for his response to determine his stance on the issue. I’m willing to answer any questions about AppPkg or StdLib that I can. Thank you for your offer. Daryl McDaniel From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] Sent: Monday, July 04, 2016 11:18 AM To: edk2-devel@lists.01.org Cc: Michael Zimmermann ; edk2-li...@mc2research.org; Carsey, Jaben Subject: RE: [edk2] StdLib usage for drivers? Daryl, Jaben, As you are the package maintainers of StdLib, could you please comment on the situation? If modifications to have StdLib working for drivers are welcome, I would offer my help in cleaning up the existing stuff and/or write my own patches, though of course there is little point if there is no reaction from the reviewers. If it is of any interest, I want to write a shim library for Capstone and would prefer not to have three copies of Std functions in my tree (StdLib, CryptoPkg (SSL) and Capstone), but rather an improved StdLib that works for all. Thanks to those who have offered alternative solutions, but I prefer to keep it ‚clean‘ and have the libraries shipping with EDK2 work. :) Regards, Marvin. From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com] Sent: Thursday, June 23, 2016 5:32 AM To: Marvin Häuser mailto:marvin.haeu...@outlook.com> > Cc: edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> ; af...@apple.com <mailto:af...@apple.com> Subject: Re: [edk2] StdLib usage for drivers? well for the patch to go upstream it would have to get improved a lot. I've tried to implement this in a way that doesn't need a different dsc but the problem is that ShellLib's constructor ASSERT's if it can't find the shell protocol and removing that would probably be against the spec's. Also it appears that the StdLib maintainers are kinda busy because most of the StdLib patches I've sent to this mailing list didn't get reviewed. Thanks Michael On Wed, Jun 22, 2016 at 10:37 PM, Marvin Häuser mailto:marvin.haeu...@outlook.com> > wrote: Hey Michael, Thank you for your input! This looks interesting. Maybe it would be a good idea to provide the libraries that depend on Shell (in master) with functions that call ASSERT (FALSE); for drivers? I do not need file I/O, so I think your modifications might work out well for me. Would be very nice of course if such changes found their way upstream. :) And thank you very much for your comment as well, Andrew! It makes sense that StdLib is primarily targeted at porting console applications to UEFI Shell. Regards, Marvin. From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com <mailto:sigmaepsilo...@gmail.com> ] Sent: Wednesday, June 22, 2016 10:28 PM To: Marvin H?user mailto:marvin.haeu...@outlook.com> > Cc: edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> Subject: Re: [edk2] StdLib usage for drivers? In my fork of edk2 I've added support for using StdLib without the Shell. It's quite hacky(setenv/getenv are stubs, no File IO and maybe other things hidden by linker GC and me not using all features). But depending on which StdLib features you need this can work pretty good. here's the commit that does the magic: https://github.com/efidroid/edk2/commit/bf7a296718486bafaf774ea8bcf187c162c3c167 and this is how you convert a Shell project to a NonShell one: https://github.com/efidroid/uefi_apps_EFIDroidUi/commit/23f0fa08108b8f852564fae733c6a7bce62e2070 as you can see it works by using StdLib with different libraries/cflags so you have to compile your driver separately if there are other modules which need the normal StdLib. Thanks Michael On Wed, Jun 22, 2016 at 9:38 PM, Marvin H?user mailto:marvin.haeu...@outlook.com> <mailto:marvin.haeu...@outlook.com <mail
Re: [edk2] [PATCH] StdLib: add __noreturn attribute to __assert
Michael, In your patch, you use GCC's __noreturn attribute at the end of the line. Does GCC have a version of this that precedes the declaration? Since use of noreturn would apply in a significant number of cases, I was hoping to be able to produce a NORETURN macro to be used at the beginning of declarations (in order to be able to use __declspec(noreturn) for MSVC). I think I remember seeing something like attribute(noreturn) used in GCC code. Do you know if this form really exists? Otherwise, it has to be put in a conditional compilation block on a case-by-case basis. I am afraid that your patch, as is, can not be applied since it would break VC++ builds. NACK by Daryl McDaniel Daryl McDaniel > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael > Zimmermann > Sent: Sunday, April 10, 2016 12:24 AM > To: edk2-devel@lists.01.org > Cc: Jaben Carsey (Intel) ; Daryl McDaniel li...@mc2research.org> > Subject: Re: [edk2] [PATCH] StdLib: add __noreturn attribute to __assert > > I guess it's time to send a reminder for this patch :) > > MIchael > > On Tue, Feb 9, 2016 at 3:27 AM, Daryl McDaniel > wrote: > > > Michael, > > > > Thanks for the report and clear references. > > I'll add this to the list of StdLib work. > > > > Also, thanks for the reminder about '__declspec(noreturn)'. > > > > Daryl McDaniel > > > > > -Original Message- > > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > > Michael > > > Zimmermann > > > Sent: Monday, February 08, 2016 8:42 AM > > > To: Andrew Fish > > > Cc: edk2-devel@lists.01.org > > > Subject: Re: [edk2] [PATCH] StdLib: add __noreturn attribute to __assert > > > > > > it is StdLib specific and other functions like abort are using it > > already. > > > from StdLib/Include/sys/EfiCdefs.h: > > > #if __GNUC_PREREQ__(2, 7) > > > #define __unused __attribute__((__unused__)) > > > #define __noreturn __attribute__((__noreturn__)) > > > #else > > > #define __unused /* delete */ > > > #define __noreturn /* delete */ > > > #endif > > > > > > do other compilers(VC?) really don't need this or should we treat it as > > not > > > being implemented? > > > This page shows that there's sth. called '__declspec(noreturn)': > > > https://msdn.microsoft.com/en-us/library/k6ktzx3s.aspx > > > but obviously there are even more compilers than just gcc and vc. > > > > > > On Mon, Feb 8, 2016 at 5:32 PM, Andrew Fish wrote: > > > > > > > > > > > > On Feb 8, 2016, at 4:15 AM, Michael Zimmermann < > > sigmaepsilo...@gmail.com> > > > > wrote: > > > > > > > > > > this prevents warnings like 'control reaches end of non-void > > function'. > > > > > > > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > > > Signed-off-by: M1cha > > > > > --- > > > > > StdLib/Include/assert.h | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/StdLib/Include/assert.h b/StdLib/Include/assert.h > > > > > index ece4f27..8369f25 100644 > > > > > --- a/StdLib/Include/assert.h > > > > > +++ b/StdLib/Include/assert.h > > > > > @@ -52,7 +52,7 @@ __BEGIN_DECLS > > > > > the application was launched from. > > > > > **/ > > > > > extern void > > > > > -__assert(const char *file, const char *func, int line, const char > > > > > *failedexpr); > > > > > +__assert(const char *file, const char *func, int line, const char > > > > > *failedexpr) __noreturn; > > > > > > > > > > > > > Is __noreturn in the C standard or is it compiler specific? > > > > > > > > Thanks, > > > > > > > > Andrew Fish > > > > > > > > > __END_DECLS > > > > > > > > > > -- > > > > > 2.7.0 > > > > > ___ > > > > > edk2-devel mailing list > > > > > edk2-devel@lists.01.org > > > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > > > > > > > ___ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] StdLib/LibC: Add floorf
Michael,
This patch has been queued for review.
Results soon...
Daryl McDaniel
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
> Zimmermann
> Sent: Sunday, April 10, 2016 12:21 AM
> To: edk2-devel@lists.01.org
> Cc: Jaben Carsey ; Daryl McDaniel li...@mc2research.org>
> Subject: Re: [edk2] [PATCH] StdLib/LibC: Add floorf
>
> I forgot to CC the maintainers, so I'm pinging with them CC'ed now.
>
> Michael
>
> On Wed, Dec 30, 2015 at 2:55 PM, Michael Zimmermann <
> sigmaepsilo...@gmail.com> wrote:
>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Michael Zimmermann
> > ---
> > StdLib/Include/math.h | 8 ++
> > StdLib/LibC/Math/Math.inf | 1 +
> > StdLib/LibC/Math/s_floorf.c | 64
> > +
> > 3 files changed, 73 insertions(+)
> > create mode 100644 StdLib/LibC/Math/s_floorf.c
> >
> > diff --git a/StdLib/Include/math.h b/StdLib/Include/math.h
> > index 3041120..2b5746b 100644
> > --- a/StdLib/Include/math.h
> > +++ b/StdLib/Include/math.h
> > @@ -304,6 +304,14 @@ double fabs(double Arg);
> > **/
> > double floor(double);
> >
> > +/** Compute the largest integer value not greater than Arg.
> > +
> > +@param[in]Arg The value to compute the floor of.
> > +
> > +@return The largest integer value not greater than Arg, expressed
> > as a floating-point number.
> > +**/
> > +float floorf(float);
> > +
> > /** Compute the floating-point remainder of A1 / A2.
> >
> > @param[in]A1The dividend.
> > diff --git a/StdLib/LibC/Math/Math.inf b/StdLib/LibC/Math/Math.inf
> > index ec5c71a..9d6c66d 100644
> > --- a/StdLib/LibC/Math/Math.inf
> > +++ b/StdLib/LibC/Math/Math.inf
> > @@ -64,6 +64,7 @@
> >s_fabs.c
> >s_ceil.c
> >s_floor.c
> > + s_floorf.c
> >s_trunc.c
> >
> ># wrapper functions
> > diff --git a/StdLib/LibC/Math/s_floorf.c b/StdLib/LibC/Math/s_floorf.c
> > new file mode 100644
> > index 000..d6e201f
> > --- /dev/null
> > +++ b/StdLib/LibC/Math/s_floorf.c
> > @@ -0,0 +1,64 @@
> > +/* s_floorf.c -- float version of s_floor.c.
> > + * Conversion to float by Ian Lance Taylor, Cygnus Support,
> > i...@cygnus.com.
> > + */
> > +
> > +/*
> > + *
> > + * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
> > + *
> > + * Developed at SunPro, a Sun Microsystems, Inc. business.
> > + * Permission to use, copy, modify, and distribute this
> > + * software is freely granted, provided that this notice
> > + * is preserved.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#if defined(LIBM_SCCS) && !defined(lint)
> > +__RCSID("$NetBSD: s_floor.c,v 1.11 2002/05/26 22:01:56 wiz Exp $");
> > +#endif
> > +
> > +/*
> > + * floorf(x)
> > + * Return x rounded toward -inf to integral value
> > + * Method:
> > + * Bit twiddling.
> > + * Exception:
> > + * Inexact flag raised if x not equal to floorf(x).
> > + */
> > +
> > +#include "math.h"
> > +#include "math_private.h"
> > +
> > +static const float huge = 1.0e30;
> > +
> > +float
> > +floorf(float x)
> > +{
> > + int32_t i0,j0;
> > + u_int32_t i;
> > + GET_FLOAT_WORD(i0,x);
> > + j0 = ((i0>>23)&0xff)-0x7f;
> > + if(j0<23) {
> > + if(j0<0) { /* raise inexact if x != 0 */
> > +if(huge+x>(float)0.0) {/* return 0*sign(x) if |x|<1 */
> > +if(i0>=0) {i0=0;}
> > +else if((i0&0x7fff)!=0)
> > + { i0=0xbf80;}
> > +}
> > + } else {
> > +i = (0x007f)>>j0;
> > +if((i0&i)==0) return x; /* x is integral */
> > +if(huge+x>(float)0.0) { /* raise inexact flag */
> > +if(i0<0) i0 += (0x0080)>>j0;
> > +i0 &= (~i);
> > +}
> > + }
> > + } else {
> > + if(j0==0x80) return x+x; /* inf or NaN */
> > + else return x;/* x is integral */
> > + }
> > + SET_FLOAT_WORD(x,i0);
> > + return x;
> > +}
> > --
> > 2.6.4
> >
> >
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] StdLib/LibC: Add trunc
Michael,
This patch has been queued for review.
Results soon...
Daryl McDaniel
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael
> Zimmermann
> Sent: Sunday, April 10, 2016 12:20 AM
> To: edk2-devel@lists.01.org
> Cc: Jaben Carsey ; Daryl McDaniel li...@mc2research.org>
> Subject: Re: [edk2] [PATCH] StdLib/LibC: Add trunc
>
> I forgot to CC the maintainers, so I'm pinging with them CC'ed now.
>
> Michael
>
> On Wed, Dec 30, 2015 at 2:41 PM, Michael Zimmermann <
> sigmaepsilo...@gmail.com> wrote:
>
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Michael Zimmermann
> > ---
> > StdLib/LibC/Math/Math.inf | 1 +
> > StdLib/LibC/Math/s_trunc.c | 65
> > ++
> > 2 files changed, 66 insertions(+)
> > create mode 100644 StdLib/LibC/Math/s_trunc.c
> >
> > diff --git a/StdLib/LibC/Math/Math.inf b/StdLib/LibC/Math/Math.inf
> > index 6a48d97..ec5c71a 100644
> > --- a/StdLib/LibC/Math/Math.inf
> > +++ b/StdLib/LibC/Math/Math.inf
> > @@ -64,6 +64,7 @@
> >s_fabs.c
> >s_ceil.c
> >s_floor.c
> > + s_trunc.c
> >
> ># wrapper functions
> >w_acos.c
> > diff --git a/StdLib/LibC/Math/s_trunc.c b/StdLib/LibC/Math/s_trunc.c
> > new file mode 100644
> > index 000..a976c5f
> > --- /dev/null
> > +++ b/StdLib/LibC/Math/s_trunc.c
> > @@ -0,0 +1,65 @@
> > +/* @(#)s_floor.c 5.1 93/09/24 */
> > +/*
> > + *
> > + * Copyright (C) 1993 by Sun Microsystems, Inc. All rights reserved.
> > + *
> > + * Developed at SunPro, a Sun Microsystems, Inc. business.
> > + * Permission to use, copy, modify, and distribute this
> > + * software is freely granted, provided that this notice
> > + * is preserved.
> > + *
> > + */
> > +
> > +#include
> > +#include
> > +#if defined(LIBM_SCCS) && !defined(lint)
> > +__RCSID("$NetBSD: s_floor.c,v 1.11 2002/05/26 22:01:56 wiz Exp $");
> > +#endif
> > +
> > +/*
> > + * trunc(x)
> > + * Return x rounded toward 0 to integral value
> > + * Method:
> > + * Bit twiddling.
> > + * Exception:
> > + * Inexact flag raised if x not equal to trunc(x).
> > + */
> > +
> > +
> > +#include "math.h"
> > +#include "math_private.h"
> > +
> > +static const double huge = 1.0e300;
> > +
> > +double
> > +trunc(double x)
> > +{
> > + int32_t i0,i1,j0;
> > + u_int32_t i;
> > + EXTRACT_WORDS(i0,i1,x);
> > + j0 = ((i0>>20)&0x7ff)-0x3ff;
> > + if(j0<20) {
> > + if(j0<0) { /* raise inexact if x != 0 */
> > +if(huge+x>0.0) {/* |x|<1, so return 0*sign(x) */
> > +i0 &= 0x8000U;
> > +i1 = 0;
> > +}
> > + } else {
> > +i = (0x000f)>>j0;
> > +if(((i0&i)|i1)==0) return x; /* x is integral */
> > +if(huge+x>0.0) { /* raise inexact flag */
> > +i0 &= (~i); i1=0;
> > +}
> > + }
> > + } else if (j0>51) {
> > + if(j0==0x400) return x+x; /* inf or NaN */
> > + else return x;/* x is integral */
> > + } else {
> > + i = ((u_int32_t)(0x))>>(j0-20);
> > + if((i1&i)==0) return x; /* x is integral */
> > + if(huge+x>0.0)/* raise inexact flag */
> > +i1 &= (~i);
> > + }
> > + INSERT_WORDS(x,i0,i1);
> > + return x;
> > +}
> > --
> > 2.6.4
> >
> >
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] StdLib/LibC: Add __aeabi_ui2f and __aeabi_f2uiz
Michael, Thank you for the patches. Would this patch be better placed in the ARM intrinsics package? If not, then I will add it to your other patches which I plan to integrate this weekend. Thanks, Daryl McDaniel > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael > Zimmermann > Sent: Sunday, April 10, 2016 12:19 AM > To: edk2-devel@lists.01.org > Cc: Jaben Carsey ; Daryl McDaniel li...@mc2research.org> > Subject: Re: [edk2] [PATCH] StdLib/LibC: Add __aeabi_ui2f and __aeabi_f2uiz > > I forgot to CC the maintainers, so I'm pinging with them CC'ed now. > > Michael > > On Wed, Dec 30, 2015 at 2:07 PM, Michael Zimmermann < > sigmaepsilo...@gmail.com> wrote: > > > these are needed for converting between unsigned int and single-precision > > float > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > Signed-off-by: Michael Zimmermann > > --- > > StdLib/LibC/LibC.inf | 2 + > > StdLib/LibC/Main/Arm/fixunssfsi.c | 75 > > > > StdLib/LibC/Main/Arm/floatunsisf.c | 79 > > ++ > > 3 files changed, 156 insertions(+) > > create mode 100644 StdLib/LibC/Main/Arm/fixunssfsi.c > > create mode 100644 StdLib/LibC/Main/Arm/floatunsisf.c > > > > diff --git a/StdLib/LibC/LibC.inf b/StdLib/LibC/LibC.inf > > index f136306..7b53f1f 100644 > > --- a/StdLib/LibC/LibC.inf > > +++ b/StdLib/LibC/LibC.inf > > @@ -86,7 +86,9 @@ > > > > [Sources.ARM] > >Main/Arm/fixunsdfsi.c > > + Main/Arm/fixunssfsi.c > >Main/Arm/floatunsidf.c > > + Main/Arm/floatunsisf.c > >Main/Arm/flt_rounds.c > > > > [Sources.AARCH64] > > diff --git a/StdLib/LibC/Main/Arm/fixunssfsi.c > > b/StdLib/LibC/Main/Arm/fixunssfsi.c > > new file mode 100644 > > index 000..251d720 > > --- /dev/null > > +++ b/StdLib/LibC/Main/Arm/fixunssfsi.c > > @@ -0,0 +1,75 @@ > > +/** > > +University of Illinois/NCSA > > +Open Source License > > + > > +Copyright (c) 2009-2014 by the contributors listed in CREDITS.TXT > > + > > +All rights reserved. > > + > > +Developed by: > > + > > +LLVM Team > > + > > +University of Illinois at Urbana-Champaign > > + > > +http://llvm.org > > + > > +Permission is hereby granted, free of charge, to any person obtaining a > > copy of > > +this software and associated documentation files (the "Software"), to > > deal with > > +the Software without restriction, including without limitation the rights > > to > > +use, copy, modify, merge, publish, distribute, sublicense, and/or sell > > copies > > +of the Software, and to permit persons to whom the Software is furnished > > to do > > +so, subject to the following conditions: > > + > > +* Redistributions of source code must retain the above copyright > > notice, > > + this list of conditions and the following disclaimers. > > + > > +* Redistributions in binary form must reproduce the above copyright > > notice, > > + this list of conditions and the following disclaimers in the > > + documentation and/or other materials provided with the distribution. > > + > > +* Neither the names of the LLVM Team, University of Illinois at > > + Urbana-Champaign, nor the names of its contributors may be used to > > + endorse or promote products derived from this Software without > > specific > > + prior written permission. > > + > > +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > > +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > > FITNESS > > +FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE > > +CONTRIBUTORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR > > OTHER > > +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > > FROM, > > +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS > > WITH THE > > +SOFTWARE. > > +**/ > > + > > +#include "int_lib.h" > > + > > +/* Returns: convert a to a unsigned int, rounding toward zero. > > + * Negative values all become zero. > > + */ > > + > > +/* Assumption: float is a IEEE 32 bit floating point type > > + * su_int is a 32 bit integral type > > + * value in float is representable in su_int o
Re: [edk2] EDK2 Python issue with QEMU
OK. Let’s see how much, if any, of Python might be working. Try: python –h python –V python –E –S –c print “It’s alive.” If those three commands work, next try: python –E –S Sorry, but I have to ask this: Do you have a EFI System disk, under QEMU, that has the \Efi\StdLib\lib\python27.10 ( python.27 if you are running 2.7.2) directory populated as described in the PythonReadMe.txt or Py2710ReadMe.txt file? If so, have you made that System disk your current drive or does your Shell prompt still say “Shell>”? It shouldn’t make a difference, but which version of Python are you trying to run: 2.7.2 or 2.7.10? Since you say that Python runs under other environments, but not under QEMU, it would appear to be an issue with the QEMU environment and not with Python. I’ve never used QEMU so I am not familiar enough with the environment to suggest other possibilities. Possibly one of the QEMU experts will be able to give you additional things to try. I’ve amended the Subject to indicate the involvement with QEMU. Daryl McDaniel From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bella Jaguar Sent: Thursday, March 31, 2016 12:30 AM To: Daryl McDaniel Cc: edk2-devel@lists.01.org Subject: Re: [edk2] EDK2 Python I am running it from the Shell. I have read about the STDERR issue but this doesnt seem to be the case - python just returns immediately, it doesn't hang. 2016-03-31 4:41 GMT+02:00 Daryl McDaniel mailto:edk2-li...@mc2research.org> >: Hello, When you try to run Python in QEMU, are you launching it from the Shell? Currently, Python requires the Shell environment to run. Another possibility is that the QEMU environment does not have STDERR output enabled by default. Python sends all prompts to stderr, so if it appears that Python hangs on startup, this may be the case. Just type “exit()” and a return and you should get another Shell prompt. STDERR output can be enabled through Setup via the “Boot Maintenance Manager” --> “Console Options” menu. If you are using the old Shell, not the new UEFI Shell, then if the first command line argument is “-#”, Python will send everything to stdout. Daryl McDaniel From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org <mailto:edk2-devel-boun...@lists.01.org> ] On Behalf Of Bella Jaguar Sent: Wednesday, March 30, 2016 3:31 PM To: edk2-devel@lists.01.org <mailto:edk2-devel@lists.01.org> Subject: [edk2] EDK2 Python Hey guys, I'm compiling python.efi (under AppPkg) and the build finishes successfully but the image only runs in SecMain.exe and not in QEMU emulator running OVMF. Does any one know what might cause this behavior? Regards, Bella ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] EDK2 Python
Hello, When you try to run Python in QEMU, are you launching it from the Shell? Currently, Python requires the Shell environment to run. Another possibility is that the QEMU environment does not have STDERR output enabled by default. Python sends all prompts to stderr, so if it appears that Python hangs on startup, this may be the case. Just type “exit()” and a return and you should get another Shell prompt. STDERR output can be enabled through Setup via the “Boot Maintenance Manager” --> “Console Options” menu. If you are using the old Shell, not the new UEFI Shell, then if the first command line argument is “-#”, Python will send everything to stdout. Daryl McDaniel From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bella Jaguar Sent: Wednesday, March 30, 2016 3:31 PM To: edk2-devel@lists.01.org Subject: [edk2] EDK2 Python Hey guys, I'm compiling python.efi (under AppPkg) and the build finishes successfully but the image only runs in SecMain.exe and not in QEMU emulator running OVMF. Does any one know what might cause this behavior? Regards, Bella ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] free(NULL) and realloc(NULL, size) conformance improvements
> -Original Message- > From: Laszlo Ersek [mailto:ler...@redhat.com] > Sent: Thursday, February 25, 2016 2:01 AM > To: David Woodhouse ; edk2-devel-01 > > Cc: Eric Dong ; Cecil Sheng ; Ting > Ye > ; Qiu Shumin ; Qin Long > ; Liming Gao ; Yao Jiewen > ; Daryl McDaniel ; Jaben > Carsey > ; Samer El-Haj-Mahmoud > Subject: Re: [edk2] [PATCH 0/4] free(NULL) and realloc(NULL, size) conformance > improvements > > On 02/25/16 03:04, David Woodhouse wrote: > > On Wed, 2016-02-24 at 22:13 +0100, Laszlo Ersek wrote: > >> The free() wrapper in BaseCryptLib has a bug that has been triggered > >> by David's recent OpenSSL work. The series fixes the bug, plus > >> more instances of the same. > > > > Should we not just fix the underlying FreePool() function to do the > > sane thing. > > It crossed my mind, but FreePool() is extremely widely used, it has a > detailed interface contract, and its current behavior matches its > interface contract. I'm not up to auditing all uses of FreePool(), to > find the one that perversely enforces a failure return form > FreePool(NULL). :) > > > Anyway, I've rebased my tree on top of yours, > > Thanks -- I'll push the first three patches to edk2 master in a minute, > and I'll post a new version of the fourth. > > > split up the patch > > changes into separate bisectable commits, and pushed my tree out again > > to http://git.infradead.org/users/dwmw2/edk2.git > > I skimmed your fresh master -- the way the patch evolves looks > excellent. I guess it took a lot of effort. > > > Both Cryptest.efi and the test boot of Fedora 22 are working correctly > > at all stages. > > Perfect. > > > Again, the final two commits aren't ready yet. But the rest probably > > are if they build OK on Windows. > > > > I do still want to kill that -w. And why in $DEITY's name do we not > > already have -nostdinc in our CFLAGS for the whole EDK2 build? The -nostdinc equivalent for Visual Studio breaks the NT32 build and there is no way to negate the flag once it has been specified. There would have to be a new target added just for NT32 builds. > I propose to involve our BaseTools overlords here... > > Thanks > Laszlo Daryl McDaniel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v1 1/1] StdLib/BsdSocketLib: Fix minor memory leak.
Fixes a minor memory leak in function res_mkupdrec() by
freeing rrecp on error return.
The error return is triggered by one of two conditions:
1. rrecp is NULL (calloc failed)
2. strdup(dname) returns NULL
Previously, the function just returned NULL. This patch adds a call to
free rrecp before returning NULL. Since the free() function will properly
do nothing when called with a NULL parameter, it is not necessary to
separate the two tests into separate if clauses.
Reported-by: Colin King
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel
---
StdLib/BsdSocketLib/res_mkupdate.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/StdLib/BsdSocketLib/res_mkupdate.c
b/StdLib/BsdSocketLib/res_mkupdate.c
index d81d7d6f1518..db8540ab4b85 100644
--- a/StdLib/BsdSocketLib/res_mkupdate.c
+++ b/StdLib/BsdSocketLib/res_mkupdate.c
@@ -438,8 +438,10 @@ res_mkupdrec(int section, const char *dname,
u_int class, u_int type, u_long ttl) {
ns_updrec *rrecp = (ns_updrec *)calloc(1, sizeof(ns_updrec));
-if (!rrecp || !(rrecp->r_dname = strdup(dname)))
+if (!rrecp || !(rrecp->r_dname = strdup(dname))) {
+free(rrecp);
return (NULL);
+}
rrecp->r_class = (u_int16_t)class;
rrecp->r_type = (u_int16_t)type;
rrecp->r_ttl = (u_int32_t)ttl;
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] rrecp has been allocated but is not freed on the error return path if the strdup fails. This is a minor memory leak that is easily fixed by free'ing rrecp on the error return.
Colin,
Thank you for reporting this.
I have added it to the list things to fix.
It will be addressed ASAP.
Sincerely,
Daryl McDaniel
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Tuesday, February 09, 2016 4:55 AM
> To: edk2-devel@lists.01.org
> Cc: Daryl McDaniel ; Jaben Carsey
>
> Subject: [PATCH] rrecp has been allocated but is not freed on the error return
> path if the strdup fails. This is a minor memory leak that is easily fixed by
> free'ing rrecp on the error return.
>
> From: Colin Ian King
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Colin Ian King
> ---
> StdLib/BsdSocketLib/res_mkupdate.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/StdLib/BsdSocketLib/res_mkupdate.c
> b/StdLib/BsdSocketLib/res_mkupdate.c
> index d81d7d6..b1539be 100644
> --- a/StdLib/BsdSocketLib/res_mkupdate.c
> +++ b/StdLib/BsdSocketLib/res_mkupdate.c
> @@ -438,8 +438,12 @@ res_mkupdrec(int section, const char *dname,
> u_int class, u_int type, u_long ttl) {
> ns_updrec *rrecp = (ns_updrec *)calloc(1, sizeof(ns_updrec));
>
> -if (!rrecp || !(rrecp->r_dname = strdup(dname)))
> +if (!rrecp)
> return (NULL);
> +if (!(rrecp->r_dname = strdup(dname))) {
> +free(rrecp);
> +return (NULL);
> +}
> rrecp->r_class = (u_int16_t)class;
> rrecp->r_type = (u_int16_t)type;
> rrecp->r_ttl = (u_int32_t)ttl;
> --
> 2.7.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] StdLib: add __noreturn attribute to __assert
Michael, Thanks for the report and clear references. I'll add this to the list of StdLib work. Also, thanks for the reminder about '__declspec(noreturn)'. Daryl McDaniel > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael > Zimmermann > Sent: Monday, February 08, 2016 8:42 AM > To: Andrew Fish > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] StdLib: add __noreturn attribute to __assert > > it is StdLib specific and other functions like abort are using it already. > from StdLib/Include/sys/EfiCdefs.h: > #if __GNUC_PREREQ__(2, 7) > #define __unused __attribute__((__unused__)) > #define __noreturn __attribute__((__noreturn__)) > #else > #define __unused /* delete */ > #define __noreturn /* delete */ > #endif > > do other compilers(VC?) really don't need this or should we treat it as not > being implemented? > This page shows that there's sth. called '__declspec(noreturn)': > https://msdn.microsoft.com/en-us/library/k6ktzx3s.aspx > but obviously there are even more compilers than just gcc and vc. > > On Mon, Feb 8, 2016 at 5:32 PM, Andrew Fish wrote: > > > > > > On Feb 8, 2016, at 4:15 AM, Michael Zimmermann > > wrote: > > > > > > this prevents warnings like 'control reaches end of non-void function'. > > > > > > Contributed-under: TianoCore Contribution Agreement 1.0 > > > Signed-off-by: M1cha > > > --- > > > StdLib/Include/assert.h | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/StdLib/Include/assert.h b/StdLib/Include/assert.h > > > index ece4f27..8369f25 100644 > > > --- a/StdLib/Include/assert.h > > > +++ b/StdLib/Include/assert.h > > > @@ -52,7 +52,7 @@ __BEGIN_DECLS > > > the application was launched from. > > > **/ > > > extern void > > > -__assert(const char *file, const char *func, int line, const char > > > *failedexpr); > > > +__assert(const char *file, const char *func, int line, const char > > > *failedexpr) __noreturn; > > > > > > > Is __noreturn in the C standard or is it compiler specific? > > > > Thanks, > > > > Andrew Fish > > > > > __END_DECLS > > > > > > -- > > > 2.7.0 > > > ___ > > > edk2-devel mailing list > > > edk2-devel@lists.01.org > > > https://lists.01.org/mailman/listinfo/edk2-devel > > > > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] StdLib: Fix compilation errors caused by previous commit of daConsole.c
Michael,
Can you review this patch to verify that it fixes the problem you were seeing.
Thanks,
Daryl
StdLib: Fix compilation errors caused by previous commit of daConsole.c
Move functions da_ConFlush and da_ConClose to just before da_ConPoll so that
they are defined after any calls to them.
Replace da_ConFlush with the actual final implementation instead of the
initial version which was committed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel
---
diff --git a/StdLib/LibC/Uefi/Devices/Console/daConsole.c
b/StdLib/LibC/Uefi/Devices/Console/daConsole.c
--- a/StdLib/LibC/Uefi/Devices/Console/daConsole.c
+++ b/StdLib/LibC/Uefi/Devices/Console/daConsole.c
@@ -106,99 +106,6 @@
return i;
}
-/** Flush the console's IIO buffers.
-
-Flush the IIO Input or Output buffers depending upon the mode
-of the specified file.
-
-If the console is open for output, write any unwritten data in the output
-buffer to the console.
-
-If the console is open for input or output, discard any remaining data
-in the associated buffers.
-
-@param[in]filpPointer to the target file's descriptor structure.
-
-@retval 0 Always succeeds
-**/
-static
-int
-EFIAPI
-da_ConFlush(
- struct __filedes *filp
-)
-{
- cIIO *This;
- char *MbcsPtr;
- ssize_t NumProc;
- void *OutPtr;
-
- This = filp->devdata;
-
- if (filp->f_iflags & S_ACC_READ) { // Readable so flush the input buffer
-This->InBuf->Flush(This->InBuf, UNICODE_STRING_MAX);
- }
- if (filp->f_iflags & S_ACC_WRITE) {// Writable so flush the output
buffer
-// At this point, the characters to write are in OutBuf
-// First, linearize and consume the buffer
-NumProc = OutBuf->Read(OutBuf, gMD->UString, UNICODE_STRING_MAX-1);
-if (NumProc > 0) { // Optimization -- Nothing to do if no characters
- gMD->UString[NumProc] = 0; // Ensure that the buffer is terminated
-
- if(filp->f_iflags & _S_IWTTY) {
-// Output device expects wide characters, Output what we have
-OutPtr = gMD->UString;
- }
- else {
-// Output device expects narrow characters, convert to MBCS
-OutPtr = gMD->UString2;
-// Translate the wide buffer, gMD->UString into MBCS
-// in the buffer pointed to by OutPtr.
-// The returned value, NumProc, is the resulting number of bytes.
-NumProc = wcstombs((char *)OutPtr, (const wchar_t *)gMD->UString,
NumProc);
-((char *)OutPtr)[NumProc] = 0; // Ensure the buffer is terminated
- }
- // Do the actual write of the data
- (void) filp->f_ops->fo_write(filp, NULL, NumProc, OutPtr);
-}
- }
- return 0;
-}
-
-/** Close an open file.
-
-@param[in] filpPointer to the file descriptor structure for this file.
-
-@retval 0 The file has been successfully closed.
-@retval -1filp does not point to a valid console descriptor.
-**/
-static
-int
-EFIAPI
-da_ConClose(
- IN struct __filedes *filp
-)
-{
- ConInstance*Stream;
-
- Stream = BASE_CR(filp->f_ops, ConInstance, Abstraction);
- // Quick check to see if Stream looks reasonable
- if(Stream->Cookie != CON_COOKIE) {// Cookie == 'IoAb'
-errno = EINVAL;
-EFIerrno = RETURN_INVALID_PARAMETER;
-return -1;// Looks like a bad File Descriptor pointer
- }
- // Stream and filp look OK, so continue.
- // Flush the I/O buffers
- (void) da_ConFlush(filp);
-
- // Break the connection to IIO
- filp->devdata = NULL;
-
- gMD->StdIo[Stream->InstanceNum] = NULL; // Mark the stream as closed
- return 0;
-}
-
/** Position the console cursor to the coordinates specified by Position.
@param[in] filp Pointer to the file descriptor structure for this
file.
@@ -621,6 +528,101 @@
}
return RetVal;
+}
+
+/** Flush a console device's IIO buffers.
+
+Flush the IIO Input or Output buffers associated with the specified file.
+
+If the console is open for output, write any unwritten data in the
associated
+output buffer (stdout or stderr) to the console.
+
+If the console is open for input, discard any remaining data
+in the input buffer.
+
+@param[in]filpPointer to the target file's descriptor structure.
+
+@retval 0 Always succeeds
+**/
+static
+int
+EFIAPI
+da_ConFlush(
+ struct __filedes *filp
+)
+{
+ cFIFO *OutBuf;
+ ssize_t NumProc;
+ int Flags;
+
+
+if(filp->MyFD == STDERR_FILENO) {
+ OutBuf = IIO->ErrBuf;
+}
+else {
+ OutBuf = IIO->OutBuf;
+}
+
+Flags = filp->Oflags & O_ACCMODE; // Get the device's open mode
+if (Flags != O_WRONLY) { // (Flags == O_RDONLY) || (Flags == O_RDWR)
+ // Readable so discard the contents of the input buffer
+ IIO->InBuf->Flush(IIO->I
[edk2] [PATCH] Python: Clean up and document how to escape the -# option.
AppPkg/.../Python: Clean up and document how to escape the -# option. Depending upon the version of Shell you are using, it may be necessary to escape the '#' character, when using the "-#" command-line option, so that the Shell doesn't interpret it as the start of a comment. The escape character is '^'. Example: python -^# -V * General updating. * Re-format so that no line is longer than 80 char. * Add note about escaping the "-#" command-line option. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel --- diff U3 a/AppPkg/Applications/Python/PythonReadMe.txt b/AppPkg/Applications/Python/PythonReadMe.txt --- a/AppPkg/Applications/Python/PythonReadMe.txt Fri Oct 25 12:09:26 2013 +++ b/AppPkg/Applications/Python/PythonReadMe.txt Sun Jan 03 15:43:26 2016 @@ -1,7 +1,8 @@ EDK II Python -ReadMe - Release 1.02 - 18 Jan. 2013 + ReadMe +Version 2.7.2 +Release 1.02 +18 Jan. 2013 1. OVERVIEW @@ -25,10 +26,10 @@ == 3.1 Getting Python == - Currently only version 2.7.2 of the CPython distribution is supported. For development - ease, a subset of the Python 2.7.2 distribution has been included in the AppPkg source - tree. If a full distribution is desired, the Python-2.7.2 directory can be removed or - renamed and the full source code downloaded from http://www.python.org/ftp/python/2.7.2/. + For development ease, a subset of the Python 2.7.2 distribution has been + included in the AppPkg source tree. If a full distribution is desired, the + Python-2.7.2 directory can be removed or renamed and the full source code + downloaded from http://www.python.org/ftp/python/2.7.2/. A. Within your EDK II development tree, extract the Python distribution into AppPkg/Applications/Python. This should create the @@ -70,7 +71,8 @@ |- \etc Configuration files used by libraries. |- \tmp Temporary files created by tmpfile(), etc. |- \lib Root of the libraries tree. - |- \python.27Directory containing the Python library modules. + |- \python.27Directory containing the Python library + |modules. |- \lib-dynload Dynamically loadable Python extensions. |- \site-packagesSite-specific packages and modules. @@ -81,7 +83,7 @@ system as follows: * \Efi\Tools receives a copy of Build/AppPkg/DEBUG_VS2005/X64/Python.efi. - ^ ^^ + ^ ^^ Modify the host path to match the your build type and compiler. * The \Efi\StdLib\etc directory is populated from the StdLib/Efi/StdLib/etc @@ -94,8 +96,8 @@ sitetypes copy_reglinecache genericpath * Python C Extension Modules built as dynamically loadable extensions go into -the \Efi\StdLib\lib\python.27\lib-dynload directory. This functionality is not -yet implemented. +the \Efi\StdLib\lib\python.27\lib-dynload directory. This functionality is +not yet implemented. 6. Example: Enabling socket support @@ -107,11 +109,48 @@ functools, types, os, sys, warnings, cStringIO, StringIO, errno 5. build -a X64 -p AppPkg\AppPkg.dsc - 6. copy Build\AppPkg\DEBUG_VS2005\X64\Python.efi to \Efi\Tools on your target system. - Modify as needed + 6. copy Build\AppPkg\DEBUG_VS2005\X64\Python.efi to \Efi\Tools on your + target system. Replace "DEBUG_VS2005\X64", in the source path, with + values appropriate for your tool chain and processor architecture. + + +7. Running Python += + Python must currently be run from an EFI FAT-32 partition, or volume, under + the UEFI Shell. At the Shell prompt enter the desired volume name, followed + by a colon ':', then press Enter. Python can then be executed by typing its + name, followed by any desired options and arguments. + + EXAMPLE: + 2.0 Shell> fs0: + 2.0 FS0:\> python + Python 2.7.2 (default, Oct 13 2015, 16:21:53) [C] on uefi + Type "help", "copyright", "credits" or "license" for more information. + >>> exit() + 2.0 FS0:\> + + NOTE: + Python, as distributed, sends its interactive prompts to stderr. If + STDERR isn't enabled in UEFI Setup so that it's output goes to the + console, it may appear that Python hangs on startup. If this happens, +
Re: [edk2] undefined Reference to 'strtof'
Michael, How would one reproduce the problem you are seeing? I don't see any problems when building or running any of the StdLib floating point test programs. This is just on Tile, Ia32 and X64, though. Sincerely, Daryl McDaniel > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael > Zimmermann > Sent: Wednesday, December 30, 2015 5:21 AM > To: edk2-devel@lists.01.org > Subject: [edk2] undefined Reference to 'strtof' > > this is caused by: > #define strtof_strtof > https://github.com/tianocore/edk2/blob/master/StdLibPrivateInternalFiles/Include/ > namespace.h#L45 > > we either need to remove this define or fix the function declaration. > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] StdLib: Clarify and improve comments.
StdLib: Clarify and improve comments.
LibC/Locale/multibyte_Utf8.c
LibC/Uefi/SysCalls.c
Clarify and improve comments.
Include/sys/termios.h
Add parameter names to function prototypes as referenced in the comments.
StdLibPrivateInternalFiles\Include\kfile.h
Add comment for the fo_close fileop.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel
---
.../StdLib/LibC/Locale/multibyte_Utf8.c | 20 +++-
.../StdLib/LibC/Uefi/SysCalls.c | 127 +++--
.../StdLib/Include/sys/termios.h| 11 ++-
.../StdLibPrivateInternalFiles\Include\kfile.h | 11 +--
4 files changed, 95 insertions(+), 74 deletions(-)
diff U3 a/StdLib/LibC/Locale/multibyte_Utf8.c
b/StdLib/LibC/Locale/multibyte_Utf8.c
--- a/StdLib/LibC/Locale/multibyte_Utf8.c Tue May 14 17:59:11 2013
+++ b/StdLib/LibC/Locale/multibyte_Utf8.c Sun Jan 03 12:45:02 2016
@@ -1,4 +1,5 @@
/** @file
+ Copyright (c) 2016, Daryl McDaniel. All rights reserved.
Copyright (c) 2012, Intel Corporation. All rights reserved.
This program and the accompanying materials
are licensed and made available under the terms and conditions of the BSD
License
@@ -16,7 +17,7 @@
#include
#include
-typedef int ch_UCS4;
+typedef int ch_UCS4;
static mbstate_t LocalConvState = {0};
@@ -79,7 +80,7 @@
// We are in an invalid state
ps->A = 0;// Initial State
}
- ps->C[ps->A] = ch; // Save the current character
+ ps->C[ps->A] = ch; // Save the current byte
Mask = utf8_code_length[ch];
if(ps->A == 0) {// Initial State. First byte of sequence.
@@ -89,7 +90,7 @@
case 0: // State 0, Code 0
errno = EILSEQ;
RetVal = -1;
-ps->E = 1;// Consume this character
+ps->E = 1;// Consume this byte
break;
case 1: // State 0, Code 1
// ASCII-7 Character
@@ -116,7 +117,7 @@
ps->A = 0; // Next state is State-0
RetVal = 2;
}
- else {// This isn't the last character, get more. State 1, Code
3 or 4
+ else {// This isn't the last byte, get more. State 1, Code 3 or
4
ps->A = 2;
RetVal = -2;
}
@@ -158,12 +159,12 @@
errno = EILSEQ;
ps->A = 0;
RetVal = -1;
-ps->E = 4; // Can't happen, but consume this character anyway
+ps->E = 4; // Can't happen, but consume this byte anyway
}
break;
}
}
-else {// Invalid surrogate character
+else {// Invalid surrogate byte
errno = EILSEQ;
ps->A = 0; // Next is State-0
RetVal = -1;
@@ -287,7 +288,8 @@
@param[in]Src Pointer to a wide character string.
@param[in]Limit Maximum number of bytes the converted string may
occupy.
-@param[out] NumChar Pointer to where to store the number of wide
characters, or NULL.
+@param[out] NumChar Pointer to where to store the number of wide
characters
+consumed, or NULL.
@return The number of bytes required to convert Src to MBCS,
not including the terminating NUL. If NumChar is not NULL,
the number
@@ -961,8 +963,8 @@
@return If a wide character is encountered that does not correspond to a
valid multibyte character, the wcstombs function returns
(size_t)(-1). Otherwise, the wcstombs function returns the number
- of bytes modified, not including a terminating null character,
- if any.
+ of bytes in the resulting multibyte character sequence,
+ not including the terminating null character (if any).
Declared in: stdlib.h
**/
diff U3 a/StdLib/LibC/Uefi/SysCalls.c b/StdLib/LibC/Uefi/SysCalls.c
--- a/StdLib/LibC/Uefi/SysCalls.c Fri Dec 21 10:19:41 2012
+++ b/StdLib/LibC/Uefi/SysCalls.c Sun Jan 03 12:52:28 2016
@@ -1,6 +1,7 @@
/** @file
EFI versions of NetBSD system calls.
+ Copyright (c) 2016, Daryl McDaniel. All rights reserved.
Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made available
under
the terms and conditions of the BSD License that accompanies this
distribution.
@@ -192,18 +193,18 @@
Fp = &gMD->fdarray[fd];
// Check if there are other users of this FileHandle
if(Fp->RefCount == 1) { // There should be no other users
-if(! IsDupFd(fd)) {
- // Only do the close if no one else is using the FileHandle
- if(Fp->f_iflags & FIF_DELCLOSE) {
-/* Handle files marked "Delete on Close". */
-if(Fp->f_ops->fo_delete != NULL) {
-
[edk2] [PATCH] StdLib: Implement da_ConFlush() and flush I/O buffers when closing a console device.
StdLib: Implement da_ConFlush() and flush I/O buffers when closing a console
device.
Add header file Efi/SysEfi.h
Implement function da_ConFlush()
Modify da_ConClose() to flush its buffers and clean up better upon close.
Construct the console instance using the new da_ConFlush() instead of the
nullop function.
Remove da_ConFlush() from the "Not implemented (yet?)" place holder.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel
---
diff U3 a/StdLib/LibC/Uefi/Devices/Console/daConsole.c
b/StdLib/LibC/Uefi/Devices/Console/daConsole.c
--- a/StdLib/LibC/Uefi/Devices/Console/daConsole.c Tue Nov 11 14:56:58 2014
+++ b/StdLib/LibC/Uefi/Devices/Console/daConsole.c Sun Jan 03 12:16:39 2016
@@ -10,6 +10,7 @@
The devices status as a wide device is indicatd by _S_IWTTY being set in
f_iflags.
+ Copyright (c) 2016, Daryl McDaniel. All rights reserved.
Copyright (c) 2010 - 2014, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made available
under
the terms and conditions of the BSD License that accompanies this
distribution.
@@ -37,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -104,6 +106,65 @@
return i;
}
+/** Flush the console's IIO buffers.
+
+Flush the IIO Input or Output buffers depending upon the mode
+of the specified file.
+
+If the console is open for output, write any unwritten data in the output
+buffer to the console.
+
+If the console is open for input or output, discard any remaining data
+in the associated buffers.
+
+@param[in]filpPointer to the target file's descriptor structure.
+
+@retval 0 Always succeeds
+**/
+static
+int
+EFIAPI
+da_ConFlush(
+ struct __filedes *filp
+)
+{
+ cIIO *This;
+ char *MbcsPtr;
+ ssize_t NumProc;
+ void *OutPtr;
+
+ This = filp->devdata;
+
+ if (filp->f_iflags & S_ACC_READ) { // Readable so flush the input buffer
+This->InBuf->Flush(This->InBuf, UNICODE_STRING_MAX);
+ }
+ if (filp->f_iflags & S_ACC_WRITE) {// Writable so flush the output
buffer
+// At this point, the characters to write are in OutBuf
+// First, linearize and consume the buffer
+NumProc = OutBuf->Read(OutBuf, gMD->UString, UNICODE_STRING_MAX-1);
+if (NumProc > 0) { // Optimization -- Nothing to do if no characters
+ gMD->UString[NumProc] = 0; // Ensure that the buffer is terminated
+
+ if(filp->f_iflags & _S_IWTTY) {
+// Output device expects wide characters, Output what we have
+OutPtr = gMD->UString;
+ }
+ else {
+// Output device expects narrow characters, convert to MBCS
+OutPtr = gMD->UString2;
+// Translate the wide buffer, gMD->UString into MBCS
+// in the buffer pointed to by OutPtr.
+// The returned value, NumProc, is the resulting number of bytes.
+NumProc = wcstombs((char *)OutPtr, (const wchar_t *)gMD->UString,
NumProc);
+((char *)OutPtr)[NumProc] = 0; // Ensure the buffer is terminated
+ }
+ // Do the actual write of the data
+ (void) filp->f_ops->fo_write(filp, NULL, NumProc, OutPtr);
+}
+ }
+ return 0;
+}
+
/** Close an open file.
@param[in] filpPointer to the file descriptor structure for this file.
@@ -127,6 +188,13 @@
EFIerrno = RETURN_INVALID_PARAMETER;
return -1;// Looks like a bad File Descriptor pointer
}
+ // Stream and filp look OK, so continue.
+ // Flush the I/O buffers
+ (void) da_ConFlush(filp);
+
+ // Break the connection to IIO
+ filp->devdata = NULL;
+
gMD->StdIo[Stream->InstanceNum] = NULL; // Mark the stream as closed
return 0;
}
@@ -188,10 +256,10 @@
by da_ConWrite are WIDE characters. It is the responsibility of the
higher-level function(s) to perform any necessary conversions.
-@param[in,out] BufferSize Number of characters in Buffer.
+ @param[in,out] BufferSize Number of characters in Buffer.
@param[in] Buffer The WCS string to be displayed
-@return The number of Characters written.
+ @return The number of Characters written.
*/
static
ssize_t
@@ -525,7 +593,7 @@
wchar_t*MPath // Not used for console devices
)
{
- ConInstance *Stream;
+ ConInstance*Stream;
UINT32 Instance;
int RetVal = -1;
@@ -646,68 +714,68 @@
IIO = New_cIIO();
if(IIO == NULL) {
FreePool(ConInstanceList);
- }
+}
else {
Status = RETURN_SUCCESS;
- for( i = 0; i < NUM_SPECIAL; ++i) {
-// Get pointer to instance.
-Stream = &ConInstanceList[i];
-
-Stream->Cookie = CON_COOKIE;
-Stream->InstanceNum = i;
-Stream->CharState.A = 0;// Start in the initial state
-
-
[edk2] [PATCH] StdLib: Fix IIO_Write() to return the number of bytes consumed, not characters output.
StdLib: Fix IIO_Write() to return the number of bytes consumed, not characters
output.
Depending upon termios settings, writing to a terminal device may result in
many more characters being output than were in the buffer provided to the
IIO_Write() function.
IIO_Write() is supposed to return the number of BYTES written, not characters.
Since the provided buffer contains MBCS characters, there can be up to three
bytes per character. Due to the expansion that may occur, "BYTES written"
is interpreted to mean the number of BYTES consumed from the MBCS buffer
provided as a parameter to IIO_Write.
These changes ensure that the correct number of characters are consumed from
the internal Output buffer and the correct number of BYTES consumed from the
buffer parameter are counted and returned.
Update copyright.
Add debugging instrumentation to count unconsumed data in the Input and Output
buffers.
Improve comments for IIO_Write().
Modify IIO_Write() to:
* Accurately count input bytes CONSUMED.
* Consume only as many expanded (cooked) characters from the output buffer
as were actually sent to the device.
* Purge only the number of CHARACTERS sent from the output buffer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel
---
diff U3 a/StdLib/LibC/Uefi/InteractiveIO/IIO.c
b/StdLib/LibC/Uefi/InteractiveIO/IIO.c
--- a/StdLib/LibC/Uefi/InteractiveIO/IIO.c Tue Dec 11 13:19:14 2012
+++ b/StdLib/LibC/Uefi/InteractiveIO/IIO.c Sun Jan 03 09:35:14 2016
@@ -3,6 +3,7 @@
The functions assume that isatty() is TRUE at the time they are called.
+ Copyright (c) 2016, Daryl McDaniel. All rights reserved.
Copyright (c) 2012, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
@@ -26,6 +27,20 @@
#include "IIOutilities.h"
#include "IIOechoCtrl.h"
+// Instrumentation used for debugging
+#define IIO_C_DEBUG 0 ///< Set to 1 to enable instrumentation, 0 to
disable
+
+#if IIO_C_DEBUG
+ static volatile size_t IIO_C_WRemainder = 0; ///< Characters in Out
buffer after IIO_Write
+ static volatile size_t IIO_C_RRemainder = 0; ///< Characters in In buffer
after IIO_Read
+
+ #define W_INSTRUMENT IIO_C_WRemainder =
+ #define R_INSTRUMENT IIO_C_RRemainder =
+#else // ! IIO_C_DEBUG -- don't instrument code
+ #define W_INSTRUMENT (void)
+ #define R_INSTRUMENT (void)
+#endif // IIO_C_DEBUG
+
/** Read from an Interactive IO device.
NOTE: If _S_IWTTY is set, the internal buffer contains WIDE characters.
@@ -82,24 +97,44 @@
NumRead = wcstombs((char *)Buffer, (const wchar_t *)gMD->UString2,
XlateSz);
// Consume the translated characters
- (void)This->InBuf->Flush(This->InBuf, Needed);
+ (void) This->InBuf->Flush(This->InBuf, Needed);
}
else {
// Data in InBuf is narrow characters. Use verbatim.
NumRead = This->InBuf->Read(This->InBuf, Buffer, (INT32)BufferSize);
}
+#if IIO_C_DEBUG
+IIO_C_RRemainder = This->InBuf->Count(This->InBuf, AsElements);
+#endif // IIO_C_DEBUG
}
return NumRead;
}
-/** Process characters from buffer buf and write them to the output device
+/** Handle write to a Terminal (Interactive) device.
+
+Processes characters from buffer buf and writes them to the Terminal device
specified by filp.
+The parameter buf points to a MBCS string to be output. This is processed
+and buffered one character at a time by IIO_WriteOne() which handles TAB
+expansion, NEWLINE to CARRIAGE_RETURN + NEWLINE expansion, as well as
+basic line editing functions. The number of characters actually written to
+the output device will seldom equal the number of characters consumed from
+buf.
+
+In this implementation, all of the special characters processed by
+IIO_WriteOne() are single-byte characters with values less than 128.
+(7-bit ASCII or the single-byte UTF-8 characters)
+
+Every byte that is not one of the recognized special characters is passed,
+unchanged, to the Terminal device.
+
@param[in] filp Pointer to a file descriptor structure.
@param[in] buf Pointer to the MBCS string to be output.
@param[in] N Number of bytes in buf.
-@retval >=0Number of bytes sent to the output device.
+@retval >=0 Number of bytes consumed from buf and sent to the
+ Terminal device.
**/
static
ssize_t
@@ -114,16 +149,15 @@
cFIFO *OutBuf;
mbstate_t *OutState;
char *MbcsPtr;
- ssize_t NumWritten;
+ ssize_t NumConsumed;
ssize_t NumProc;
size_t CharLen;
UINTN MaxColumn;
UINTN MaxRow;
- wchar_t OutChar[2]; // Just in case we run into 4-byte MBCS character
+
Re: [edk2] [PATCH] StdLib: Return and flush of proper number of bytes for IIO_Write()
Alexey,
It turns out the problem is deeper than thought.
Since IIO is for Terminal devices, depending upon the termios settings
many more characters may be output than were present in the buffer
provided as a parameter to IIO_Write(). This is due to TAB expansion,
LF to CRLF conversion, and line editing operations.
The expected behavior, I believe, is for IIO_Write (and subsequently write())
to return the number of BYTES consumed from the buffer provided as a parameter
to the call.
I will be submitting a new version of the patch, titled:
StdLib: Fix IIO_Write() to return the number of bytes consumed, not
characters output.
I would appreciate it if you could review the patch since your test environment
for this problem is much better than mine.
Thanks,
Daryl McDaniel
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Alexey
> Vegner
> Sent: Wednesday, December 30, 2015 4:15 AM
> To: Daryl McDaniel ; edk2-de...@ml01.01.org
> Subject: [edk2] [PATCH] StdLib: Return and flush of proper number of bytes for
> IIO_Write()
>
> Daryl, Community
>
> I've found another logical error inside IIO_Write().
> It's related to flush of OutBuf with wide characters.
> Currently the number of flushed characters from OutBuf is correct only for a
> conditional branch with wide character device but may be incorrect for
> non-latin
> symbols and multi-byte device.
> For multi-byte character device more characters are flushed than it should be.
> So please consider more appropriate patch which fixes improper flush and
> guarantee return of a proper number of bytes sent to any device type.
> Happy New Year!
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Alexey Vegner
> ---
>
> The patch for
> https://github.com/tianocore/edk2/blob/master/StdLib/LibC/Uefi/InteractiveIO/IIO.
> c:
>
> diff --git a/StdLib/LibC/Uefi/InteractiveIO/IIO.c
> b/StdLib/LibC/Uefi/InteractiveIO/IIO.c
> index 65b61d9..7375c74 100644
> --- a/StdLib/LibC/Uefi/InteractiveIO/IIO.c
> +++ b/StdLib/LibC/Uefi/InteractiveIO/IIO.c
> @@ -115,6 +115,7 @@ IIO_Write(
>mbstate_t *OutState;
>char *MbcsPtr;
>ssize_t NumWritten;
> + ssize_t NumToFlush;
>ssize_t NumProc;
>size_t CharLen;
>UINTN MaxColumn;
> @@ -148,7 +149,6 @@ IIO_Write(
> This->CurrentXY.Column = This->InitialXY.Column;
> This->CurrentXY.Row = This->InitialXY.Row;
>
> -
> NumWritten = 0;
> OutChar[0] = (wchar_t)buf[0];
> while((OutChar[0] != 0) && (NumWritten < N)) {
> @@ -177,12 +177,18 @@ IIO_Write(
> if(filp->f_iflags & _S_IWTTY) {
>// Output device expects wide characters, Output what we have
>NumWritten = filp->f_ops->fo_write(filp, NULL, NumWritten,
> gMD->UString);
> + // Remember how many wide characters we need to flush
> + NumToFlush = NumWritten;
> + // The function gets buf with multi-byte string but writes to the
> device
> wide-character string.
> + // So we have to return how many bytes from buf have been sent.
> + gMD->UString[NumWritten] = '\0';
> + NumWritten = (ssize_t)EstimateWtoM((const wchar_t *)gMD->UString,
> UNICODE_STRING_MAX * sizeof(wchar_t), NULL);
> }
> else {
>// Output device expects narrow characters, convert to MBCS
>MbcsPtr = (char *)gMD->UString2;
>// Determine the needed space
> - NumProc = (ssize_t)EstimateWtoM((const wchar_t *)gMD->UString,
> UNICODE_STRING_MAX * sizeof(wchar_t), &CharLen);
> + NumProc = (ssize_t)EstimateWtoM((const wchar_t *)gMD->UString,
> UNICODE_STRING_MAX * sizeof(wchar_t), NULL);
>
>// Now translate this into MBCS in Buffer
>NumWritten = wcstombs(MbcsPtr, (const wchar_t *)gMD->UString, NumProc);
> @@ -190,9 +196,12 @@ IIO_Write(
>
>// Send the MBCS buffer to Output
>NumWritten = filp->f_ops->fo_write(filp, NULL, NumWritten, MbcsPtr);
> + // Calculate how many wide characters we need to flush
> + MbcsPtr[NumWritten] = 0;
> + NumToFlush = CountMbcsChars(MbcsPtr);
> }
> -// Consume the translated characters
> - (void)OutBuf->Flush(OutBuf, NumWritten);
> +// Consume the translated wide characters
> +(void)OutBuf->Flush(OutBuf, NumToFlush);
>}
>else {
> if(This == NULL) {
>
> Best regards,
> Alexey Vegner
> Paragon Software Group Corporation
> http://www.paragon-software.com
>
> -Original Message-
> From: Daryl McDaniel [mailto:edk2-li...@mc2research.org]
> Sent: Tuesday, December 29, 2015 6:06 AM
>
[edk2] [PATCH] StdLib: Temporarily restrict compiler warnings so that sockets can be built using VS2015.
StdLib: Temporarily restrict compiler warnings so that sockets can be built using VS2015. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel --- diff U3 a/StdLib/StdLib.inc b/StdLib/StdLib.inc --- a/StdLib/StdLib.inc Tue Aug 11 21:25:12 2015 +++ b/StdLib/StdLib.inc Sun Jan 03 12:17:42 2016 @@ -5,6 +5,7 @@ # The including DSC file must DEFINE the EMULATE macro if # the application is to be run in an emulation environment. # +# Copyright (c) 2016, Daryl McDaniel. All rights reserved. # Copyright (c) 2011 - 2014, Intel Corporation. All rights reserved. # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License @@ -133,3 +134,12 @@ RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm XCODE:*_*_*_CC_FLAGS = -nostdinc -nostdlib -DUEFI_C_SOURCE -Wno-unused-const-variable -Wno-string-compare -Wno-sometimes-uninitialized !endif + + # Temporarily restrict compiler warnings to those produced by VS2012. + # Code that fails when these flags are removed will have to be rewritten + # in order to pass. This may be as simple as renaming an object, but may + # require more significant changes. +MSFT:*_VS2015_*_CC_FLAGS = /Wv:11 +MSFT:*_VS2015x86_*_CC_FLAGS = /Wv:11 +MSFT:*_VS2015xASL_*_CC_FLAGS = /Wv:11 +MSFT:*_VS2015x86xASL_*_CC_FLAGS = /Wv:11 -- Daryl McDaniel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] StdLib: Return of proper number of bytes sent to the output device expecting wide characters
Alexey,
Thank you for bringing this to my attention and providing the patch and
detailed analysis.
There is a chance that I will not be able to review and commit this until next
week.
Please be patient.
Happy Holidays,
Daryl McDaniel
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Alexey
> Vegner
> Sent: Monday, December 28, 2015 3:04 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH] StdLib: Return of proper number of bytes sent to the
> output device expecting wide characters
>
> When we try to print out some non-latin Unicode UTF-16 string by means of
> *printf family functions some garbage is also printed out after the given
> string.
> The reason is IIO_Write() function (StdLib/LibC/Uefi/InteractiveIO/IIO.c)
> returns
> invalid number of bytes
> sent to the device expecting wide characters.
> That function gets buf parameter (pointer to the MBC string to be output) and
> returns number of bytes
> sent to the output device. But if the device expects wide characters the
> function
> will return actually number
> of sent wide characters instead of number of MBC characters consumed from the
> buf.
> It's obvious that number of MBC characters isn't equal to a number of
> equivalent
> wide characters. It's greater.
> This difference causes upper level functions to send more MBC characters from
> beyond the bounds of the given string.
> That's why garbage is printed out. Please look at the suggested patch.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Alexey Vegner
> ---
>
> The patch for
> https://github.com/tianocore/edk2/blob/master/StdLib/LibC/Uefi/InteractiveIO/IIO.
> c:
>
> diff --git a/StdLib/LibC/Uefi/InteractiveIO/IIO.c
> b/StdLib/LibC/Uefi/InteractiveIO/IIO.c
> index 65b61d9..362edd2 100644
> --- a/StdLib/LibC/Uefi/InteractiveIO/IIO.c
> +++ b/StdLib/LibC/Uefi/InteractiveIO/IIO.c
> @@ -177,6 +177,10 @@ IIO_Write(
> if(filp->f_iflags & _S_IWTTY) {
>// Output device expects wide characters, Output what we have
>NumWritten = filp->f_ops->fo_write(filp, NULL, NumWritten,
> gMD->UString);
> + // The function gets buf with multi-byte string but writes to the
> device
> wide-character string.
> + // So we have to return how many bytes from buf have been sent.
> + gMD->UString[NumWritten] = '\0';
> + NumWritten = (ssize_t)EstimateWtoM((const wchar_t *)gMD->UString,
> UNICODE_STRING_MAX * sizeof(wchar_t), &CharLen);
> }
> else {
>// Output device expects narrow characters, convert to MBCS
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch] AppPkg/.../Python-2.7.10: Update pyconfig for Python 2.7.10 compliance.
Jaben or Erik, could you please review the following patch? AppPkg/Applications/Python/Python-2.7.10/*/pyconfig.h: Update pyconfig for Python 2.7.10 compliance. Add new constants required for Python 2.7.10. Update package and help values. Define networking constants so that the getaddrinfo, gethostbyname, and getnameinfo functions are used from the sockets package. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel --- .../Python/Python-2.7.10/Ia32/pyconfig.h | 18 +- .../Python/Python-2.7.10/X64/pyconfig.h | 89 +++-- 2 files changed, 73 insertions(+), 34 deletions(-) diff C3 a/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h b/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h *** a/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h Tue Dec 22 16:15:45 2015 --- b/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h Sun Dec 27 15:07:14 2015 *** *** 289,295 #endif /* Define if you have the getaddrinfo function. */ ! #undef HAVE_GETADDRINFO /* Define to 1 if you have the 'getcwd' function. */ #define HAVE_GETCWD 1 --- 289,296 #endif /* Define if you have the getaddrinfo function. */ ! //#undef HAVE_GETADDRINFO ! #define HAVE_GETADDRINFO 1 /* Define to 1 if you have the 'getcwd' function. */ #define HAVE_GETCWD 1 *** *** 304,310 #undef HAVE_GETGROUPS /* Define to 1 if you have the 'gethostbyname' function. */ ! #undef HAVE_GETHOSTBYNAME /* Define this if you have some version of gethostbyname_r() */ #undef HAVE_GETHOSTBYNAME_R --- 305,312 #undef HAVE_GETGROUPS /* Define to 1 if you have the 'gethostbyname' function. */ ! //#undef HAVE_GETHOSTBYNAME ! #define HAVE_GETHOSTBYNAME 1 /* Define this if you have some version of gethostbyname_r() */ #undef HAVE_GETHOSTBYNAME_R *** *** 328,334 #undef HAVE_GETLOGIN /* Define to 1 if you have the 'getnameinfo' function. */ ! #undef HAVE_GETNAMEINFO /* Define if you have the 'getpagesize' function. */ #undef HAVE_GETPAGESIZE --- 330,337 #undef HAVE_GETLOGIN /* Define to 1 if you have the 'getnameinfo' function. */ ! //#undef HAVE_GETNAMEINFO ! #define HAVE_GETNAMEINFO 1 /* Define if you have the 'getpagesize' function. */ #undef HAVE_GETPAGESIZE diff C3 a/AppPkg/Applications/Python/X64/pyconfig.h b/AppPkg/Applications/Python/X64/pyconfig.h *** a/AppPkg/Applications/Python/X64/pyconfig.h Tue Nov 03 10:58:06 2015 --- b/AppPkg/Applications/Python/X64/pyconfig.h Sun Dec 27 15:11:17 2015 *** *** 1,6 --- 1,7 /** @file Manually generated Python Configuration file for EDK II. + Copyright (c) 2015, Daryl McDaniel. All rights reserved. Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License that accompanies this distribution. *** *** 67,72 --- 68,76 /* Define to 1 if you have the 'alarm' function. */ #undef HAVE_ALARM + /* Define to 1 if you have the header file. */ + #undef HAVE_ALLOCA_H + /* Define this if your time.h defines altzone. */ #undef HAVE_ALTZONE *** *** 109,114 --- 113,121 /* define to 1 if your sem_getvalue is broken. */ #define HAVE_BROKEN_SEM_GETVALUE 1 + /* Define if 'unsetenv' does not return an int. */ + #undef HAVE_BROKEN_UNSETENV + /* Define this if you have the type _Bool. */ #define HAVE_C99_BOOL 1 *** *** 170,179 /* Define to 1 if you have the device macros. */ #undef HAVE_DEVICE_MACROS ! /* Define if we have /dev/ptc. */ #undef HAVE_DEV_PTC ! /* Define if we have /dev/ptmx. */ #undef HAVE_DEV_PTMX /* Define to 1 if you have the header file. */ --- 177,186 /* Define to 1 if you have the device macros. */ #undef HAVE_DEVICE_MACROS ! /* Define to 1 if you have the /dev/ptc device file. */ #undef HAVE_DEV_PTC ! /* Define to 1 if you have the /dev/ptmx device file. */ #undef HAVE_DEV_PTMX /* Define to 1 if you have the header file. */ *** *** 282,288 #endif /* Define if you have the getaddrinfo function. */ ! #undef HAVE_GETADDRINFO /* Define to 1 if you have the 'getcwd' function. */ #define HAVE_GETCWD 1 --- 289,296 #endif /* Define if you have the getaddrinfo function. */ ! //#undef HAVE_GETADDRINFO ! #define HAVE_GETADDRINFO 1 /* Define to 1 if you have the 'getcwd' function. */ #define HAVE_GETCWD 1 *** *** 290,300 /* Define this if you have flockfile(), getc_unlocked(), and funlockfile() */ #undef HAVE_GETC_UNLOCKED /* Define to 1 if you have the 'getgroups' function. */ #undef HAVE_GETGROUPS /* Define to 1 if you have the &#
Re: [edk2] Double or floating point on edk2 ?
Hello, Doing floating point operations within the UEFI environment is not recommended. There are many reasons, but the main one is that floating point exceptions are unlikely to be handled. The default FPU mode (rounding, precision, ...) may also not be what you would want. There is also a chance that one or more of the UEFI functions may destroy a floating point or vector register that you are using. That said, there is nothing that would prevent you from using floating point types and operations in your Shell application. If you do, it is your responsibility to ensure that the environment is properly set up for your needs. The UEFI specification details what registers are preserved, or not. Using StdLib does not alleviate this responsibility. The only thing StdLib does is ensure that the correct rounding, floor, and NAN modes are set in the FPU in order to conform to the ISO/IEC 9899 Addendum-1 (C95) specification. The sole purpose of StdLib's floating point support is to facilitate porting existing C applications to the UEFI environment. Unfortunately, using floating point is entirely at your own risk. Sincerely, Daryl McDaniel > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Shubha > Ramani > Sent: Friday, December 04, 2015 4:39 PM > To: edk2-devel@lists.01.org > Subject: [edk2] Double or floating point on edk2 ? > > I know this question has been answered before. Do I need to convert my > application to a UEFI StdLib applicationto do double or > floating point math ? Can't do it in a regular Shell App ? > Please illuminate. > Thanks, > Shubha Shubha D. ramanishubharam...@gmail.com > shubharam...@yahoo.com > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools GCC: avoid the use of COMMON symbols
once, prior to program startup. 6.9 External definitions Syntax 1 translation-unit: external-declaration translation-unit external-declaration external-declaration: function-definition declaration Semantics 4 As discussed in 5.1.1.1, the unit of program text after preprocessing is a translation unit, which consists of a sequence of external declarations. These are described as ''external'' because they appear outside any function (and hence have file scope). As discussed in 6.7, a declaration that also causes storage to be reserved for an object or a function named by the identifier is a definition. 5 An external definition is an external declaration that is also a definition of a function (other than an inline definition) or an object. If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier; otherwise, there shall be no more than one.(140) (140) Thus, if an identifier declared with external linkage is not used in an expression, there need be no external definition for it. 6.9.2 External object definitions Semantics 2 A declaration of an identifier for an object that has file scope without an initializer, and without a storage-class specifier or with the storage-class specifier static, constitutes a tentative definition. If a translation unit contains one or more tentative definitions for an identifier, and the translation unit contains no external definition for that identifier, then the behavior is exactly as if the translation unit contains a file scope declaration of that identifier, with the composite type as of the end of the translation unit, with an initializer equal to 0. By my analysis, key items are: 1 Within the SET of TUs, each identifier with external linkage is the same object. 2 If an identifier with external linkage is not initialized, then it will be implicitly initialized to 0. 3 Within the entire program, there may be 0 or 1 initializer for an identifier with external linkage. 4 The entire SET of TUs comprising a program must be examined in order to resolve identifiers with external linkage. 5 The use, and definition, of the term "translation unit" within the C specifications is inconsistent and misleading in the presence of "libraries" and multiple source files making up a single executable program. > This patch will enforce the right behavior. > > Reviewed-by: Laszlo Ersek > > Thanks! > Laszlo I don't agree, use of -fno-common is a bad idea and does not really fix the problem. The code needs to be re-examined and fixed. > On 12/03/15 13:54, Ard Biesheuvel wrote: >> The default behavior of the GCC compiler is to emit uninitialized >> globals into a COMMON section, where duplicate definitions are merged. >> This may result in unexpected behavior, since global variables appearing >> by the same name in different C files typically do not refer to the same >> conceptual data item. If the files are being linked together, then this is exactly the correct behavior. If the variables do not refer to the "same conceptual data item" then they either have to be renamed or made static. This is a common problem when combining code that comes from multiple unrelated sources. Checking for this type of name collision should be part of the porting process. Sincerely, Daryl McDaniel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] Integrate application into Shell
Johannes,
In order for an application to use features from STDLIB, the application must
be explicitly linked with the appropriate libraries.
For applications that are built into the shell and are part of the same .efi
file the rules that apply to standalone applications
should work. The Shell and all built-in "applications" are actually a single
application.
Make sure that you are following the instructions in the ReadMe.txt file within
either of the AppPkg or StdLib packages for which
libraries to link with.
If you are still having problems, send me your .dsc and .inf files for the
modified Shell and I will see if there are any problems
there.
Sincerely,
Daryl McDaniel
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Conen,
Johannes
Sent: Monday, November 23, 2015 12:46 AM
To: edk2-devel@lists.01.org
Subject: [edk2] Integrate application into Shell
Hi everyone,
I'd like to integrate a few applications into the shell so they are directly
available when booting the shell vie PXE. One of the
applications I wanted to include in the shell is made using EADK, specifically
the socket library. I got it integrated and can run
it from the shell, however all EADK related things don't seem to work - e.g. if
I use printf(), nothing happens, the UEFI Print()
however works. Is this a mistake on my side or does EADK generally not work
when used from applications integrated into the shell? I
saw the "known issue" in the readme.txt from AppPkg ("2. Applications must be
launched from within the EFI Shell"), but thought
running it from the shell or integrating it into the shell would make no
technical difference.
Greetings
Johannes
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 3/3] AppPkg/Python-2.7.10/edk2module.c: Update for Python 2.7.10.
Hi Erik,
The commit message is wrong.
I'll fix it when I do the actual commit.
Daryl McDaniel
-Original Message-
From: Bjorge, Erik C [mailto:erik.c.bjo...@intel.com]
Sent: Friday, November 13, 2015 2:10 PM
To: Daryl McDaniel ; edk2-devel@lists.01.org;
Carsey, Jaben
Subject: RE: [edk2] [PATCH 3/3] AppPkg/Python-2.7.10/edk2module.c: Update for
Python 2.7.10.
Daryl,
It actually looks like you are adding a two blank lines instead of removing
them. Is the commit message wrong?
Thanks,
-Erik
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daryl
McDaniel
Sent: Thursday, November 12, 2015 2:53 PM
To: edk2-devel@lists.01.org; Carsey, Jaben ; Bjorge,
Erik C
Subject: [edk2] [PATCH 3/3] AppPkg/Python-2.7.10/edk2module.c: Update for
Python 2.7.10.
AppPkg/Python-2.7.10: Update file for Python-2.7.10 inclusion.
Add copyright message.
Remove some redundant blank lines.
Remove a superfluous call to setup_confname_tables(m) from INITFUNC().
Signed-off-by: Daryl McDaniel
---
.../Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
a/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
b/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
index 4cf09ca..42a9aea 100644
--- a/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
+++ b/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
@@ -2,6 +2,7 @@
OS-specific module implementation for EDK II and UEFI.
Derived from posixmodule.c in Python 2.7.2.
+Copyright (c) 2015, Daryl McDaniel. All rights reserved.
Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made
available under
the terms and conditions of the BSD License that accompanies this
distribution.
@@ -2248,6 +2249,7 @@ edk2_getpid(PyObject *self, PyObject *noargs)
return PyLong_FromPid(getpid());
}
+
#ifdef HAVE_GETLOGIN
PyDoc_STRVAR(edk2_getlogin__doc__,
"getlogin() -> string\n\n\
@@ -2340,7 +2342,6 @@ PyDoc_STRVAR(edk2_popen__doc__,
"popen(command [, mode='r' [, bufsize]]) -> pipe\n\n\
Open a pipe to/from a command returning a file object.");
-/* standard posix version of popen() support */
static PyObject *
edk2_popen(PyObject *self, PyObject *args)
{
@@ -2369,6 +2370,7 @@ edk2_popen(PyObject *self, PyObject *args)
#endif /* HAVE_POPEN */
+
#if defined(HAVE_WAIT3) || defined(HAVE_WAIT4)
static PyObject *
wait_helper(pid_t pid, int status, struct rusage *ru)
@@ -4187,9 +4189,6 @@ INITFUNC(void)
if (all_ins(m))
return;
-if (setup_confname_tables(m))
-return;
-
Py_INCREF(PyExc_OSError);
PyModule_AddObject(m, "error", PyExc_OSError);
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 0/3] AppPkg/Python-2.7.10/edk2module.c: Reviewable Revision Resubmission
AppPkg/Python-2.7.10: Present patch in three reviewable chunks. Due to the large number of changes, the previous submission of this patch was not reviewable. This patch set presents the changes as three patches, each containing a single type of change. Patch 1/3: Remove irrelevant code. Remove sections of conditional code that are not relevant to the EDK II or UEFI environments. Patch 2/3: Rename posix_ to edk2_. Rename objects beginning with posix_ to edk2_. Patch 3/3: Update for Python 2.7.10. Add copyright message. Remove some redundant blank lines. Remove a superfluous call to setup_confname_tables(m) from INITFUNC(). .../PyMod-2.7.10/Modules/edk2module.c | 5692 +--- 1 file changed, 1253 insertions(+), 4439 deletions(-) -- 1.9.5.msysgit.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 3/3] AppPkg/Python-2.7.10/edk2module.c: Update for Python 2.7.10.
AppPkg/Python-2.7.10: Update file for Python-2.7.10 inclusion.
Add copyright message.
Remove some redundant blank lines.
Remove a superfluous call to setup_confname_tables(m) from INITFUNC().
Signed-off-by: Daryl McDaniel
---
.../Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git
a/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
b/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
index 4cf09ca..42a9aea 100644
--- a/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
+++ b/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
@@ -2,6 +2,7 @@
OS-specific module implementation for EDK II and UEFI.
Derived from posixmodule.c in Python 2.7.2.
+Copyright (c) 2015, Daryl McDaniel. All rights reserved.
Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved.
This program and the accompanying materials are licensed and made
available under
the terms and conditions of the BSD License that accompanies this
distribution.
@@ -2248,6 +2249,7 @@ edk2_getpid(PyObject *self, PyObject *noargs)
return PyLong_FromPid(getpid());
}
+
#ifdef HAVE_GETLOGIN
PyDoc_STRVAR(edk2_getlogin__doc__,
"getlogin() -> string\n\n\
@@ -2340,7 +2342,6 @@ PyDoc_STRVAR(edk2_popen__doc__,
"popen(command [, mode='r' [, bufsize]]) -> pipe\n\n\
Open a pipe to/from a command returning a file object.");
-/* standard posix version of popen() support */
static PyObject *
edk2_popen(PyObject *self, PyObject *args)
{
@@ -2369,6 +2370,7 @@ edk2_popen(PyObject *self, PyObject *args)
#endif /* HAVE_POPEN */
+
#if defined(HAVE_WAIT3) || defined(HAVE_WAIT4)
static PyObject *
wait_helper(pid_t pid, int status, struct rusage *ru)
@@ -4187,9 +4189,6 @@ INITFUNC(void)
if (all_ins(m))
return;
-if (setup_confname_tables(m))
-return;
-
Py_INCREF(PyExc_OSError);
PyModule_AddObject(m, "error", PyExc_OSError);
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 2/3] AppPkg/Python-2.7.10/edk2module.c: Rename posix_ to edk2_.
AppPkg/Python-2.7.10: Rename identifiers beginning with "posix_" to "edk2_".
Rename identifiers to have an edk2_ prefix instead of posix_ in order to
conform to the convention used in other environment-specific Python modules.
This also makes the names match the module instead of implying that these are
Posix compatible routines.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel
---
.../PyMod-2.7.10/Modules/edk2module.c | 794 ++---
1 file changed, 397 insertions(+), 397 deletions(-)
diff --git
a/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
b/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
index d9d4916..4cf09ca 100644
--- a/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
+++ b/AppPkg/Applications/Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c
@@ -201,19 +201,19 @@ convertenviron(void)
/* Set a POSIX-specific error from errno, and return NULL */
static PyObject *
-posix_error(void)
+edk2_error(void)
{
return PyErr_SetFromErrno(PyExc_OSError);
}
static PyObject *
-posix_error_with_filename(char* name)
+edk2_error_with_filename(char* name)
{
return PyErr_SetFromErrnoWithFilename(PyExc_OSError, name);
}
static PyObject *
-posix_error_with_allocated_filename(char* name)
+edk2_error_with_allocated_filename(char* name)
{
PyObject *rc = PyErr_SetFromErrnoWithFilename(PyExc_OSError, name);
PyMem_Free(name);
@@ -224,7 +224,7 @@ posix_error_with_allocated_filename(char* name)
#ifndef UEFI_C_SOURCE
static PyObject *
- posix_fildes(PyObject *fdobj, int (*func)(int))
+ edk2_fildes(PyObject *fdobj, int (*func)(int))
{
int fd;
int res;
@@ -232,19 +232,19 @@ posix_error_with_allocated_filename(char* name)
if (fd < 0)
return NULL;
if (!_PyVerify_fd(fd))
- return posix_error();
+ return edk2_error();
Py_BEGIN_ALLOW_THREADS
res = (*func)(fd);
Py_END_ALLOW_THREADS
if (res < 0)
- return posix_error();
+ return edk2_error();
Py_INCREF(Py_None);
return Py_None;
}
#endif /* UEFI_C_SOURCE */
static PyObject *
-posix_1str(PyObject *args, char *format, int (*func)(const char*))
+edk2_1str(PyObject *args, char *format, int (*func)(const char*))
{
char *path1 = NULL;
int res;
@@ -255,14 +255,14 @@ posix_1str(PyObject *args, char *format, int
(*func)(const char*))
res = (*func)(path1);
Py_END_ALLOW_THREADS
if (res < 0)
-return posix_error_with_allocated_filename(path1);
+return edk2_error_with_allocated_filename(path1);
PyMem_Free(path1);
Py_INCREF(Py_None);
return Py_None;
}
static PyObject *
-posix_2str(PyObject *args,
+edk2_2str(PyObject *args,
char *format,
int (*func)(const char *, const char *))
{
@@ -279,7 +279,7 @@ posix_2str(PyObject *args,
PyMem_Free(path2);
if (res != 0)
/* XXX how to report both path1 and path2??? */
-return posix_error();
+return edk2_error();
Py_INCREF(Py_None);
return Py_None;
}
@@ -486,7 +486,7 @@ fill_time(PyObject *v, int index, time_t sec, unsigned long
nsec)
}
/* pack a system stat C structure into the Python stat tuple
- (used by posix_stat() and posix_fstat()) */
+ (used by edk2_stat() and edk2_fstat()) */
static PyObject*
_pystat_fromstructstat(STRUCT_STAT *st)
{
@@ -556,7 +556,7 @@ _pystat_fromstructstat(STRUCT_STAT *st)
}
static PyObject *
-posix_do_stat(PyObject *self, PyObject *args,
+edk2_do_stat(PyObject *self, PyObject *args,
char *format,
int (*statfunc)(const char *, STRUCT_STAT *),
char *wformat,
@@ -578,7 +578,7 @@ posix_do_stat(PyObject *self, PyObject *args,
Py_END_ALLOW_THREADS
if (res != 0) {
-result = posix_error_with_filename(pathfree);
+result = edk2_error_with_filename(pathfree);
}
else
result = _pystat_fromstructstat(&st);
@@ -589,7 +589,7 @@ posix_do_stat(PyObject *self, PyObject *args,
/* POSIX methods */
-PyDoc_STRVAR(posix_access__doc__,
+PyDoc_STRVAR(edk2_access__doc__,
"access(path, mode) -> True if granted, False otherwise\n\n\
Use the real uid/gid to test for access to a path. Note that most\n\
operations will use the effective uid/gid, therefore this routine can\n\
@@ -598,7 +598,7 @@ specified access to the path. The mode argument can be
F_OK to test\n\
existence, or the inclusive-OR of R_OK, W_OK, and X_OK.");
static PyObject *
-posix_access(PyObject *self, PyObject *args)
+edk2_access(PyObject *self, PyObject *args)
{
char *path;
int mode;
@@ -627,22 +627,22 @@ posix_access(PyObject *self, PyObject *args)
#define X_OK 1
#endif
-PyDoc_STRVAR(posix_chdir__doc__,
+PyDoc_STRVAR(edk2_chdir__doc__,
"chdir(path)\n\n\
Change
Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II
For what it's worth, here is the mail header that Outlook 2013 provided (on my system) for Laszlo's message quoted below. Note that it has both a References: header as well as a Message-ID. > Return-path: > Envelope-to: edk2-li...@mc2research.org > Delivery-date: Mon, 09 Nov 2015 13:10:01 -0500 > Received: from mx1.redhat.com ([209.132.183.28]:24154) > by host12.webserveralpha.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) > (Exim 4.85) > (envelope-from ) > id 1ZvqtD-0002R1-Qc > for edk2-li...@mc2research.org; Mon, 09 Nov 2015 13:10:01 -0500 > Received: from int-mx11.intmail.prod.int.phx2.redhat.com > (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) > by mx1.redhat.com (Postfix) with ESMTPS id 6AA2F8E233; > Mon, 9 Nov 2015 18:10:03 + (UTC) > Received: from lacos-laptop-7.usersys.redhat.com (ovpn-113-61.phx2.redhat.com > [10.3.113.61]) > by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP > id tA9IA1r0007572; > Mon, 9 Nov 2015 13:10:01 -0500 > Subject: Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II > To: Scott Duplichan , > "'Gao, Liming'" > , > "'Daryl McDaniel'" > References: <011201d11819$3c5ea660$b51bf320$@mc2research.org> > <144677372726.25731.1094579344399551208@jljusten-ivb> > <01d1183b$c03b8bc0$40b2a340$@notabs.org> > <4a89e2ef3dfedb4c8bfde51014f606a112e6b...@shsmsx102.ccr.corp.intel.com> > <000901d118a0$c906e000$5b14a000$@notabs.org> > <4a89e2ef3dfedb4c8bfde51014f606a112e75...@shsmsx102.ccr.corp.intel.com> > <01d11b00$4bdf4b50$e39de1f0$@notabs.org> > Cc: edk2-de...@ml01.01.org > From: Laszlo Ersek > Message-ID: <5640e178.8080...@redhat.com> > Date: Mon, 9 Nov 2015 19:10:00 +0100 > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 > Thunderbird/38.3.0 > MIME-Version: 1.0 > In-Reply-To: <01d11b00$4bdf4b50$e39de1f0$@notabs.org> > Content-Type: text/plain; charset=windows-1252 > Content-Transfer-Encoding: 7bit > X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 > X-Spam-Status: No, score=-5.3 > X-Spam-Score: -52 > X-Spam-Bar: - > X-Ham-Report: Spam detection software, running on the system > "host12.webserveralpha.com", > has NOT identified this incoming email as spam. The original > message has been attached to this so you can view it or label > similar future email. If you have any questions, see > root\@localhost for details. Daryl McDaniel -Original Message- From: Laszlo Ersek [mailto:ler...@redhat.com] Sent: Monday, November 09, 2015 10:10 AM To: Scott Duplichan ; 'Gao, Liming' ; 'Daryl McDaniel' Cc: edk2-de...@ml01.01.org Subject: Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II On 11/09/15 16:07, Scott Duplichan wrote: > Hello Liming, > > You are right, the select-all, paste method skips the mail header. > I don't know of a solution that retains the mail header. Here's one way. (1) Locate the email that you are interested in in the mailing list archive. If your email client lets you *see* (as in, copy & paste) the Message-Id headers of the emails in your personal mailbox, then this is trivial. Enter the following URL: http://news.gmane.org/find-root.php?message_id=X For example, the thread starter message in this thread has Message-Id <011201d11819$3c5ea660$b51bf320$@mc2research.org> And the URL is http://news.gmane.org/find-root.php?message_id=011201d11819$3c5ea660$b51bf320$@mc2research.org If your MUA doesn't expose the Message-Id to you (and I expect outlook doesn't...) then you'll simply have to browse the archive until you find the message you are looking for (or else, use the GMANE search UI, <http://search.gmane.org/>.) (2) Once you are looking at the message in the threaded view on GMANE, take note of the "direct link" in the third (= bottom most) frame. For this example, it is: http://article.gmane.org/gmane.comp.bios.edk2.devel/3918 The interesting part here is "3918". That number is the internal GMANE identifier of the message. (3) GMANE provides a dedicated download facility; see <http://gmane.org/export.php>. In this case the instructions translate to: http://download.gmane.org/gmane.comp.bios.edk2.devel/3918/3919 Because that URL instructs GMANE to export the message interval from internal ID 3918 (inclusive) to internal ID 3919 (exclusive). Such URLs should probably be fetched with some kind of download manager. I prefer "wget", but I'm not on Windows to begin with. Cygwin should have wget though. Thanks Laszlo > > Thanks, > Scott > > -Origin
Re: [edk2] [PATCH 4/4] AppPkg/Python-2.7.10: AppPkg.dsc, pyconfig.h, PyMod-2.7.10 (resend)
Ard, I am sorry if the recent Python 2.7.10 patches caused you difficulties. The structure of this patch set is a result of my lack of experience with GIT. I expect this to improve with time now that I am learning more of the limitations of GIT. So that I may learn, what would you have considered a good structure for these patches? My initial patches included a description of the changes at the beginning of each message. I was informed that this prevented applying the patches for review. So, when I resent the patches using git format-patch and git send-email those comments were removed. I have since learned that they can be added back and will be ignored by git am. The original comment from Patch 3/4 was: The edk2module.c file has been significantly modified between the Python 2.7.2 and 2.7.10 versions. Luckily, the majority of these changes are cosmetic and consist of renaming objects from "posix_*" to "edk2_*" and removing segments of code that are not relevant to the UEFI environment. Rest assured that I will resume inclusion of file-by-file descriptions of the changes in subsequent patches. Sincerely, Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Monday, November 09, 2015 8:26 AM To: Carsey, Jaben Cc: edk2-devel@lists.01.org; Bjorge, Erik C ; Daryl McDaniel Subject: Re: [edk2] [PATCH 4/4] AppPkg/Python-2.7.10: AppPkg.dsc, pyconfig.h, PyMod-2.7.10 (resend) On 9 November 2015 at 17:09, Carsey, Jaben wrote: > Reviewed-by: Jaben Carsey > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Daryl McDaniel >> Sent: Saturday, November 07, 2015 11:46 AM >> To: edk2-devel@lists.01.org; Carsey, Jaben ; >> Bjorge, Erik C >> Subject: [edk2] [PATCH 4/4] AppPkg/Python-2.7.10: AppPkg.dsc, pyconfig.h, >> PyMod-2.7.10 (resend) >> Importance: High >> >> Resent using git send-email. Maybe this will be easier to use. >> As a stakeholder in Tianocore whose understanding of AppPkg and its dependence on Python may be limited, is it too much to ask to actually *describe* what these patches change? I am not contesting that these patches are useful, it is just that they are structured very poorly, and contain no description whatsoever what the nature of the changes is. Thanks, Ard. >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Daryl McDaniel >> --- >> AppPkg/AppPkg.dsc | 5 +- >> .../Python/Python-2.7.10/Ia32/pyconfig.h | 93 >> .../Python-2.7.10/PyMod-2.7.10/Lib/ntpath.py | 30 +++- >> .../Python/Python-2.7.10/PyMod-2.7.10/Lib/os.py| 35 - >> .../Python/Python-2.7.10/PyMod-2.7.10/Lib/pydoc.py | 17 +++ >> .../Python/Python-2.7.10/PyMod-2.7.10/Lib/site.py | 165 >> ++--- >> .../Python-2.7.10/PyMod-2.7.10/Modules/_sre.c | 150 ++- >> .../Python-2.7.10/PyMod-2.7.10/Modules/addrinfo.h | 101 +++-- >> .../PyMod-2.7.10/Modules/errnomodule.c | 57 ++- >> .../PyMod-2.7.10/Modules/expat/expat_external.h| 4 +- >> .../Python-2.7.10/PyMod-2.7.10/Modules/getpath.c | 143 +- >> .../Python-2.7.10/PyMod-2.7.10/Modules/main.c | 61 >> .../PyMod-2.7.10/Modules/selectmodule.c| 43 -- >> .../PyMod-2.7.10/Modules/zlib/gzguts.h | 10 +- >> .../PyMod-2.7.10/Modules/zlib/zutil.h | 11 +- >> .../PyMod-2.7.10/Objects/longobject.c | 14 +- >> .../PyMod-2.7.10/Objects/stringlib/localeutil.h| 17 ++- >> .../PyMod-2.7.10/Python/getcopyright.c | 24 ++- >> .../Python-2.7.10/PyMod-2.7.10/Python/marshal.c| 21 ++- >> .../Python-2.7.10/PyMod-2.7.10/Python/random.c | 32 +++- >> .../Python/Python-2.7.10/X64/pyconfig.h| 63 ++-- >> 21 files changed, 640 insertions(+), 456 deletions(-) >> >> diff --git a/AppPkg/AppPkg.dsc b/AppPkg/AppPkg.dsc >> index 6db32a1..58bc84e 100644 >> --- a/AppPkg/AppPkg.dsc >> +++ b/AppPkg/AppPkg.dsc >> @@ -126,9 +126,12 @@ >>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80400040 >>} >> >> - Un-comment the following line to build Python. >> + Un-comment the following line to build Python 2.7.2. >> # AppPkg/Applications/Python/PythonCore.inf >> >> + Un-comment the following line to build Python 2.7.10. >> +# AppPkg/Applications/Python/Python-2.7.10/Python2710.inf >> + >> Un-comment the following line to build Lua. >> # AppPkg/Applications/Lua/Lua.inf
Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II
Python 2.7.10 is compatible with Python 2.7.2. Python 2.7.2 has been extensively tested within the UEFI environment and some people have a dependency on a particular version of Python so I made both versions coexist. Once Python 2.7.10 has been used by the community for a while, Python 2.7.2 will be deprecated and eventually removed from the repository. Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael Zimmermann Sent: Monday, November 09, 2015 12:20 AM To: Gao, Liming Cc: edk2-de...@ml01.01.org; Scott Duplichan ; Daryl McDaniel Subject: Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II Is Python 2.7.10 incompatible with 2.7.2 or why didn't you just update the existing port? On Mon, Nov 9, 2015 at 6:40 AM, Gao, Liming wrote: > Scott: > Thanks for your suggestion. I can select all and copy them, but I still > miss the mail header. Do you mean to get the mail header from the saved as > txt file? > > Thanks > Liming > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Scott Duplichan > > Sent: Friday, November 06, 2015 10:38 PM > > To: Gao, Liming; 'Daryl McDaniel' > > Cc: edk2-de...@ml01.01.org > > Subject: Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK > II > > > > Hello Liming, > > > > I see what you mean. With Microsoft Outlook File->Save as->Save as Txt, > > a tab is added after from:, sent:, to:, and subject:. Worse yet, the > > lines are wrapped to 78 or so columns. The only solution I have found > > is to avoid File->SaveAs altogether and instead use: > > > > Select All > > Copy > > > > ... then paste the patch into a text editor and save it that way. > > It is truly frightening to see how many data corruption methods > > Microsoft has invented. > > > > Thanks, > > Scott > > > > > > -Original Message- > > From: Gao, Liming [mailto:liming@intel.com] > > Sent: Friday, November 06, 2015 01:46 AM > > To: Scott Duplichan ; 'Daryl McDaniel' < > edk2-li...@mc2research.org> > > Cc: edk2-de...@ml01.01.org > > Subject: RE: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK > II > > > > Scott: > > When I get the mail in outlook, how I save this mail as Git patch? > > > > I try saving the mail by File->Save as->Save as Txt. I find the saved > txt file includes Tab in header and the wrapped line. It can't be > > applied as the git patch. > > > > Thanks > > Liming > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Scott Duplichan > > Sent: Friday, November 06, 2015 10:35 AM > > To: 'Daryl McDaniel' > > Cc: edk2-de...@ml01.01.org > > Subject: Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK > II > > > > Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote: > > > > ]Sent: Thursday, November 05, 2015 07:35 PM > > ]To: Daryl McDaniel ; edk2-de...@ml01.01.org; > Jaben Carsey (Intel) ]; Erik > > Bjorge (Intel) > > ]Subject: Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to > EDK II > > ] > > ]Have you considered using git? > > ] > > ]For one, EDK II is moving to git. > > ] > > ]It would have enabled you to easily generate and send the patch files > > ]for your patch series. (I am guessing you spend considerable time > > ]generating these emails, and yet, I don't think they are usable to > > ]actually apply to a tree.) > > ] > > ]I think Outlook may have munged some of the lines in your file. Some > > ]of the lines seem to have been wrapped. > > > > Correct. Daryl is using Outlook 2013, same as me. Here is a partial > > solution: In File, Options, Mail, Message Format... > > Automatically wrap text at character [Set to maximum (132)] > > Remove extra line breaks in plain text messages [Uncheck] > > Then be sure to select FORMAT TEXT, Plain Text for messages to the > > list. When typing text, put in line breaks manually. > > > > Amazing Microsoft doesn't allow disabling line wrapping altogether. > > If I remember correctly, Outlook 2007 is better. Next time I rebuild > > my drive, I am switching back to Outlook 2007. > > > > So anyway, this is not a rock solid solution. But EDK2 code doesn't > > have lines long enough to make the patch fail from wrapping to 132 > > columns. > > > > Here is a test line of length 1
[edk2] [PATCH 4/4] AppPkg/Python-2.7.10: AppPkg.dsc, pyconfig.h, PyMod-2.7.10 (resend)
Resent using git send-email. Maybe this will be easier to use. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel --- AppPkg/AppPkg.dsc | 5 +- .../Python/Python-2.7.10/Ia32/pyconfig.h | 93 .../Python-2.7.10/PyMod-2.7.10/Lib/ntpath.py | 30 +++- .../Python/Python-2.7.10/PyMod-2.7.10/Lib/os.py| 35 - .../Python/Python-2.7.10/PyMod-2.7.10/Lib/pydoc.py | 17 +++ .../Python/Python-2.7.10/PyMod-2.7.10/Lib/site.py | 165 ++--- .../Python-2.7.10/PyMod-2.7.10/Modules/_sre.c | 150 ++- .../Python-2.7.10/PyMod-2.7.10/Modules/addrinfo.h | 101 +++-- .../PyMod-2.7.10/Modules/errnomodule.c | 57 ++- .../PyMod-2.7.10/Modules/expat/expat_external.h| 4 +- .../Python-2.7.10/PyMod-2.7.10/Modules/getpath.c | 143 +- .../Python-2.7.10/PyMod-2.7.10/Modules/main.c | 61 .../PyMod-2.7.10/Modules/selectmodule.c| 43 -- .../PyMod-2.7.10/Modules/zlib/gzguts.h | 10 +- .../PyMod-2.7.10/Modules/zlib/zutil.h | 11 +- .../PyMod-2.7.10/Objects/longobject.c | 14 +- .../PyMod-2.7.10/Objects/stringlib/localeutil.h| 17 ++- .../PyMod-2.7.10/Python/getcopyright.c | 24 ++- .../Python-2.7.10/PyMod-2.7.10/Python/marshal.c| 21 ++- .../Python-2.7.10/PyMod-2.7.10/Python/random.c | 32 +++- .../Python/Python-2.7.10/X64/pyconfig.h| 63 ++-- 21 files changed, 640 insertions(+), 456 deletions(-) diff --git a/AppPkg/AppPkg.dsc b/AppPkg/AppPkg.dsc index 6db32a1..58bc84e 100644 --- a/AppPkg/AppPkg.dsc +++ b/AppPkg/AppPkg.dsc @@ -126,9 +126,12 @@ gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80400040 } - Un-comment the following line to build Python. + Un-comment the following line to build Python 2.7.2. # AppPkg/Applications/Python/PythonCore.inf + Un-comment the following line to build Python 2.7.10. +# AppPkg/Applications/Python/Python-2.7.10/Python2710.inf + Un-comment the following line to build Lua. # AppPkg/Applications/Lua/Lua.inf diff --git a/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h b/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h index 99b3422..00cfd54 100644 --- a/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h +++ b/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h @@ -1,6 +1,7 @@ /** @file Manually generated Python Configuration file for EDK II. +Copyright (c) 2015, Daryl McDaniel. All rights reserved. Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License that accompanies this distribution. @@ -67,6 +68,9 @@ /* Define to 1 if you have the 'alarm' function. */ #undef HAVE_ALARM +/* Define to 1 if you have the header file. */ +#undef HAVE_ALLOCA_H + /* Define this if your time.h defines altzone. */ #undef HAVE_ALTZONE @@ -109,6 +113,9 @@ /* define to 1 if your sem_getvalue is broken. */ #define HAVE_BROKEN_SEM_GETVALUE 1 +/* Define if 'unsetenv' does not return an int. */ +#undef HAVE_BROKEN_UNSETENV + /* Define this if you have the type _Bool. */ #define HAVE_C99_BOOL 1 @@ -170,10 +177,10 @@ /* Define to 1 if you have the device macros. */ #undef HAVE_DEVICE_MACROS -/* Define if we have /dev/ptc. */ +/* Define to 1 if you have the /dev/ptc device file. */ #undef HAVE_DEV_PTC -/* Define if we have /dev/ptmx. */ +/* Define to 1 if you have the /dev/ptmx device file. */ #undef HAVE_DEV_PTMX /* Define to 1 if you have the header file. */ @@ -274,11 +281,11 @@ #undef HAVE_GAMMA /* Define if we can use gcc inline assembler to get and set x87 control word -*/ + */ #if defined(__GNUC__) #define HAVE_GCC_ASM_FOR_X87 1 #else - #undef HAVE_GCC_ASM_FOR_X87 +#undef HAVE_GCC_ASM_FOR_X87 #endif /* Define if you have the getaddrinfo function. */ @@ -290,6 +297,9 @@ /* Define this if you have flockfile(), getc_unlocked(), and funlockfile() */ #undef HAVE_GETC_UNLOCKED +/* Define to 1 if you have the 'getentropy' function. */ +#undef HAVE_GETENTROPY + /* Define to 1 if you have the 'getgroups' function. */ #undef HAVE_GETGROUPS @@ -383,6 +393,12 @@ /* Define to 1 if you have the 'initgroups' function. */ #undef HAVE_INITGROUPS +/* Define if your compiler provides int32_t. */ +#undef HAVE_INT32_T + +/* Define if your compiler provides int64_t. */ +#undef HAVE_INT64_T + /* Define to 1 if you have the header file. */ #define HAVE_INTTYPES_H 1 @@ -479,6 +495,9 @@ /* Define to 1 if you have the 'mktime' function. */ #define HAVE_MKTIME 1 +/* Define to 1 if you have the 'mmap' function. */ +#undef HAVE_MMAP + /* Define to 1 if you have the 'mrem
Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II
Jordan, As a GIT neophyte, I would welcome any help or guidance you can give. Should I have created a remote branch on github? How does one go about splitting up the diffs so that they fit within the 400KiB limit of the list server? I have been using this port of Python 2.7.10 as a learning exercise for GIT. I have all of this in a local branch (off of master), in git. I added the text at the beginning of the patch files in the assumption that it would be helpful. Is it preferred that all explanatory text go into the 0/n file and all other files in the patch set just be raw diffs? The line wrapping is being added by lists.01.org. There is no wrapping when the mail goes out but it is wrapped when I receive the message from the listserver. A copy sent directly to me is NOT wrapped. I agree, Outlook's "Plain Text" mode is pretty screwed up. Sincerely, Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan Justen Sent: Thursday, November 05, 2015 5:35 PM To: Daryl McDaniel ; edk2-devel@lists.01.org; Jaben Carsey (Intel) ; Erik Bjorge (Intel) Subject: Re: [edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II Have you considered using git? For one, EDK II is moving to git. It would have enabled you to easily generate and send the patch files for your patch series. (I am guessing you spend considerable time generating these emails, and yet, I don't think they are usable to actually apply to a tree.) I think Outlook may have munged some of the lines in your file. Some of the lines seem to have been wrapped. You also could easily post a branch of your patches (for example, on github). Also, git send-email nicely uses the In-Reply-To email header to thread all the patches of your series together. -Jordan On 2015-11-05 14:28:01, Daryl McDaniel wrote: > AppPkg/Python-2.7.10: Patch 0 of 4 -- Introduction > > The following series of four patches detail the changes necessary to > port cPython 2.7.10 to the EDK II implementation of UEFI. > > In order to easily coexist with the Python 2.7.2 port, all files for > Python 2.7.10 are contained within > AppPkg/Applications/Python/Python-2.7.10 > Within this directory the Ia32, X64, and PyMod-2.7.10 directories > along with the Py2710ReadMe.txt, Python2710.inf, libprep.bat, and > srcprep.bat files are specific to the EDK II port. All other files > and directories are from the cPython 2.7.10 distribution. > > Files from the cPython distribution, that were not modified, are not listed. > Some files were copied from the cPython 2.7.2 port then modified for 2.7.10. > The diffs for these files are between the 2.7.2 and 2.7.10 versions. > They > are: > Python-2.7.10/Ia32/pyconfig.h > PyMod-2.7.10/Modules/edk2module.c > Python-2.7.10/X64/pyconfig.h > All other diffs are between the distribution and final files. > > Because of the large number of changes, both the diff as well as the > full file are included for: > Python-2.7.10/Py2710ReadMe.txt > Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c > Python-2.7.10/Python2710.inf > > Because they are new and small, the full file is included instead of > diffs > for: > Python-2.7.10/libprep.bat > Python-2.7.10/srcprep.bat > > > AppPkg/AppPkg.dsc |5 +- > .../Python/Python-2.7.10/Ia32/pyconfig.h | 93 +- > .../Python/Python-2.7.10/Py2710ReadMe.txt | 124 +- > .../Python-2.7.10/PyMod-2.7.10/Lib/ntpath.py | 30 +- > .../Python/Python-2.7.10/PyMod-2.7.10/Lib/os.py| 35 +- > .../Python/Python-2.7.10/PyMod-2.7.10/Lib/pydoc.py | 17 + > .../Python/Python-2.7.10/PyMod-2.7.10/Lib/site.py | 165 +- > .../Python-2.7.10/PyMod-2.7.10/Modules/_sre.c | 150 +- > .../Python-2.7.10/PyMod-2.7.10/Modules/addrinfo.h | 101 +- > .../PyMod-2.7.10/Modules/edk2module.c | 5698 > +--- > .../PyMod-2.7.10/Modules/errnomodule.c | 57 +- > .../PyMod-2.7.10/Modules/expat/expat_external.h|4 +- > .../Python-2.7.10/PyMod-2.7.10/Modules/getpath.c | 143 +- > .../Python-2.7.10/PyMod-2.7.10/Modules/main.c | 61 +- > .../PyMod-2.7.10/Modules/selectmodule.c| 43 +- > .../PyMod-2.7.10/Modules/zlib/gzguts.h | 10 +- > .../PyMod-2.7.10/Modules/zlib/zutil.h | 11 +- > .../PyMod-2.7.10/Objects/longobject.c | 14 +- > .../PyMod-2.7.10/Objects/stringlib/localeutil.h| 17 +- > .../PyMod-2.7.10/Python/getcopyright.c | 24 +- > .../Python-2.7.10/PyMod-2.7.10/Python/marshal.c| 21 +- > .../Python-2.7.10/PyMod-2.7.10/Python/random.c | 32 +- > .../Python/Python-2.7.10/Python2710.inf| 367 +- > .../Pytho
[edk2] [Patch 4/4] AppPkg/Python-2.7.10: PyMod-2.7.10
AppPkg/Python-2.7.10: Patch 4 of 4 -- PyMod-2.7.10 File diffs for the remaining files of the cPython 2.7.10 port to UEFI. AppPkg/AppPkg.dsc |5 +- .../Python/Python-2.7.10/Ia32/pyconfig.h | 93 +- .../Python-2.7.10/PyMod-2.7.10/Lib/ntpath.py | 30 +- .../Python/Python-2.7.10/PyMod-2.7.10/Lib/os.py| 35 +- .../Python/Python-2.7.10/PyMod-2.7.10/Lib/pydoc.py | 17 + .../Python/Python-2.7.10/PyMod-2.7.10/Lib/site.py | 165 +- .../Python-2.7.10/PyMod-2.7.10/Modules/_sre.c | 150 +- .../Python-2.7.10/PyMod-2.7.10/Modules/addrinfo.h | 101 +- .../PyMod-2.7.10/Modules/errnomodule.c | 57 +- .../PyMod-2.7.10/Modules/expat/expat_external.h|4 +- .../Python-2.7.10/PyMod-2.7.10/Modules/getpath.c | 143 +- .../Python-2.7.10/PyMod-2.7.10/Modules/main.c | 61 +- .../PyMod-2.7.10/Modules/selectmodule.c| 43 +- .../PyMod-2.7.10/Modules/zlib/gzguts.h | 10 +- .../PyMod-2.7.10/Modules/zlib/zutil.h | 11 +- .../PyMod-2.7.10/Objects/longobject.c | 14 +- .../PyMod-2.7.10/Objects/stringlib/localeutil.h| 17 +- .../PyMod-2.7.10/Python/getcopyright.c | 24 +- .../Python-2.7.10/PyMod-2.7.10/Python/marshal.c| 21 +- .../Python-2.7.10/PyMod-2.7.10/Python/random.c | 32 +- .../Python/Python-2.7.10/X64/pyconfig.h| 63 +- Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel diff --git a/AppPkg/AppPkg.dsc b/AppPkg/AppPkg.dsc index 6db32a1..58bc84e 100644 --- a/AppPkg/AppPkg.dsc +++ b/AppPkg/AppPkg.dsc @@ -126,9 +126,12 @@ gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80400040 } - Un-comment the following line to build Python. + Un-comment the following line to build Python 2.7.2. # AppPkg/Applications/Python/PythonCore.inf + Un-comment the following line to build Python 2.7.10. +# AppPkg/Applications/Python/Python-2.7.10/Python2710.inf + Un-comment the following line to build Lua. # AppPkg/Applications/Lua/Lua.inf diff --git a/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h b/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h index 99b3422..00cfd54 100644 --- a/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h +++ b/AppPkg/Applications/Python/Python-2.7.10/Ia32/pyconfig.h @@ -1,6 +1,7 @@ /** @file Manually generated Python Configuration file for EDK II. +Copyright (c) 2015, Daryl McDaniel. All rights reserved. Copyright (c) 2011 - 2012, Intel Corporation. All rights reserved. This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License that accompanies this distribution. @@ -67,6 +68,9 @@ /* Define to 1 if you have the 'alarm' function. */ #undef HAVE_ALARM +/* Define to 1 if you have the header file. */ +#undef HAVE_ALLOCA_H + /* Define this if your time.h defines altzone. */ #undef HAVE_ALTZONE @@ -109,6 +113,9 @@ /* define to 1 if your sem_getvalue is broken. */ #define HAVE_BROKEN_SEM_GETVALUE 1 +/* Define if 'unsetenv' does not return an int. */ +#undef HAVE_BROKEN_UNSETENV + /* Define this if you have the type _Bool. */ #define HAVE_C99_BOOL 1 @@ -170,10 +177,10 @@ /* Define to 1 if you have the device macros. */ #undef HAVE_DEVICE_MACROS -/* Define if we have /dev/ptc. */ +/* Define to 1 if you have the /dev/ptc device file. */ #undef HAVE_DEV_PTC -/* Define if we have /dev/ptmx. */ +/* Define to 1 if you have the /dev/ptmx device file. */ #undef HAVE_DEV_PTMX /* Define to 1 if you have the header file. */ @@ -274,11 +281,11 @@ #undef HAVE_GAMMA /* Define if we can use gcc inline assembler to get and set x87 control word -*/ + */ #if defined(__GNUC__) #define HAVE_GCC_ASM_FOR_X87 1 #else - #undef HAVE_GCC_ASM_FOR_X87 +#undef HAVE_GCC_ASM_FOR_X87 #endif /* Define if you have the getaddrinfo function. */ @@ -290,6 +297,9 @@ /* Define this if you have flockfile(), getc_unlocked(), and funlockfile() */ #undef HAVE_GETC_UNLOCKED +/* Define to 1 if you have the 'getentropy' function. */ +#undef HAVE_GETENTROPY + /* Define to 1 if you have the 'getgroups' function. */ #undef HAVE_GETGROUPS @@ -383,6 +393,12 @@ /* Define to 1 if you have the 'initgroups' function. */ #undef HAVE_INITGROUPS +/* Define if your compiler provides int32_t. */ +#undef HAVE_INT32_T + +/* Define if your compiler provides int64_t. */ +#undef HAVE_INT64_T + /* Define to 1 if you have the header file. */ #define HAVE_INTTYPES_H 1 @@ -479,6 +495,9 @@ /* Define to 1 if you have the 'mktime' function. */ #define HAVE_MKTIME 1 +/* Define to 1 if you have the 'mmap' function. */ +#undef HAVE_MMAP + /* Define to 1 if you have the 'mremap' function. */ #undef HAVE_MREMAP @@ -524,6 +543,9 @@ /* Define i
[edk2] [Patch 2/4] AppPkg/Python-2.7.10: New helper scripts
AppPkg/Python-2.7.10: Patch 2 of 4 -- New helper scripts New files libprep.bat and srcprep.bat are included here in their entirety, along with their diffs. The whole files are located between the " BEGIN" and " END" lines with the diffs following. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel BEGIN CUT HERE - @echo off REM libprep.bat REM REM SYNTAX: libprep REM SETLOCAL set dest=%1 echo Copying files to %dest%. echo Existing files will be overwritten. echo. PAUSE REM Copy Distro then PyMod files to the destination XCOPY Lib %dest% /S /I /Y XCOPY PyMod-2.7.10\Lib %dest% /S /I /Y echo DONE ENDLOCAL END CUT HERE - BEGIN CUT HERE - @echo off REM Prepare the Python sources for EDK II by copying REM the .h files from the PyMod tree into the Python tree. REM Directory correspondence is maintained. FOR %%d IN (Include Modules Objects Python) DO ( echo. echo Processing the %%d directory. XCOPY /S /Y /Q PyMod-2.7.10\%%d\*.h %%d ) echo. echo DONE! END CUT HERE - diff --git a/AppPkg/Applications/Python/Python-2.7.10/libprep.bat b/AppPkg/Applications/Python/Python-2.7.10/libprep.bat new file mode 100644 index 000..b623b4b --- /dev/null +++ b/AppPkg/Applications/Python/Python-2.7.10/libprep.bat @@ -0,0 +1,20 @@ +@echo off +REM libprep.bat +REM +REM SYNTAX: libprep +REM +SETLOCAL + +set dest=%1 + +echo Copying files to %dest%. +echo Existing files will be overwritten. +echo. +PAUSE + +REM Copy Distro then PyMod files to the destination +XCOPY Lib %dest% /S /I /Y +XCOPY PyMod-2.7.10\Lib %dest% /S /I /Y + +echo DONE +ENDLOCAL diff --git a/AppPkg/Applications/Python/Python-2.7.10/srcprep.bat b/AppPkg/Applications/Python/Python-2.7.10/srcprep.bat new file mode 100644 index 000..d7a5823 --- /dev/null +++ b/AppPkg/Applications/Python/Python-2.7.10/srcprep.bat @@ -0,0 +1,13 @@ +@echo off +REM Prepare the Python sources for EDK II by copying +REM the .h files from the PyMod tree into the Python tree. +REM Directory correspondence is maintained. + +FOR %%d IN (Include Modules Objects Python) DO ( + echo. + echo Processing the %%d directory. + XCOPY /S /Y /Q PyMod-2.7.10\%%d\*.h %%d +) + +echo. +echo DONE! END OF PATCH 2 of 4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch 1/4] AppPkg/Python-2.7.10: ReadMe and .inf files
AppPkg/Python-2.7.10: Patch 1 of 4 -- ReadMe and .inf files Files Py2710ReadMe.txt and Python2710.inf are included here in their entirety, along with their diffs. The whole files are located between the " BEGIN" and " END" lines with the diffs following. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel BEGIN CUT HERE - EDK II Python ReadMe Version 2.7.10 Release 1.00 3 Nov. 2015 1. OVERVIEW === This document is devoted to general information on building and setup of the Python environment for UEFI, the invocation of the interpreter, and things that make working with Python easier. It is assumed that you already have UDK2010 or later, or a current snapshot of the EDK II sources from www.tianocore.org, and that you can successfully build packages within that distribution. 2. Release Notes 1) All C extension modules must be statically linked (built in) 2) The site and os modules must exist as discrete files in ...\lib\python27.10 3) User-specific configurations are not supported. 4) Environment variables are not supported. 3. Getting and Building Python == 3.1 Getting Python == This file describes the UEFI port of version 2.7.10 of the CPython distribution. For development ease, a subset of the Python 2.7.10 distribution has been included as part of the AppPkg/Applications/Python/Python-2.7.10 source tree. If this is sufficient, you may skip to section 3.2, Building Python. If a full distribution is desired, it can be merged into the Python-2.7.10 source tree. Directory AppPkg/Applications/Python/Python-2.7.10 corresponds to the root directory of the CPython 2.7.10 distribution. The full CPython 2.7.10 source code may be downloaded from http://www.python.org/ftp/python/2.7.10/. A. Within your EDK II development tree, extract the Python distribution into AppPkg/Applications/Python/Python-2.7.10. This should merge the additional files into the source tree. It will also create the following directories: Demo Doc Grammar Mac Misc PCPCbuild RISCOS Tools The greatest change will be within the Python-2.7.10/Lib directory where many more packages and modules will be added. These additional components may not have been ported to EDK II yet. 3.2 Building Python === B. From the AppPkg/Applications/Python/Python-2.7.10 directory, execute the srcprep.bat (srcprep.sh) script to copy the header files from within the PyMod-2.7.10 sub-tree into their corresponding directories within the distribution. This step only needs to be performed prior to the first build of Python, or if one of the header files within the PyMod tree has been modified. A. Edit PyMod-2.7.10\Modules\config.c to enable the built-in modules you need. By default, it is configured for the minimally required set of modules. Mandatory Built-in Modules: edk2 errno imp marshal Additional built-in modules which are required to use the help() functionality provided by PyDoc, are: _codecs _collections_functools_random _sre_struct _weakref binascii cStringIO gc itertools math operatortime B. Edit AppPkg/AppPkg.dsc to enable (uncomment) the Python2710.inf line within the [Components] section. C. Build AppPkg using the standard "build" command: For example, to build Python for an X64 CPU architecture: build -a X64 -p AppPkg\AppPkg.dsc 4. Python-related paths and files = Python depends upon the existence of several directories and files on the target system. \EFI Root of the UEFI system area. |- \ToolsLocation of the Python.efi executable. |- \Boot UEFI specified Boot directory. |- \StdLib Root of the Standard Libraries sub-tree. |- \etc Configuration files used by libraries. |- \tmp Temporary files created by tmpfile(), etc. |- \lib Root of the libraries tree. |- \python27.10 Directory containing the Python library modules. |- \lib-dynload Dynamically loadable Python extensions. |- \site-packagesSite-specific packages and modules. NOTE: The name of the directory containing the Python library modules has changed in order to distinguish i
[edk2] [Patch 0/4] AppPkg/Python: Port Python 2.7.10 to EDK II
AppPkg/Python-2.7.10: Patch 0 of 4 -- Introduction The following series of four patches detail the changes necessary to port cPython 2.7.10 to the EDK II implementation of UEFI. In order to easily coexist with the Python 2.7.2 port, all files for Python 2.7.10 are contained within AppPkg/Applications/Python/Python-2.7.10 Within this directory the Ia32, X64, and PyMod-2.7.10 directories along with the Py2710ReadMe.txt, Python2710.inf, libprep.bat, and srcprep.bat files are specific to the EDK II port. All other files and directories are from the cPython 2.7.10 distribution. Files from the cPython distribution, that were not modified, are not listed. Some files were copied from the cPython 2.7.2 port then modified for 2.7.10. The diffs for these files are between the 2.7.2 and 2.7.10 versions. They are: Python-2.7.10/Ia32/pyconfig.h PyMod-2.7.10/Modules/edk2module.c Python-2.7.10/X64/pyconfig.h All other diffs are between the distribution and final files. Because of the large number of changes, both the diff as well as the full file are included for: Python-2.7.10/Py2710ReadMe.txt Python-2.7.10/PyMod-2.7.10/Modules/edk2module.c Python-2.7.10/Python2710.inf Because they are new and small, the full file is included instead of diffs for: Python-2.7.10/libprep.bat Python-2.7.10/srcprep.bat AppPkg/AppPkg.dsc |5 +- .../Python/Python-2.7.10/Ia32/pyconfig.h | 93 +- .../Python/Python-2.7.10/Py2710ReadMe.txt | 124 +- .../Python-2.7.10/PyMod-2.7.10/Lib/ntpath.py | 30 +- .../Python/Python-2.7.10/PyMod-2.7.10/Lib/os.py| 35 +- .../Python/Python-2.7.10/PyMod-2.7.10/Lib/pydoc.py | 17 + .../Python/Python-2.7.10/PyMod-2.7.10/Lib/site.py | 165 +- .../Python-2.7.10/PyMod-2.7.10/Modules/_sre.c | 150 +- .../Python-2.7.10/PyMod-2.7.10/Modules/addrinfo.h | 101 +- .../PyMod-2.7.10/Modules/edk2module.c | 5698 +--- .../PyMod-2.7.10/Modules/errnomodule.c | 57 +- .../PyMod-2.7.10/Modules/expat/expat_external.h|4 +- .../Python-2.7.10/PyMod-2.7.10/Modules/getpath.c | 143 +- .../Python-2.7.10/PyMod-2.7.10/Modules/main.c | 61 +- .../PyMod-2.7.10/Modules/selectmodule.c| 43 +- .../PyMod-2.7.10/Modules/zlib/gzguts.h | 10 +- .../PyMod-2.7.10/Modules/zlib/zutil.h | 11 +- .../PyMod-2.7.10/Objects/longobject.c | 14 +- .../PyMod-2.7.10/Objects/stringlib/localeutil.h| 17 +- .../PyMod-2.7.10/Python/getcopyright.c | 24 +- .../Python-2.7.10/PyMod-2.7.10/Python/marshal.c| 21 +- .../Python-2.7.10/PyMod-2.7.10/Python/random.c | 32 +- .../Python/Python-2.7.10/Python2710.inf| 367 +- .../Python/Python-2.7.10/X64/pyconfig.h| 63 +- .../Applications/Python/Python-2.7.10/libprep.bat | 20 + .../Applications/Python/Python-2.7.10/srcprep.bat | 13 + 26 files changed, 2202 insertions(+), 5116 deletions(-) In order to reduce space and download times, only a subset of Python library files, from the distribution, will be included. These are: --- encodings/importlib/ json/ pydoc_data/ xml/ _abcoll.py_weakrefset.py abc.pyargparse.py ast.pyatexit.py BaseHTTPServer.py binhex.py bisect.py calendar.py cmd.pycodecs.py collections.pycompileall.py copy.py copy_reg.py csv.pydis.py dummy_thread.py fnmatch.py fileinput.py formatter.pyfunctools.py genericpath.py getopt.py gettext.py hashlib.pyheapq.py HTMLParser.py inspect.py io.py keyword.py linecache.py locale.py md5.pymodulefinder.py ntpath.py numbers.py optparse.py os.py pkgutil.pyplatform.py pydoc.py random.py re.py repr.py runpy.py sha.py shutil.py SimpleHTTPServer.py site.py socket.py SocketServer.py sre.py sre_compile.pysre_constants.py sre_parse.py stat.py string.py StringIO.py struct.py textwrap.py token.py tokenize.py traceback.py types.pyurlparse.py UserDict.py warnings.py weakref.py xmllib.py zipfile.py END OF PATCH 0 of 4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] C Coding Standards Specification disappeared
Andrew, This has been discussed many times already, but additional feedback from the community is always welcome. >From page 1 of the "EDK II C Coding Standards Specification": These rules apply to all code developed for inclusion in the EDK II code base. All changes or additions from this point on shall conform to this specification. Pre-existing code does not need to be updated for the sole purpose of conforming to this specification. As conforming updates are made, the developer may, at her discretion, update other content within the modified file to bring it within compliance with this specification. Code originally developed for other environments, which has been ported to, or modified for, the EDK II environment does not have to conform. But, any new code added to the ported code must conform. The intent is to minimize changes while providing a path forward. Cheers, Daryl McDaniel -Original Message- From: af...@apple.com [mailto:af...@apple.com] Sent: Thursday, November 05, 2015 10:57 AM To: Mike Kinney Cc: Laszlo Ersek ; Daryl McDaniel ; edk2-devel@lists.01.org Subject: Re: [edk2] C Coding Standards Specification disappeared Mike, I think it would also be good to have a discussion about what to do when the coding style changes. For example does it mean that all the code in the repo needs to get fixed up, or does it just apply to new code. There are a lot of projects that infrequently sync with edk2 master and stay on a given official UDK 201* release for some time. Thus global formatting changes make diffing more challenging. Thanks, Andrew Fish > On Nov 5, 2015, at 10:26 AM, Kinney, Michael D wrote: > > Laszlo, > > I agree cast operators need their own rule in the coding standard. > > I prefer to use () with sizeof(). For example, some compilers do not seem to like sizeof CHAR16, but they work with sizeof (CHAR16). > > Mike > > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >> Of Laszlo Ersek >> Sent: Thursday, November 05, 2015 9:31 AM >> To: Daryl McDaniel >> Cc: 'edk2-devel@lists.01.org' >> Subject: Re: [edk2] C Coding Standards Specification disappeared >> >> On 11/05/15 18:03, Daryl McDaniel wrote: >>> Laszlo, >>> >>> The current published version of the coding standard has section >>> "5.1.1.2 Horizontal Spacing". In fact, rule 3 of section 5.1.1.2 >>> prohibits spaces between unary operators and their object. A type cast is a unary operator. >>> "3. Do not put space between unary operators and their object." >> >> I should be happy about this (because it *seems* to address what I'd >> like to see), but in fact, the cast operator is not a unary operator. >> (I had double-checked the C standard before sending my earlier email >> that I referenced in this thread.) >> >> Namely, in C99 / 6.5 Expressions, there is: >> >> - 6.5.3 Unary operators >> - 6.5.3.1 Prefix increment and decrement operators >> - 6.5.3.2 Address and indirection operators >> - 6.5.3.3 Unary arithmetic operators >> - 6.5.3.4 The sizeof operator (*) >> - 6.5.4 Cast operators >> >> And the grammar given under "6.5.4 Cast operators" is: >> >> cast-expression: >> unary-expression >> ( type-name ) cast-expression >> >> Therefore cast operators are not part of the unary operators, neither >> by the structuring of the standard, nor by the official language grammar. >> >> The same can be found in C11, and in C89 as well. (In C89, the >> section numbers are a bit different.) >> >> >> (*) Another, independent, thing that people frequently miss is that >> the parentheses are not part of the sizeof operator. They may be part >> of the >> *operand* of the sizeof operator. The standard says, >> >> The sizeof operator yields the size (in bytes) of its operand, >> which may be an expression or the parenthesized name of a type. >> >> I consistently write "sizeof variable" and "sizeof *pointer", without >> parens. Thankfully it is not forbidden by the edk2 coding style, and >> I have never received negative comments for it. I shall be watching >> the spec so that this (valid) practice remain accepted. :) >> >> Thanks! >> Laszlo >> >> >>> >>> Sincerely, >>> Daryl McDaniel >>> >>> -Original Message- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >>> Of Laszlo
Re: [edk2] C Coding Standards Specification disappeared
Actually, I am still collecting requests and adding them to the list for inclusion in the next release of the document. I had been planning on sending a new version out for review next month. Due to the appearance of this new and fully reformatted version, I may have to delay that. Suggestions and discussion of documentation changes, such as to the "EDK II C Coding Standards", is best performed on this list. That way the entire community it is addressed to has visibility and input. Thanks, Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Thursday, November 05, 2015 8:05 AM To: Kinney, Michael D ; Jarlstrom, Laurie Cc: Bruce Cran ; edk2-devel@lists.01.org ; Sheng, Cecil (HPS SW) Subject: Re: [edk2] C Coding Standards Specification disappeared On 11/05/15 16:52, Kinney, Michael D wrote: > Laszlo, > > The semi-formal way is to discuss these types of change requests on this mailing list and get agreement. > > I think your suggestion to add a new horizontal spacing rule that there should be no space between cast operator and cast operand is good. > > I will collect results of these discussions and get new versions of the document released. Awesome! :) Thanks! Laszlo > > Thanks, > > Mike > >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >> Of Laszlo Ersek >> Sent: Thursday, November 05, 2015 4:28 AM >> To: Jarlstrom, Laurie >> Cc: Bruce Cran; edk2-devel@lists.01.org; Sheng, Cecil (HPS SW) >> Subject: Re: [edk2] C Coding Standards Specification disappeared >> >> On 11/04/15 18:30, Jarlstrom, Laurie wrote: >>> Here is a link to a Draft to the 2.1 version : >> https://sourceforge.net/projects/edk2/files/Specifications/CCS_2_1_Dr >> aft.pdf/ >> download >> >> Is there a semi-formal way to provide input for this spec? >> >> Please see: >> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1881/focus=1889 >> >> Thank you, >> Laszlo >> >>> >>> thanks, >>> Laurie >>> >>> laurie.jarlst...@intel.com >>> >>> Intel SSG/STO/EBP >>> (503) 712-9395 >>> >>> >>> >>> -Original Message- >>> From: Bruce Cran [mailto:br...@cran.org.uk] >>> Sent: Wednesday, November 04, 2015 8:54 AM >>> To: Jarlstrom, Laurie; Sheng, Cecil (HPS SW); >>> edk2-devel@lists.01.org >>> Subject: Re: [edk2] C Coding Standards Specification disappeared >>> >>> On 11/4/15 9:44 AM, Jarlstrom, Laurie wrote: >>>> The Previous C Coding Standards Guide is currently being updated. >>>> A new >> revision will be posted shortly. >>> >>> Could someone post that information on the website please? >>> >>> By 'website' I guess I mean both the sourceforge _and_ github wikis, >>> since >> for some reason they're both active. >>> >>> >> >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch v2 1/1] AppPkg/Python remove improper characters from pyconfig.h
AppPkg: Within the Ia32 and X64 pyconfig.h files, there are 178 occurrences of an accent character, `, being used instead of a regular single quote, ', within comments. Replace all occurrences of ` within comments with '. Example: OLD: `foobar' NEW: 'foobar' The same changes are applied to both AppPkg/Applications/Python/Ia32/pyconfig.h and AppPkg/Applications/Python/X64/pyconfig.h. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel *** a/AppPkg/Applications/Python/X64/pyconfig.h-revBASE.svn001.tmp.hFri Mar 23 17:19:06 2012 --- b/AppPkg/Applications/Python/X64/pyconfig.h Tue Oct 20 12:43:43 2015 *** *** 58,88 the case on Motorola V4 (R40V4.2) */ #undef GETTIMEOFDAY_NO_TZ ! /* Define to 1 if you have the `acosh' function. */ #undef HAVE_ACOSH /* struct addrinfo (netdb.h) */ #undef HAVE_ADDRINFO ! /* Define to 1 if you have the `alarm' function. */ #undef HAVE_ALARM /* Define this if your time.h defines altzone. */ #undef HAVE_ALTZONE ! /* Define to 1 if you have the `asinh' function. */ #undef HAVE_ASINH /* Define to 1 if you have the header file. */ #undef HAVE_ASM_TYPES_H ! /* Define to 1 if you have the `atanh' function. */ #undef HAVE_ATANH /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3))) */ #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE ! /* Define to 1 if you have the `bind_textdomain_codeset' function. */ #undef HAVE_BIND_TEXTDOMAIN_CODESET /* Define to 1 if you have the header file. */ --- 58,88 the case on Motorola V4 (R40V4.2) */ #undef GETTIMEOFDAY_NO_TZ ! /* Define to 1 if you have the 'acosh' function. */ #undef HAVE_ACOSH /* struct addrinfo (netdb.h) */ #undef HAVE_ADDRINFO ! /* Define to 1 if you have the 'alarm' function. */ #undef HAVE_ALARM /* Define this if your time.h defines altzone. */ #undef HAVE_ALTZONE ! /* Define to 1 if you have the 'asinh' function. */ #undef HAVE_ASINH /* Define to 1 if you have the header file. */ #undef HAVE_ASM_TYPES_H ! /* Define to 1 if you have the 'atanh' function. */ #undef HAVE_ATANH /* Define if GCC supports __attribute__((format(PyArg_ParseTuple, 2, 3))) */ #undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE ! /* Define to 1 if you have the 'bind_textdomain_codeset' function. */ #undef HAVE_BIND_TEXTDOMAIN_CODESET /* Define to 1 if you have the header file. */ *** *** 112,139 /* Define this if you have the type _Bool. */ #define HAVE_C99_BOOL 1 ! /* Define to 1 if you have the `chflags' function. */ #undef HAVE_CHFLAGS ! /* Define to 1 if you have the `chown' function. */ #undef HAVE_CHOWN /* Define if you have the 'chroot' function. */ #undef HAVE_CHROOT ! /* Define to 1 if you have the `clock' function. */ #define HAVE_CLOCK1 ! /* Define to 1 if you have the `confstr' function. */ #undef HAVE_CONFSTR /* Define to 1 if you have the header file. */ #undef HAVE_CONIO_H ! /* Define to 1 if you have the `copysign' function. */ #undef HAVE_COPYSIGN ! /* Define to 1 if you have the `ctermid' function. */ #undef HAVE_CTERMID /* Define if you have the 'ctermid_r' function. */ --- 112,139 /* Define this if you have the type _Bool. */ #define HAVE_C99_BOOL 1 ! /* Define to 1 if you have the 'chflags' function. */ #undef HAVE_CHFLAGS ! /* Define to 1 if you have the 'chown' function. */ #undef HAVE_CHOWN /* Define if you have the 'chroot' function. */ #undef HAVE_CHROOT ! /* Define to 1 if you have the 'clock' function. */ #define HAVE_CLOCK1 ! /* Define to 1 if you have the 'confstr' function. */ #undef HAVE_CONFSTR /* Define to 1 if you have the header file. */ #undef HAVE_CONIO_H ! /* Define to 1 if you have the 'copysign' function. */ #undef HAVE_COPYSIGN ! /* Define to 1 if you have the 'ctermid' function. */ #undef HAVE_CTERMID /* Define if you have the 'ctermid_r' function. */ *** *** 151,169 /* Define if you have the 'resize_term' function. */ #undef HAVE_CURSES_RESIZE_TERM ! /* Define to 1 if you have the declaration of `isfinite', and to 0 if you don't. */ #define HAVE_DECL_ISFINITE0 ! /* Define to 1 if you have the declaration of `isinf', and to 0 if you don't. */ #define HAVE_DECL_ISINF 1 ! /* Define to 1 if you have the declaration of `isnan', and to 0 if you don't. */ #define HAVE_DECL_ISNAN 1 ! /* Define to 1 if you have the declaration of `tzname', and to 0 if you don't. */ #define
[edk2] [Patch 1/1] AppPkg/Python remove improper characters from pyconfig.h
AppPkg: Within the Ia32 and X64 pyconfig.h files, there are 178 occurrences of an accent character, `, being used instead of a regular single quote, ', within comments. Replace all occurrences of ` within comments with '. Example: OLD: `foobar' NEW: 'foobar' The same changes are applied to both AppPkg/Applications/Python/Ia32/pyconfig.h and AppPkg/Applications/Python/X64/pyconfig.h. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Daryl McDaniel Changes are detailed in the attached patch file. Sincerely, Daryl McDaniel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH 1/1] AppPkg: Allow interactive Python on platforms without STDERR
AppPkg: Python, as distributed, sends its prompts and other interactive
output to stderr, which uses the platforms STDERR device for output. If
STDERR output is not visible, it may appear that Python has hung. Several
people have reported problems on platforms that don't enable STDERR. These
include platforms without a Setup utility and those without Setup options
for STDERR.
This patch adds a command-line switch, -#, to Python. If this switch is
present, stderr will be aliased to stdout.
AppPkg/Applications/Python/PyMod-2.7.2/Modules/main.c: New file, modified
version of AppPkg/Applications/Python/Python-2.7.2/Modules/main.c. Add the
-# option which causes stderr to be aliased to stdout. Add a description of
this switch to the Help output.
AppPkg/Applications/Python/PythonCore.inf: Reference main.c from
PyMod-2.7.2 instead of from Python-2.7.2 so that the modified version is
used.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Daryl McDaniel
diff C3b Temp/PythonCore.inf-revBASE.svn001.tmp.inf
AppPkg/Applications/Python/PythonCore.inf
*** Temp/PythonCore.inf-revBASE.svn001.tmp.inf Thu Sep 18 12:13:22 2014
--- AppPkg/Applications/Python/PythonCore.inf Fri Oct 16 14:15:13 2015
***
*** 1,6
--- 1,7
## @file
# PythonCore.inf
#
+ # Copyright (c) 2015, Daryl McDaniel. All rights reserved.
# Copyright (c) 2011-2012, Intel Corporation. All rights reserved.
# This program and the accompanying materials
# are licensed and made available under the terms and conditions of the
BSD License
***
*** 164,170
Python-$(PYTHON_VERSION)/Modules/_functoolsmodule.c
Python-$(PYTHON_VERSION)/Modules/gcmodule.c
Python-$(PYTHON_VERSION)/Modules/getbuildinfo.c
! Python-$(PYTHON_VERSION)/Modules/main.c
Python-$(PYTHON_VERSION)/Modules/python.c
# Optional Modules -- See Python/Efi/config.c
--- 165,171
Python-$(PYTHON_VERSION)/Modules/_functoolsmodule.c
Python-$(PYTHON_VERSION)/Modules/gcmodule.c
Python-$(PYTHON_VERSION)/Modules/getbuildinfo.c
! PyMod-$(PYTHON_VERSION)/Modules/main.c
Python-$(PYTHON_VERSION)/Modules/python.c
# Optional Modules -- See Python/Efi/config.c
diff C3b a/AppPkg/Applications/Python/Python-2.7.2/Modules/main.c
b/AppPkg/Applications/Python/PyMod-2.7.2/Modules/main.c
*** a/AppPkg/Applications/Python/Python-2.7.2/Modules/main.c Thu Oct 15
13:08:22 2015
--- b/AppPkg/Applications/Python/PyMod-2.7.2/Modules/main.c Fri Oct 16
15:08:08 2015
***
*** 1,4
! /* Python interpreter main program */
#include "Python.h"
#include "osdefs.h"
--- 1,8
! /** @file
! Python interpreter main program.
!
! Copyright (c) 2015, Daryl McDaniel. All rights reserved.
! **/
#include "Python.h"
#include "osdefs.h"
***
*** 40,46
static int orig_argc;
/* command line options */
! #define BASE_OPTS "3bBc:dEhiJm:OQ:sStuUvVW:xX?"
#ifndef RISCOS
#define PROGRAM_OPTS BASE_OPTS
--- 44,50
static int orig_argc;
/* command line options */
! #define BASE_OPTS "#3bBc:dEhiJm:OQ:sStuUvVW:xX?"
#ifndef RISCOS
#define PROGRAM_OPTS BASE_OPTS
***
*** 59,64
--- 63,69
/* Long usage message, split into parts < 512 bytes */
static char *usage_1 = "\
Options and arguments (and corresponding environment variables):\n\
+ -# : alias stderr to stdout for platforms without STDERR output.\n\
-B : don't write .py[co] files on import; also
PYTHONDONTWRITEBYTECODE=x\n\
-c cmd : program passed in as string (terminates option list)\n\
-d : debug output from parser; also PYTHONDEBUG=x\n\
***
*** 99,105
static char *usage_5 = "\
PYTHONHOME : alternate directory (or
%c).\n\
The default module search path uses %s.\n\
! PYTHONCASEOK : ignore case in 'import' statements (Windows).\n\
PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
";
--- 104,110
static char *usage_5 = "\
PYTHONHOME : alternate directory (or
%c).\n\
The default module search path uses %s.\n\
! PYTHONCASEOK : ignore case in 'import' statements (UEFI default).\n\
PYTHONIOENCODING: Encoding[:errors] used for stdin/stdout/stderr.\n\
";
***
*** 241,246
--- 246,252
int help = 0;
int version = 0;
int saw_unbuffered_flag = 0;
+ int saw_pound_flag = 0;
PyCompilerFlags cf;
cf.cf_flags = 0;
***
*** 389,394
--- 395,409
PySys_AddWarnOption(_PyOS_optarg);
break;
+ case '#':
+ if (saw_pound_flag == 0) {
+ if(freopen("stdout:", "w", stde
Re: [edk2] [PATCH v2 1/6] StdLib: remove mention of ARMGCC
Reviewed-by: Daryl McDaniel >From a StdLib point-of-view, the patch to StdLib.inc looks fine. I'll wait for approval of the other parts of the patch before committing these changes. Daryl -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Tuesday, August 11, 2015 4:15 AM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; yingke.d@intel.com Cc: Jaben Carsey ; jordan.l.jus...@intel.com; Daryl McDaniel ; Ard Biesheuvel Subject: [edk2] [PATCH v2 1/6] StdLib: remove mention of ARMGCC The ARMGCC toolchain will be removed, and so will the build rule family by the same name. So remove the BuildOptions specific to ARMGCC. Cc: Daryl McDaniel Cc: Jaben Carsey Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel Acked-by: Daryl McDaniel --- StdLib/StdLib.inc | 2 -- 1 file changed, 2 deletions(-) diff --git a/StdLib/StdLib.inc b/StdLib/StdLib.inc index 9d540abd9221..fff9ef05e61f 100644 --- a/StdLib/StdLib.inc +++ b/StdLib/StdLib.inc @@ -122,7 +122,6 @@ MSFT:*_*_IA32_CC_FLAGS = /Od /D UEFI_C_SOURCE GCC:*_*_IA32_CC_FLAGS = -O0 -DUEFI_C_SOURCE RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm - ARMGCC:*_*_*_CC_FLAGS = -O0 -DUEFI_C_SOURCE -Wno-unknown-pragmas -Wno-unused -Wno-format-zero-length XCODE:*_*_*_CC_FLAGS = -O0 -DUEFI_C_SOURCE -Wno-unused-const-variable -Wno-string-compare -Wno-sometimes-uninitialized !else @@ -132,6 +131,5 @@ MSFT:*_*_*_CC_FLAGS = /X /Zc:wchar_t /D UEFI_C_SOURCE GCC:*_*_*_CC_FLAGS = -nostdinc -nostdlib -DUEFI_C_SOURCE RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm - ARMGCC:*_*_*_CC_FLAGS = -nostdinc -nostdlib -DUEFI_C_SOURCE -Wno-unknown-pragmas -Wno-unused -Wno-format-zero-length XCODE:*_*_*_CC_FLAGS = -nostdinc -nostdlib -DUEFI_C_SOURCE -Wno-unused-const-variable -Wno-string-compare -Wno-sometimes-uninitialized !endif -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/5] StdLib: remove mention of ARMGCC
Ard, Thank you for the patch. I'll get it applied today. Daryl -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Monday, August 10, 2015 6:08 AM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; yingke.d@intel.com Cc: jordan.l.jus...@intel.com; Ard Biesheuvel ; Daryl McDaniel ; Jaben Carsey Subject: [PATCH 1/5] StdLib: remove mention of ARMGCC The ARMGCC toolchain will be removed, and so will the build rule family by the same name. So remove the BuildOptions specific to ARMGCC. Cc: Daryl McDaniel Cc: Jaben Carsey Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- StdLib/StdLib.inc | 2 -- 1 file changed, 2 deletions(-) diff --git a/StdLib/StdLib.inc b/StdLib/StdLib.inc index 9d540abd9221..fff9ef05e61f 100644 --- a/StdLib/StdLib.inc +++ b/StdLib/StdLib.inc @@ -122,7 +122,6 @@ MSFT:*_*_IA32_CC_FLAGS = /Od /D UEFI_C_SOURCE GCC:*_*_IA32_CC_FLAGS = -O0 -DUEFI_C_SOURCE RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm - ARMGCC:*_*_*_CC_FLAGS = -O0 -DUEFI_C_SOURCE -Wno-unknown-pragmas -Wno-unused -Wno-format-zero-length XCODE:*_*_*_CC_FLAGS = -O0 -DUEFI_C_SOURCE -Wno-unused-const-variable -Wno-string-compare -Wno-sometimes-uninitialized !else @@ -132,6 +131,5 @@ MSFT:*_*_*_CC_FLAGS = /X /Zc:wchar_t /D UEFI_C_SOURCE GCC:*_*_*_CC_FLAGS = -nostdinc -nostdlib -DUEFI_C_SOURCE RVCT:*_*_*_CC_FLAGS = --library_interface=none -DUEFI_C_SOURCE -J$(WORKSPACE)/StdLib/Include -J$(WORKSPACE)/StdLib/Include/Arm - ARMGCC:*_*_*_CC_FLAGS = -nostdinc -nostdlib -DUEFI_C_SOURCE -Wno-unknown-pragmas -Wno-unused -Wno-format-zero-length XCODE:*_*_*_CC_FLAGS = -nostdinc -nostdlib -DUEFI_C_SOURCE -Wno-unused-const-variable -Wno-string-compare -Wno-sometimes-uninitialized !endif -- 1.9.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 2/2] Update copyright info, use BDS license.
The copyright information was incorrectly updated. The correct copyright is: Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved. Previous copyrights must be maintained. This patch should be rejected and a new one submitted with the corrected copyright notice and subject line. Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard Biesheuvel Sent: Thursday, July 30, 2015 12:27 AM To: Eric Dong Cc: Ruiyu Ni ; edk2-devel@lists.01.org; Gao, Liming Subject: Re: [edk2] [Patch 2/2] Update copyright info, use BDS license. On 29 July 2015 at 10:59, Eric Dong wrote: > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Eric Dong The license is called 'BSD' not 'BDS' Could you fix up the commit titles please? -- Ard. > --- > .../Include/Guid/HiiBootMaintenanceFormset.h | 28 ++ > 1 file changed, 12 insertions(+), 16 deletions(-) > > diff --git a/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h > b/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h > index 7c809f4..393cc95 100644 > --- a/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h > +++ b/MdeModulePkg/Include/Guid/HiiBootMaintenanceFormset.h > @@ -1,25 +1,21 @@ > // > -// This file contains 'Framework Code' and is licensed as such -// > under the terms of your license agreement with Intel or your -// > vendor. This file may not be modified, except as allowed by -// > additional terms of your license agreement. > -// > -/**@file > -Constants and declarations that are common accross PEI and DXE. > - > -Copyright (c) 2011, Intel Corporation. All rights reserved. -This > software and associated documentation (if any) is furnished -under a > license and may only be used or copied in accordance -with the terms > of the license. Except as permitted by such -license, no part of this > software or documentation may be -reproduced, stored in a retrieval > system, or transmitted in any -form or by any means without the > express written consent of -Intel Corporation. > +/** @file > + Guid definition for Boot Maintainence Formset. > + > +Copyright (c) 2015, Intel Corporation. All rights reserved. This > +program and the accompanying materials are licensed and made > +available under the terms and conditions of the BSD License which > +accompanies this distribution. The full text of the license may be > +found at http://opensource.org/licenses/bsd-license.php > + > +THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, > +WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. > > **/ > > + > #ifndef __HII_BOOT_MAINTENANCE_FORMSET_H__ > #define __HII_BOOT_MAINTENANCE_FORMSET_H__ > > /// > /// Guid define to group the item show on the Boot Menaintenance Manager Menu. > -- > 1.9.5.msysgit.1 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] StdLib: Add ARM SoftFloat & AArch64 supports
Now that we have received legal approval of the LLVM / University of Illinois license, I can say that this set of patches looks OK to me. 0. [PATCH 0/4] StdLib: Add ARM SoftFloat & AArch64 supports 1. [PATCH 1/4] StdLib: Added BaseStackLib for ARM architectures 2. [PATCH 2/4] StdLib/LibC: Add software floating point library from NetBSD 3. [PATCH 3/4] StdLib/LibC: Provide missing ARM symbols 4. [PATCH 4/4] StdLib: Add support for AArch64 Reviewed by: Daryl McDaniel Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Olivier Martin Sent: Thursday, July 16, 2015 6:52 AM To: daryl.mcdan...@intel.com Cc: bill.fletc...@linaro.org; edk2-de...@ml01.01.org; edk2-de...@lists.sourceforge.net; Olivier Martin Subject: [edk2] [PATCH 0/4] StdLib: Add ARM SoftFloat & AArch64 supports This patchset adds support for ARM SoftFloat. ARM Hardware floating point is disabled when building UEFI Firmware. Software Floating point is required to get full StdLib support. This support also adds AArch64 support. Contributed-under: TianoCore Contribution Agreement 1.0 Reviewed-by: Olivier Martin Brendan Jackman (1): StdLib: Add support for AArch64 Harry Liebel (2): StdLib/LibC: Add software floating point library from NetBSD StdLib/LibC: Provide missing ARM symbols Olivier Martin (1): StdLib: Added BaseStackLib for ARM architectures StdLib/Include/Aarch64/arm-gcc.h | 110 + StdLib/Include/Aarch64/machine/ansi.h | 106 + StdLib/Include/Aarch64/machine/bswap.h | 13 + StdLib/Include/Aarch64/machine/byte_swap.h | 63 + StdLib/Include/Aarch64/machine/endian.h|3 + StdLib/Include/Aarch64/machine/endian_machdep.h|3 + StdLib/Include/Aarch64/machine/fenv.h | 39 + StdLib/Include/Aarch64/machine/float.h | 59 + StdLib/Include/Aarch64/machine/ieee.h | 31 + StdLib/Include/Aarch64/machine/ieeefp.h| 45 + StdLib/Include/Aarch64/machine/int_const.h | 63 + StdLib/Include/Aarch64/machine/int_limits.h| 127 + StdLib/Include/Aarch64/machine/int_mwgwtypes.h | 82 + StdLib/Include/Aarch64/machine/int_types.h | 61 + StdLib/Include/Aarch64/machine/limits.h| 100 + StdLib/Include/Aarch64/machine/math.h |3 + StdLib/Include/Aarch64/machine/param.h | 124 + StdLib/Include/Aarch64/machine/signal.h| 22 + StdLib/Include/Aarch64/machine/types.h | 82 + StdLib/Include/Aarch64/milieu.h| 52 + StdLib/Include/Aarch64/softfloat.h | 316 ++ StdLib/Include/Arm/arm-gcc.h | 114 + StdLib/Include/Arm/machine/fenv.h | 55 + StdLib/Include/Arm/machine/ieeefp.h| 58 + StdLib/Include/Arm/milieu.h| 38 + StdLib/Include/Arm/softfloat.h | 316 ++ StdLib/Include/ieeefp.h| 46 + StdLib/LibC/LibC.inf |5 + StdLib/LibC/Main/Arm/fixunsdfsi.c | 74 + StdLib/LibC/Main/Arm/floatunsidf.c | 71 + StdLib/LibC/Main/Arm/fp_lib.h | 282 + StdLib/LibC/Main/Arm/int_endianness.h | 71 + StdLib/LibC/Main/Arm/int_lib.h | 105 + StdLib/LibC/Main/Arm/int_types.h | 170 + StdLib/LibC/Main/Arm/int_util.h| 68 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmpeq.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmpge.c | 35 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmpgt.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmple.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmplt.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_dcmpun.c | 42 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmpeq.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmpge.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmpgt.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmple.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmplt.c | 37 + StdLib/LibC/Softfloat/Arm/__aeabi_fcmpun.c | 42 + StdLib/LibC/Softfloat/Makefile.inc | 42 + StdLib/LibC/Softfloat/README.NetBSD|8 + StdLib/LibC/Softfloat/README.txt | 39 + StdLib/LibC/Softfloat/Softfloat.inf| 74 + StdLib/LibC/Softfloat/bits32/softfloat-macros | 648 +++ StdLib/LibC/Softfloat/bits32/softfloat.c | 2355 StdLib/LibC/Softfloat/bits64/softfloat-macros | 745 +++ StdLib/LibC/Softfloat/bits64/softfloat.c | 5602 StdLib/LibC/Softfloat/eqdf2.c | 38 + StdLib/LibC/Softfloat/eqsf2.c | 38 + StdLib/LibC/Softfloat
Re: [edk2] TianoCore Subversion down?
Thank you Jordan and Laszlo for all of the great work you put into this. Daryl -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo Ersek Sent: Sunday, July 26, 2015 2:43 AM To: Jordan Justen Cc: Bruce Cran ; edk2-devel@lists.01.org ; Blibbet ; Gao, Liming ; Ard Biesheuvel Subject: Re: [edk2] TianoCore Subversion down? On 07/26/15 10:23, Jordan Justen wrote: > On 2015-07-25 19:59:10, Bruce Cran wrote: >> On 7/24/15 5:40 PM, Jordan Justen wrote: >>> Unfortunately, it looks like they are going to manage to get svn back >>> up and running. ;) >> >> It looks like it's back: >> http://sourceforge.net/blog/sourceforge-subversion-svn-service-online/ >> >> "SourceForge-hosted Allura-backed Subversion (SVN) repositories have >> been restored to service as of 7/25." > > Well, they certainly tried to make it difficult for us. The restored > repo was missing r18015-18032. Luckily thanks to git (and git-svn), I > was able to restore them fairly easily. :) Yay! :) > We also lucked out in that I was able to restore things before anyone > else tried to commit. So, basically we don't have two versions of > r18015-18032. Phew. That was close. Sometimes working at night, when the streets are silent and the people asleep, has bonuses. Everyone, give this man a medal. :) > >> Now the question is whether we switch back to SF or continue using >> Github :) > > Well ... I still think we're going to have to go back for now. +1 > I think > the question has moved from *if* we'll move to git, to *when* will we > move. Considering I've been running the git-svn mirror since 2009, > I'll take this as a great step forward. :) > > Hopefully this incident will highlight how much more stable git is > based on its distributed nature. Thank you very much for being such a good shepherd of our SVN and git repos. Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] StdLib: Do not define memcpy for AARCH64 builds
Reviewed by: Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Scott Duplichan Sent: Thursday, July 23, 2015 1:19 PM To: edk2-devel@lists.01.org Cc: 'Daryl Mcdaniel' Subject: [edk2] [PATCH] StdLib: Do not define memcpy for AARCH64 builds For AARCH64, do not define a memcpy function in stdlib because it is already defined in CompilerIntrinsicsLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Scott Duplichan --- StdLib/LibC/String/Copying.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/StdLib/LibC/String/Copying.c b/StdLib/LibC/String/Copying.c index e27519e..96be24b 100644 --- a/StdLib/LibC/String/Copying.c +++ b/StdLib/LibC/String/Copying.c @@ -19,12 +19,12 @@ #include #include -/** Do not define memcpy for IPF+GCC or ARM+GCC builds. +/** Do not define memcpy for IPF+GCC or ARM/AARCH64+GCC builds. For IPF, using a GCC compiler, the memcpy function is converted to CopyMem by objcpy during build. -For ARM, the memcpy function is provided by the CompilerIntrinsics library. +For ARM/AARCH64, the memcpy function is provided by the CompilerIntrinsics library. **/ -#if !((defined(MDE_CPU_IPF) || defined(MDE_CPU_ARM)) && defined(__GNUC__)) +#if !((defined(MDE_CPU_IPF) || defined(MDE_CPU_ARM) || defined(MDE_CPU_AARCH64)) && defined(__GNUC__)) /** The memcpy function copies n characters from the object pointed to by s2 into the object pointed to by s1. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] StdLib: Added BaseStackLib for ARM architectures
Thank you Scott, I await your patches. Sincerely, Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Scott Duplichan Sent: Thursday, July 23, 2015 12:02 PM To: 'Laszlo Ersek'; 'Carsey, Jaben'; 'Mcdaniel, Daryl' Cc: 'Jordan Justen (Intel address)'; 'edk2-devel-01'; 'Brendan Jackman'; 'Harry Liebel' Subject: Re: [edk2] [PATCH] StdLib: Added BaseStackLib for ARM architectures Laszlo Ersek [mailto:ler...@redhat.com] wrote: ]Sent: Thursday, July 23, 2015 09:47 AM ]To: Carsey, Jaben ; Mcdaniel, Daryl ]Cc: Jordan Justen (Intel address) ; edk2-devel-01 ; ]Brendan Jackman ; Harry Liebel ]Subject: Re: [edk2] [PATCH] StdLib: Added BaseStackLib for ARM architectures ] ]On 07/16/15 23:28, Carsey, Jaben wrote: ]> Reviewed-by: Jaben Carsey ] ]I'm rounding up patches for Jordan to queue up in the new (temporary) ]git repo. And, this patch looked like a candidate ready for merging. ] ]However, it doesn't apply. The reason is that Olivier submitted this ]patch on top of his ] ] [edk2] [PATCH 0/4] StdLib: Add ARM SoftFloat & AArch64 supports ] ]series -- hence the "StdLib/LibC/Softfloat/Softfloat.inf" lines in the ]context of this patch. That 4-part patch series is not ready for merging ]yet (it lacks reviews), and I'm not sure if without that patch series, ]it is valid to rework this patch, ie. drop the Softfloat context, and ]just add BaseStackCheckLib. Speaking of "StdLib: Add ARM SoftFloat & AArch64 supports", I did a build-only test using the Windows hosted GCC44-GCC49 tool chains. The 36 combinations of: AppPkg GCC44, GCC45, GCC46, GCC47, GCC48, GCC49 DEBUG, RELEASE, NOOPT ARM, AARCH64 ... build successfully after making two small changes: I will send patches for the changes. They are 1) Add some missing NOOPT_ lines where only DEBUG and RELEASE are given. 2) Line 27 of Copying.c: Add AARCH64 to the list of targets that already define memcpy in the intrinsics lib. This was a build-only test. Thanks, Scott ]So, I am *not* including this patch for now. It should be either ]reposted by an ARM expert without the softfloat context, or the ]softfloat dependency should be spelled out clearly in the commit message ](or in a separate blurb). ] ]Thanks ]Laszlo ] > >> -Original Message- >> From: Olivier Martin [mailto:olivier.mar...@arm.com] >> Sent: Tuesday, July 14, 2015 9:26 AM >> To: Mcdaniel, Daryl >> Cc: edk2-de...@lists.sourceforge.net >> Subject: [edk2] [PATCH] StdLib: Added BaseStackLib for ARM >> architectures >> >> Stack protection support is required when building with ARM/AArch64 GCC. >> >> Contributed-under: TianoCore Contribution Agreement 1.0 >> Signed-off-by: Olivier Martin >> --- >> StdLib/StdLib.inc | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/StdLib/StdLib.inc b/StdLib/StdLib.inc index >> 51aeefa..7ee2e0a 100644 >> --- a/StdLib/StdLib.inc >> +++ b/StdLib/StdLib.inc >> @@ -74,10 +74,16 @@ >>NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf >>NULL|StdLib/LibC/Softfloat/Softfloat.inf >> >> + # Add support for GCC stack protector >> + NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf >> + >> [LibraryClasses.AARCH64] >># Use the softfloat library to cover missing hardfloat operations. >>NULL|StdLib/LibC/Softfloat/Softfloat.inf >> >> + # Add support for GCC stack protector >> + NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf >> + >> [Components] >> # BaseLib and BaseMemoryLib need to be built with the /GL- switch >> when using the Microsoft # tool chain. This is required so that the >> library functions can be resolved during >> -- >> 2.1.1 >> >> >> - >> - Don't Limit Your Business. Reach for the Cloud. >> GigeNET's Cloud Solutions provide you with the tools and support that >> you need to offload your IT needs and focus on growing your business. >> Configured For All Businesses. Start Your Cloud Today. >> https://www.gigenetcloud.com/ >> ___ >> edk2-devel mailing list >> edk2-de...@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/edk2-devel > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] TianoCore Subversion down?
I agree with both Jaben and Jordan. I don't think the change was critical for the repo, but it was of interest to me since I had intended to continue supporting the StdLib triumvirate: AppPkg, StdLIb, StdLibPrivateInternalFiles. Daryl McDaniel -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Carsey, Jaben Sent: Wednesday, July 22, 2015 5:57 PM To: Justen, Jordan L; Bruce Cran; Laszlo Ersek; Ard Biesheuvel Cc: Carsey, Jaben; Blibbet; edk2-devel@lists.01.org; Gao, Liming Subject: Re: [edk2] TianoCore Subversion down? I meant interesting in terms of criticality for the repo... the change could be redone easily... >-Original Message- >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >Jordan Justen >Sent: Wednesday, July 22, 2015 4:46 PM >To: Carsey, Jaben; Bruce Cran; Laszlo Ersek; Ard Biesheuvel >Cc: Carsey, Jaben; Blibbet; edk2-devel@lists.01.org; Gao, Liming >Subject: Re: [edk2] TianoCore Subversion down? >Importance: High > >On 2015-07-22 13:42:05, Carsey, Jaben wrote: >> 18032 was just a change to maintainers.txt by me replacing Daryl as >> the maintainer of a few packages with myself. I can send it if >> necessary, but I'd say it's pretty uninteresting really... > >It doesn't seem uninteresting to me. I think we should send out code >review patches for changes to Maintainers.txt. But, I don't think >there's a need to send it out now. > >-Jordan > >> > -Original Message- >> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf >> > Of Bruce Cran >> > Sent: Wednesday, July 22, 2015 4:51 AM >> > To: Laszlo Ersek ; Ard Biesheuvel >> > ; Justen, Jordan L >> > >> > Cc: Blibbet ; edk2-devel@lists.01.org > > de...@ml01.01.org>; Gao, Liming >> > Subject: Re: [edk2] TianoCore Subversion down? >> > >> > On 7/22/15 4:18 AM, Laszlo Ersek wrote: >> > >> > > My personal git-svn clone has only r18027. Anyone got anything >> > > newer >> > than r18030? >> > >> > From https://edk2.bluestop.org/diffusion/EDK/history/ there was also: >> > >> > r18031 MdeModulePkg PiSmmCore: Remove a hidden assumption of SMRAM >> > reservation >> > >> > r18032 Daryl has changed positions and I am taking over maintaining for now. >> > >> > -- >> > Bruce >> > ___ >> > edk2-devel mailing list >> > edk2-devel@lists.01.org >> > https://lists.01.org/mailman/listinfo/edk2-devel >___ >edk2-devel mailing list >edk2-devel@lists.01.org >https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
