EmulatorPkg does not unload DLL after exit

EmulatorPkg does not unload DLL after exit

[Tim Lewis]

[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]

When running a shell app twice, I ran into an interesting problem: global variables that had initializers were not initialized to the defaults specified in the source. Running the same shell app under the old NT32 seems to work. It turns out that the shell app was not being reloaded, but rather being relaunched. I deduced this from the following behavior:

 

1.	The value of the global variables was the same as the last known value from the previous invocation.
2.	The following line in WinHost.c was returning the exact same value for the DLL being loaded

Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); (around line 901)

3.	The corresponding code in Nt32’s PeCoffExtractionLib had the following lines in PeCoffLoaderUnloadImageExtraAction

  VOID *ModHandle;

 

  ASSERT (ImageContext != NULL);

  ModHandle = RemoveModeHandle (ImageContext);

  if (ModHandle != NULL) {

    mWinNt->FreeLibrary (ModHandle);

  }

 

However, the same function in EmulatorPkg’s WinHost.c has:

 

ASSERT (ImageContext != NULL);

 

So it appears that the DLL is never being unloaded and the subsequent invocation of the shell app uses the same instance of the DLL, leaving the global variables with the previous values. There are two related functions: AddModHandle and RemoveModHandle.

 

Am I missing something? Or heading in the right direction? 

 

Thanks,

Tim

 

From: devel@edk2.groups.io <devel@edk2.groups.io> 
Sent: Saturday, August 17, 2019 6:30 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder

 

Reminder: TianoCore Design Meeting - APAC/NAMO

When: Thursday, 22 August 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles 

Where:https://zoom.us/j/969264410

View Event <https://edk2.groups.io/g/devel/viewevent?eventid=470780> 

Organizer: Stephano Cetola stephano.cetola@intel.com <mailto:stephano.cetola@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO>

Description: 

Join Zoom Meeting

https://zoom.us/j/969264410

 

One tap mobile

+16465588656,,969264410# US (New York)

+17207072699,,969264410# US

 

Dial by your location

        +1 646 558 8656 US (New York)

        +1 720 707 2699 US

Meeting ID: 969 264 410

Find your local number: https://zoom.us/u/abOtdJckxL




[-- Attachment #2: Type: text/html, Size: 9987 bytes --]

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

[Andrew Fish]

[-- Attachment #1: Type: text/plain, Size: 4322 bytes --]

Tim,

Sounds like you are on to something....

The Unix side [1] does a dlclose() to undo a dlsym(). 

I seem to remember this code flow is very very old, I wonder if it is possible to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and wrote a debugger script to load symbols. So for Xcode all the code is running from the emulator memory, not in an OS context. For lldb I added a breakpoint script on SecGdbScriptBreak() that loads symbols. Since the SecGdbScriptBreak() is part of the App you get symbols for free, and the break point function can access the arguments to SecGdbScriptBreak() to load symbols [3]. Seems like this would easily work for gdb too? I'm not sure how easy this is to do in VC++, but it seems like we can leverage what ever scripts folks use to load symbols on real hardware. 

I'm not 100% sure what is happening on Linux as if you build the code as EFIAPI it seems like the dlopen would fail since it is not x86_64 Sys V ABI, and I guess it could be falling back to the use the gdb script to load symbols. This would Imply for X64 Windows is the odd person out. 

The only downside to "making it real" is you may need to launch pointing at a debugger script to get source level debug. 

I know the lldb symbol loading is working as I help Mike test his recent patches. 

[1] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1263
[2] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1120
[3] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py#L357

Thanks,

Andrew Fish

> On Aug 21, 2019, at 2:13 PM, Tim Lewis <tim.lewis@insyde.com> wrote:
> 
> When running a shell app twice, I ran into an interesting problem: global variables that had initializers were not initialized to the defaults specified in the source. Running the same shell app under the old NT32 seems to work. It turns out that the shell app was not being reloaded, but rather being relaunched. I deduced this from the following behavior:
>
> The value of the global variables was the same as the last known value from the previous invocation.
> The following line in WinHost.c was returning the exact same value for the DLL being loaded
> Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); (around line 901)
> The corresponding code in Nt32’s PeCoffExtractionLib had the following lines in PeCoffLoaderUnloadImageExtraAction
>   VOID *ModHandle;
>
>   ASSERT (ImageContext != NULL);
>   ModHandle = RemoveModeHandle (ImageContext);
>   if (ModHandle != NULL) {
>     mWinNt->FreeLibrary (ModHandle);
>   }
>
> However, the same function in EmulatorPkg’s WinHost.c has:
>
> ASSERT (ImageContext != NULL);
>
> So it appears that the DLL is never being unloaded and the subsequent invocation of the shell app uses the same instance of the DLL, leaving the global variables with the previous values. There are two related functions: AddModHandle and RemoveModHandle.
>
> Am I missing something? Or heading in the right direction? 
>
> Thanks,
> Tim
>
> From: devel@edk2.groups.io <mailto:devel@edk2.groups.io> <devel@edk2.groups.io <mailto:devel@edk2.groups.io>> 
> Sent: Saturday, August 17, 2019 6:30 PM
> To: devel@edk2.groups.io <mailto:devel@edk2.groups.io>
> Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder
>
> Reminder: TianoCore Design Meeting - APAC/NAMO
> 
> When: Thursday, 22 August 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles 
> 
> Where:https://zoom.us/j/969264410 <https://zoom.us/j/969264410>
> View Event <https://edk2.groups.io/g/devel/viewevent?eventid=470780>
> Organizer: Stephano Cetola stephano.cetola@intel.com <mailto:stephano.cetola@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO>
> Description:
> 
> Join Zoom Meeting
> https://zoom.us/j/969264410 <https://zoom.us/j/969264410>
>
> One tap mobile
> +16465588656,,969264410# US (New York)
> +17207072699,,969264410# US
>
> Dial by your location
>         +1 646 558 8656 US (New York)
>         +1 720 707 2699 US
> Meeting ID: 969 264 410
> Find your local number: https://zoom.us/u/abOtdJckxL <https://zoom.us/u/abOtdJckxL>
> 


[-- Attachment #2: Type: text/html, Size: 14152 bytes --]

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

[Michael D Kinney]

[-- Attachment #1: Type: text/plain, Size: 5215 bytes --]

Tim,

Thanks for the analysis.

Looks like we need to fix PeCoffLoaderUnloadImageExtraAction()
for winhost to unload the DLL to keep compatibility with Nt32.  This is important
for both apps and unloadable drivers.

Please enter a BZ.  This looks like a critical enough regression bug that we may want to
consider fixing it before stable tag release.

There are some limitations to the DLL approach.  It is good for source level debug
using VS.  The limitation is when the same driver is loaded more than once.  The
first one is loaded as a DLL and can be debugged.  The 2nd one is loaded into
UEFI memory, but is not registered so all you get is assembly code debug.

The method that Andrew describes supports multiple instances of the same driver.

Thanks,

Mike

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io
Sent: Wednesday, August 21, 2019 2:45 PM
To: devel@edk2.groups.io; tim.lewis@insyde.com
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

Tim,

Sounds like you are on to something....

The Unix side [1] does a dlclose() to undo a dlsym().

I seem to remember this code flow is very very old, I wonder if it is possible to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and wrote a debugger script to load symbols. So for Xcode all the code is running from the emulator memory, not in an OS context. For lldb I added a breakpoint script on SecGdbScriptBreak() that loads symbols. Since the SecGdbScriptBreak() is part of the App you get symbols for free, and the break point function can access the arguments to SecGdbScriptBreak() to load symbols [3]. Seems like this would easily work for gdb too? I'm not sure how easy this is to do in VC++, but it seems like we can leverage what ever scripts folks use to load symbols on real hardware.

I'm not 100% sure what is happening on Linux as if you build the code as EFIAPI it seems like the dlopen would fail since it is not x86_64 Sys V ABI, and I guess it could be falling back to the use the gdb script to load symbols. This would Imply for X64 Windows is the odd person out.

The only downside to "making it real" is you may need to launch pointing at a debugger script to get source level debug.

I know the lldb symbol loading is working as I help Mike test his recent patches.

[1] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1263
[2] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1120
[3] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py#L357

Thanks,

Andrew Fish


On Aug 21, 2019, at 2:13 PM, Tim Lewis <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>> wrote:

When running a shell app twice, I ran into an interesting problem: global variables that had initializers were not initialized to the defaults specified in the source. Running the same shell app under the old NT32 seems to work. It turns out that the shell app was not being reloaded, but rather being relaunched. I deduced this from the following behavior:


  1.  The value of the global variables was the same as the last known value from the previous invocation.
  2.  The following line in WinHost.c was returning the exact same value for the DLL being loaded
Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); (around line 901)

  1.  The corresponding code in Nt32’s PeCoffExtractionLib had the following lines in PeCoffLoaderUnloadImageExtraAction
  VOID *ModHandle;

  ASSERT (ImageContext != NULL);
  ModHandle = RemoveModeHandle (ImageContext);
  if (ModHandle != NULL) {
    mWinNt->FreeLibrary (ModHandle);
  }

However, the same function in EmulatorPkg’s WinHost.c has:

ASSERT (ImageContext != NULL);

So it appears that the DLL is never being unloaded and the subsequent invocation of the shell app uses the same instance of the DLL, leaving the global variables with the previous values. There are two related functions: AddModHandle and RemoveModHandle.

Am I missing something? Or heading in the right direction?

Thanks,
Tim

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>
Sent: Saturday, August 17, 2019 6:30 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder

Reminder: TianoCore Design Meeting - APAC/NAMO
When: Thursday, 22 August 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles
Where:https://zoom.us/j/969264410
View Event<https://edk2.groups.io/g/devel/viewevent?eventid=470780>
Organizer: Stephano Cetola stephano.cetola@intel.com<mailto:stephano.cetola@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO>
Description:
Join Zoom Meeting
https://zoom.us/j/969264410

One tap mobile
+16465588656,,969264410# US (New York)
+17207072699,,969264410# US

Dial by your location
        +1 646 558 8656 US (New York)
        +1 720 707 2699 US
Meeting ID: 969 264 410
Find your local number: https://zoom.us/u/abOtdJckxL



[-- Attachment #2: Type: text/html, Size: 63280 bytes --]

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

[Tim Lewis]

[-- Attachment #1: Type: text/plain, Size: 5984 bytes --]

Mike –

Ok, it is bug 2104.

 

From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Michael D Kinney
Sent: Wednesday, August 21, 2019 3:08 PM
To: devel@edk2.groups.io; afish@apple.com; tim.lewis@insyde.com; Kinney, Michael D <michael.d.kinney@intel.com>
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

 

Tim,

 

Thanks for the analysis.

 

Looks like we need to fix PeCoffLoaderUnloadImageExtraAction()

for winhost to unload the DLL to keep compatibility with Nt32.  This is important

for both apps and unloadable drivers.

 

Please enter a BZ.  This looks like a critical enough regression bug that we may want to 

consider fixing it before stable tag release.

 

There are some limitations to the DLL approach.  It is good for source level debug

using VS.  The limitation is when the same driver is loaded more than once.  The

first one is loaded as a DLL and can be debugged.  The 2nd one is loaded into

UEFI memory, but is not registered so all you get is assembly code debug.

 

The method that Andrew describes supports multiple instances of the same driver.

 

Thanks,

 

Mike

 

From: devel@edk2.groups.io <mailto:devel@edk2.groups.io>  [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io
Sent: Wednesday, August 21, 2019 2:45 PM
To: devel@edk2.groups.io <mailto:devel@edk2.groups.io> ; tim.lewis@insyde.com <mailto:tim.lewis@insyde.com> 
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

 

Tim,

 

Sounds like you are on to something....

 

The Unix side [1] does a dlclose() to undo a dlsym(). 

 

I seem to remember this code flow is very very old, I wonder if it is possible to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and wrote a debugger script to load symbols. So for Xcode all the code is running from the emulator memory, not in an OS context. For lldb I added a breakpoint script on SecGdbScriptBreak() that loads symbols. Since the SecGdbScriptBreak() is part of the App you get symbols for free, and the break point function can access the arguments to SecGdbScriptBreak() to load symbols [3]. Seems like this would easily work for gdb too? I'm not sure how easy this is to do in VC++, but it seems like we can leverage what ever scripts folks use to load symbols on real hardware. 

 

I'm not 100% sure what is happening on Linux as if you build the code as EFIAPI it seems like the dlopen would fail since it is not x86_64 Sys V ABI, and I guess it could be falling back to the use the gdb script to load symbols. This would Imply for X64 Windows is the odd person out. 

 

The only downside to "making it real" is you may need to launch pointing at a debugger script to get source level debug. 

 

I know the lldb symbol loading is working as I help Mike test his recent patches. 

 

[1] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1263

[2] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1120

[3] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py#L357

 

Thanks,

 

Andrew Fish





On Aug 21, 2019, at 2:13 PM, Tim Lewis <tim.lewis@insyde.com <mailto:tim.lewis@insyde.com> > wrote:

 

When running a shell app twice, I ran into an interesting problem: global variables that had initializers were not initialized to the defaults specified in the source. Running the same shell app under the old NT32 seems to work. It turns out that the shell app was not being reloaded, but rather being relaunched. I deduced this from the following behavior:

 

1.	The value of the global variables was the same as the last known value from the previous invocation.
2.	The following line in WinHost.c was returning the exact same value for the DLL being loaded

Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); (around line 901)

3.	The corresponding code in Nt32’s PeCoffExtractionLib had the following lines in PeCoffLoaderUnloadImageExtraAction

  VOID *ModHandle;

 

  ASSERT (ImageContext != NULL);

  ModHandle = RemoveModeHandle (ImageContext);

  if (ModHandle != NULL) {

    mWinNt->FreeLibrary (ModHandle);

  }

 

However, the same function in EmulatorPkg’s WinHost.c has:

 

ASSERT (ImageContext != NULL);

 

So it appears that the DLL is never being unloaded and the subsequent invocation of the shell app uses the same instance of the DLL, leaving the global variables with the previous values. There are two related functions: AddModHandle and RemoveModHandle.

 

Am I missing something? Or heading in the right direction? 

 

Thanks,

Tim

 

From:  <mailto:devel@edk2.groups.io> devel@edk2.groups.io < <mailto:devel@edk2.groups.io> devel@edk2.groups.io> 
Sent: Saturday, August 17, 2019 6:30 PM
To:  <mailto:devel@edk2.groups.io> devel@edk2.groups.io
Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder

 

Reminder: TianoCore Design Meeting - APAC/NAMO

When: Thursday, 22 August 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles 

Where: <https://zoom.us/j/969264410> https://zoom.us/j/969264410

 <https://edk2.groups.io/g/devel/viewevent?eventid=470780> View Event

Organizer: Stephano Cetola  <mailto:stephano.cetola@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO> stephano.cetola@intel.com

Description:

Join Zoom Meeting

 <https://zoom.us/j/969264410> https://zoom.us/j/969264410

 

One tap mobile

+16465588656,,969264410# US (New York)

+17207072699,,969264410# US

 

Dial by your location

        +1 646 558 8656 US (New York)

        +1 720 707 2699 US

Meeting ID: 969 264 410

Find your local number:  <https://zoom.us/u/abOtdJckxL> https://zoom.us/u/abOtdJckxL

 




[-- Attachment #2: Type: text/html, Size: 23893 bytes --]

Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

[Michael D Kinney]

[-- Attachment #1: Type: text/plain, Size: 6279 bytes --]

Tim,

Thanks.  We must have been typing at same time.  J

I will mark my 2105 as a dup of your 2104.

I have a patch I will send in a minute.  I have tested unload and load multiple.

Mike

From: tim.lewis@insyde.com [mailto:tim.lewis@insyde.com]
Sent: Wednesday, August 21, 2019 5:47 PM
To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@intel.com>; afish@apple.com
Subject: RE: [edk2-devel] EmulatorPkg does not unload DLL after exit

Mike –
Ok, it is bug 2104.

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>> On Behalf Of Michael D Kinney
Sent: Wednesday, August 21, 2019 3:08 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; afish@apple.com<mailto:afish@apple.com>; tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

Tim,

Thanks for the analysis.

Looks like we need to fix PeCoffLoaderUnloadImageExtraAction()
for winhost to unload the DLL to keep compatibility with Nt32.  This is important
for both apps and unloadable drivers.

Please enter a BZ.  This looks like a critical enough regression bug that we may want to
consider fixing it before stable tag release.

There are some limitations to the DLL approach.  It is good for source level debug
using VS.  The limitation is when the same driver is loaded more than once.  The
first one is loaded as a DLL and can be debugged.  The 2nd one is loaded into
UEFI memory, but is not registered so all you get is assembly code debug.

The method that Andrew describes supports multiple instances of the same driver.

Thanks,

Mike

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> [mailto:devel@edk2.groups.io] On Behalf Of Andrew Fish via Groups.Io
Sent: Wednesday, August 21, 2019 2:45 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>
Subject: Re: [edk2-devel] EmulatorPkg does not unload DLL after exit

Tim,

Sounds like you are on to something....

The Unix side [1] does a dlclose() to undo a dlsym().

I seem to remember this code flow is very very old, I wonder if it is possible to do better? For lldb (Xcode) I skipped the LoadLibraryEx()/dlsym() action and wrote a debugger script to load symbols. So for Xcode all the code is running from the emulator memory, not in an OS context. For lldb I added a breakpoint script on SecGdbScriptBreak() that loads symbols. Since the SecGdbScriptBreak() is part of the App you get symbols for free, and the break point function can access the arguments to SecGdbScriptBreak() to load symbols [3]. Seems like this would easily work for gdb too? I'm not sure how easy this is to do in VC++, but it seems like we can leverage what ever scripts folks use to load symbols on real hardware.

I'm not 100% sure what is happening on Linux as if you build the code as EFIAPI it seems like the dlopen would fail since it is not x86_64 Sys V ABI, and I guess it could be falling back to the use the gdb script to load symbols. This would Imply for X64 Windows is the odd person out.

The only downside to "making it real" is you may need to launch pointing at a debugger script to get source level debug.

I know the lldb symbol loading is working as I help Mike test his recent patches.

[1] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1263
[2] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/Host/Host.c#L1120
[3] https://github.com/tianocore/edk2/blob/master/EmulatorPkg/Unix/lldbefi.py#L357

Thanks,

Andrew Fish

On Aug 21, 2019, at 2:13 PM, Tim Lewis <tim.lewis@insyde.com<mailto:tim.lewis@insyde.com>> wrote:

When running a shell app twice, I ran into an interesting problem: global variables that had initializers were not initialized to the defaults specified in the source. Running the same shell app under the old NT32 seems to work. It turns out that the shell app was not being reloaded, but rather being relaunched. I deduced this from the following behavior:


  1.  The value of the global variables was the same as the last known value from the previous invocation.
  2.  The following line in WinHost.c was returning the exact same value for the DLL being loaded
Library = LoadLibraryEx (DllFileName, NULL, DONT_RESOLVE_DLL_REFERENCES); (around line 901)

  1.  The corresponding code in Nt32’s PeCoffExtractionLib had the following lines in PeCoffLoaderUnloadImageExtraAction
  VOID *ModHandle;

  ASSERT (ImageContext != NULL);
  ModHandle = RemoveModeHandle (ImageContext);
  if (ModHandle != NULL) {
    mWinNt->FreeLibrary (ModHandle);
  }

However, the same function in EmulatorPkg’s WinHost.c has:

ASSERT (ImageContext != NULL);

So it appears that the DLL is never being unloaded and the subsequent invocation of the shell app uses the same instance of the DLL, leaving the global variables with the previous values. There are two related functions: AddModHandle and RemoveModHandle.

Am I missing something? Or heading in the right direction?

Thanks,
Tim

From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>
Sent: Saturday, August 17, 2019 6:30 PM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Subject: [edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - Thu, 08/22/2019 6:30pm-7:30pm #cal-reminder

Reminder: TianoCore Design Meeting - APAC/NAMO
When: Thursday, 22 August 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los Angeles
Where:https://zoom.us/j/969264410
View Event<https://edk2.groups.io/g/devel/viewevent?eventid=470780>
Organizer: Stephano Cetola stephano.cetola@intel.com<mailto:stephano.cetola@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO>
Description:
Join Zoom Meeting
https://zoom.us/j/969264410

One tap mobile
+16465588656,,969264410# US (New York)
+17207072699,,969264410# US

Dial by your location
        +1 646 558 8656 US (New York)
        +1 720 707 2699 US
Meeting ID: 969 264 410
Find your local number: https://zoom.us/u/abOtdJckxL



[-- Attachment #2: Type: text/html, Size: 65843 bytes --]