<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://bugs.webkit.org/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4.1"
          urlbase="https://bugs.webkit.org/"
          
          maintainer="admin@webkit.org"
>

    <bug>
          <bug_id>83105</bug_id>
          
          <creation_ts>2012-04-03 18:58:22 -0700</creation_ts>
          <short_desc>figure out how to export webcore symbols from webkit.dll properly</short_desc>
          <delta_ts>2012-04-04 12:22:12 -0700</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>WebKit</product>
          <component>Platform</component>
          <version>528+ (Nightly build)</version>
          <rep_platform>Unspecified</rep_platform>
          <op_sys>Unspecified</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords></keywords>
          <priority>P2</priority>
          <bug_severity>Normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="Dirk Pranke">dpranke</reporter>
          <assigned_to name="Adam Barth">abarth</assigned_to>
          <cc>abarth</cc>
    
    <cc>dglazkov</cc>
    
    <cc>fischman</cc>
    
    <cc>fishd</cc>
    
    <cc>jamesr</cc>
    
    <cc>maruel</cc>
    
    <cc>rvargas</cc>
    
    <cc>scottmg</cc>
    
    <cc>tkent</cc>
    
    <cc>tony</cc>
    
    <cc>webkit.review.bot</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>595129</commentid>
    <comment_count>0</comment_count>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2012-04-03 18:58:22 -0700</bug_when>
    <thetext>We&apos;ve stumbled onto an issue in attempting to export a symbol out of chromium/public/WebMediaStreamSourcesRequest.h, which is part of webcore_platform now.

Since WebMediaStreamSourcesRequest.cpp is not referenced by anything in WebKit directly (apparently), it looks like we run into an issue on windows where, when building webkit.dll, we think the file is dead/unused code, and it isn&apos;t linked into the DLL.

We attempted to work around this by enabling ULDI for webkit.dll in bug 83068, but that appears to have caused other weird issues downstream in chromium, so we reverted that.

For now we&apos;ve hacked around it in http://trac.webkit.org/changeset/113105 by forcing a reference from WebKit.cpp to the file, but this is not a good nor scalable solution.

It seems like the &quot;correct&quot; solution is to not build webcore_platform as a .lib at all, but to include the objects directly into the link of webkit.lib/webkit.dll (this is basically what I did for content.dll). However, we suspect that we&apos;ll hit the 128KB command line limit for the linker, like we did when we tried this w/ chrome.dll, and what caused Scott to write &apos;supalink&apos; to break up the command line.

So, it&apos;s not clear what the best way forward is ... thoughts?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595193</commentid>
    <comment_count>1</comment_count>
    <who name="James Robinson">jamesr</who>
    <bug_when>2012-04-03 20:24:11 -0700</bug_when>
    <thetext>Could we make a dedicated section of the .gypis for implementations of WebKit API that aren&apos;t in webkit.lib (this would be Source/WebCore/platform/chromium/support and Source/Platform/chromium/src, I believe) and have those objects be stuck in webkit.dll?  We need to be pretty careful about where we put implementations of exported symbols anyway to make sure we don&apos;t break APIs so that won&apos;t be an unbounded set.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595264</commentid>
    <comment_count>2</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-04-03 22:55:51 -0700</bug_when>
    <thetext>Yeah, Comment #1 is what I was thinking about on the drive home tonight too.  We should just compile Source/WebCore/platform/chromium/support/* as part of webkit.lib to make sure the obj files are in the DLL, causing the linker to export the symbols.  Apparently we do similar things in other parts of Chrome.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595270</commentid>
    <comment_count>3</comment_count>
      <attachid>135520</attachid>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-04-03 23:18:46 -0700</bug_when>
    <thetext>Created attachment 135520
Patch</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595271</commentid>
    <comment_count>4</comment_count>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-04-03 23:22:32 -0700</bug_when>
    <thetext>Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595274</commentid>
    <comment_count>5</comment_count>
    <who name="Ami Fischman">fischman</who>
    <bug_when>2012-04-03 23:43:28 -0700</bug_when>
    <thetext>(In reply to comment #2)
&gt; Yeah, Comment #1 is what I was thinking about on the drive home tonight too.  We should just compile Source/WebCore/platform/chromium/support/* as part of webkit.lib to make sure the obj files are in the DLL, causing the linker to export the symbols.  Apparently we do similar things in other parts of Chrome.

Doesn&apos;t this fly in the face of bug 82948?  (and lose the benefit of the compiler/linker verifying that code in webcore_platform not depend on code above webcore (specifically, in webkit))

I expected the right fix to mark WebMediaStreamSourcesRequest (and any other public-API classes in Platform) as exported, via something like WEBKIT_EXPORT (although presumably using a (new) PLATFORM_EXPORT macro, instead).  

Maybe I&apos;m just confused.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595277</commentid>
    <comment_count>6</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-04-03 23:57:10 -0700</bug_when>
    <thetext>&gt; Doesn&apos;t this fly in the face of bug 82948?  (and lose the benefit of the compiler/linker verifying that code in webcore_platform not depend on code above webcore (specifically, in webkit))

We do lose some benefits in the sense that the include rules are more relaxed on these compilation units than we would like.  My understanding is that there&apos;s a limitation of GYP that you cannot use different include paths within a given lib.  If we need to link these obj files as part of webkit.lib, that implies that we need to use the looser include paths.

Note, however, that we will be able to achieve the goal of Bug 82948, which is to remove PlatformSupport.  Logically, these files are part of WebCore/platform.  We just happen to compile and link them as part of webkit.lib rather than as part of webcore_platform.lib.

&gt; I expected the right fix to mark WebMediaStreamSourcesRequest (and any other public-API classes in Platform) as exported, via something like WEBKIT_EXPORT (although presumably using a (new) PLATFORM_EXPORT macro, instead).  

If you know of a way to do that and make the Windows component build work, I&apos;m all ears!  That would be much better than the approach in this patch.

My understanding of the issue is as follows:

When constructing webkit.dll, the linker starts with all the obj files in webkit.lib and constructs the list of unmet dependencies.  While there are still at least one unmet dependency, the linker searches the libs on the link line for obj files that contain that dependency.  Upon finding such an obj file, the obj file is added to webkit.dll and any new unmet dependencies are added to the list of unmet dependencies.  This process terminates either when the list of unmet dependencies is empty or when the linker fails to find an obj file to satisfy an unmet dependency.

Finally, the linker exports all the symbols in webkit.dll that are marked for export, and creates a stub lib containing those symbols, etc.

Now, the problem in this case is that none of the symbols in WebMediaStreamSourcesRequest.obj are unmet dependencies of webkit.lib and hence WebMediaStreamSourcesRequest.obj never gets pulled into webkit.dll.  Because WebMediaStreamSourcesRequest.obj never gets pulled into webkit.lib, the linker never sees that some of the symbols in WebMediaStreamSourcesRequest.obj are marked for export and hence those symbols are not exported by webkit.dll.

We tried a fix earlier today that forced the link to slam all the obj files into webkit.dll.  At that point, the linker sees the exported symbols in WebMediaStreamSourcesRequest.obj and exports them in webkit.dll.  However, that change caused a compile error for Aura (for reason I don&apos;t fully understand).  It&apos;s also frowned upon by folks who know infinitely more about our build system than I do.

This change similarly forces the linker to include WebMediaStreamSourcesRequest.obj in webkit.lib by moving the obj file from webcore_platform.lib to webkit.lib.  It&apos;s certainly not ideal, but I think it should work.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595284</commentid>
    <comment_count>7</comment_count>
    <who name="Ami Fischman">fischman</who>
    <bug_when>2012-04-04 00:23:21 -0700</bug_when>
    <thetext>Is the problem that MSVC&apos;s linker doesn&apos;t have an equivalent to ld&apos;s --whole-archive (which would allow webkit.dll to include wholesale webcore_platform.lib)?
(I know nothing about MSVC but google points me at http://msdn.microsoft.com/en-US/library/bxwfs976%28v=VS.80%29.aspx)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595285</commentid>
    <comment_count>8</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-04-04 00:26:05 -0700</bug_when>
    <thetext>We did try one, which is what I was referring to with &quot;We tried a fix earlier today that forced the link to slam all the obj files into webkit.dll.&quot;  Maybe there are other ways to do that better?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595624</commentid>
    <comment_count>9</comment_count>
      <attachid>135520</attachid>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2012-04-04 09:44:52 -0700</bug_when>
    <thetext>Comment on attachment 135520
Patch

Makes sense.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595625</commentid>
    <comment_count>10</comment_count>
    <who name="Dimitri Glazkov (Google)">dglazkov</who>
    <bug_when>2012-04-04 09:46:19 -0700</bug_when>
    <thetext>We could also add an explicit exclusion of chromium/support files in WebKit.gyp, so that they never get accidentally added to the build files.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595661</commentid>
    <comment_count>11</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-04-04 10:26:31 -0700</bug_when>
    <thetext>&gt; We could also add an explicit exclusion of chromium/support files in WebKit.gyp, so that they never get accidentally added to the build files.

Thats and interesting idea.  I&apos;d be inclined to do that after the first time we mess up.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595668</commentid>
    <comment_count>12</comment_count>
    <who name="Marc-Antoine Ruel">maruel</who>
    <bug_when>2012-04-04 10:31:53 -0700</bug_when>
    <thetext>General note:

To force MSVC to include a symbol in the final PE (dll or exe) that is located in a static library (lib), you can use :

#pragma comment(linker, &apos;/include:&lt;symbol&gt;&apos;)

where the symbol is preferably an extern &quot;C&quot; to not have to manage the C++ mangling.

General doc: http://msdn.microsoft.com/en-us/library/7f0aews7.aspx</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595695</commentid>
    <comment_count>13</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-04-04 10:45:02 -0700</bug_when>
    <thetext>Where would we place that pragma?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595699</commentid>
    <comment_count>14</comment_count>
    <who name="Marc-Antoine Ruel">maruel</who>
    <bug_when>2012-04-04 10:50:46 -0700</bug_when>
    <thetext>IIRC, any object that is ultimately included for consideration in the final link step is fine. This means any .obj inside any .lib is fine.

FTR, this is what ATL does to inject globals in the final executable.

But my memory is failing. So if this fails, at worst put it an header file which will be included in one .obj that will be linked directly in the final link step.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595704</commentid>
    <comment_count>15</comment_count>
    <who name="Adam Barth">abarth</who>
    <bug_when>2012-04-04 10:53:48 -0700</bug_when>
    <thetext>Thanks for the pointer.  I don&apos;t think that&apos;s a great option for us here because this is a C++ API, which means we&apos;d need to use the mangled symbol.  However, it&apos;s a good trick to add to the basket.  :)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595708</commentid>
    <comment_count>16</comment_count>
    <who name="Marc-Antoine Ruel">maruel</who>
    <bug_when>2012-04-04 10:58:04 -0700</bug_when>
    <thetext>Assign the address of a C++ symbol to a C symbol.

#ifdef _MSC_VER

// Make sure the symbol is included.
// Note the lack of function call. It&apos;s taking the function&apos;s address.
extern &quot;C&quot; const void * const force_include_platform_support = static_cast&lt;const void*&gt;(&amp;webKitPlatformSupport);

#pragma comment(linker, &apos;/include:__force_include_platform_support&apos;)

#endif // _MSC_VER


or something roughly like that, I haven&apos;t tested.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595728</commentid>
    <comment_count>17</comment_count>
      <attachid>135520</attachid>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-04-04 11:14:33 -0700</bug_when>
    <thetext>Comment on attachment 135520
Patch

Clearing flags on attachment: 135520

Committed r113218: &lt;http://trac.webkit.org/changeset/113218&gt;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595729</commentid>
    <comment_count>18</comment_count>
    <who name="WebKit Review Bot">webkit.review.bot</who>
    <bug_when>2012-04-04 11:14:39 -0700</bug_when>
    <thetext>All reviewed patches have been landed.  Closing bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>595797</commentid>
    <comment_count>19</comment_count>
    <who name="Dirk Pranke">dpranke</who>
    <bug_when>2012-04-04 12:22:12 -0700</bug_when>
    <thetext>(In reply to comment #7)
&gt; Is the problem that MSVC&apos;s linker doesn&apos;t have an equivalent to ld&apos;s --whole-archive (which would allow webkit.dll to include wholesale webcore_platform.lib)?
&gt; (I know nothing about MSVC but google points me at http://msdn.microsoft.com/en-US/library/bxwfs976%28v=VS.80%29.aspx)

The option we tried (for reference) was &quot;Use Library Dependency Inputs&quot; (which is a VS option, not a linker option, but I think is a closer analog to --whole-archive); I&apos;m not familiar with /opt:noref but it sounds like it does dead code stripping *after* it&apos;s figured out which objects it&apos;s supposed to link, so I would hazard a guess that it wouldn&apos;t cause the archive member to be pulled in.

IIRC, the downstream failure was on the Chromium &quot;Win Aura&quot;; I hadn&apos;t looked at the error until now, but I think it was probably from this build: http://build.chromium.org/p/chromium/builders/Win%20Aura/builds/9390 , and it looks like we just blew out the 128KB command line length to the linker, which doesn&apos;t surprise me (as mentioned in comment #1).

Note that you can run into other weirdness when you do something like --whole-archive, which is that you can multiply defined symbols and, sometimes worse, multiple copies of singletons. Much of the work of making things work in component builds is restructuring the libraries so that we don&apos;t have these issues.</thetext>
  </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>135520</attachid>
            <date>2012-04-03 23:18:46 -0700</date>
            <delta_ts>2012-04-04 11:14:33 -0700</delta_ts>
            <desc>Patch</desc>
            <filename>bug-83105-20120403231845.patch</filename>
            <type>text/plain</type>
            <size>9629</size>
            <attacher name="Adam Barth">abarth</attacher>
            
              <data encoding="base64">SW5kZXg6IFNvdXJjZS9QbGF0Zm9ybS9DaGFuZ2VMb2cKPT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1Bs
YXRmb3JtL0NoYW5nZUxvZwkocmV2aXNpb24gMTEzMTQzKQorKysgU291cmNlL1BsYXRmb3JtL0No
YW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE1IEBACisyMDEyLTA0LTAzICBBZGFt
IEJhcnRoICA8YWJhcnRoQHdlYmtpdC5vcmc+CisKKyAgICAgICAgZmlndXJlIG91dCBob3cgdG8g
ZXhwb3J0IHdlYmNvcmUgc3ltYm9scyBmcm9tIHdlYmtpdC5kbGwgcHJvcGVybHkKKyAgICAgICAg
aHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTgzMTA1CisKKyAgICAgICAg
UmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgVW53aW5kIG91ciB1Z2x5LCB1
Z2x5IGhhY2sgdG8gbWFrZSB0aGUgV2luZG93cyBjb21wb25lbnQgYnVpbGQgd29yay4KKworICAg
ICAgICAqIGNocm9taXVtL3B1YmxpYy9XZWJNZWRpYVN0cmVhbVNvdXJjZXNSZXF1ZXN0Lmg6Cisg
ICAgICAgIChXZWJNZWRpYVN0cmVhbVNvdXJjZXNSZXF1ZXN0KToKKwogMjAxMi0wNC0wMyAgQWRh
bSBCYXJ0aCAgPGFiYXJ0aEB3ZWJraXQub3JnPgogCiAgICAgICAgIFVucmV2aWV3ZWQuIFRoaXMg
cGF0Y2ggYWRkcyBhbiB1Z2x5LCB1Z2x5IGhhY2sgdG8gYmFuZGFpZCBvdmVyIHRoZQpJbmRleDog
U291cmNlL1BsYXRmb3JtL2Nocm9taXVtL3B1YmxpYy9XZWJNZWRpYVN0cmVhbVNvdXJjZXNSZXF1
ZXN0LmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1BsYXRmb3JtL2Nocm9taXVtL3B1YmxpYy9XZWJN
ZWRpYVN0cmVhbVNvdXJjZXNSZXF1ZXN0LmgJKHJldmlzaW9uIDExMzEzNikKKysrIFNvdXJjZS9Q
bGF0Zm9ybS9jaHJvbWl1bS9wdWJsaWMvV2ViTWVkaWFTdHJlYW1Tb3VyY2VzUmVxdWVzdC5oCSh3
b3JraW5nIGNvcHkpCkBAIC01NSwxMyArNTUsNiBAQCBwdWJsaWM6CiAKICAgICBXRUJLSVRfRVhQ
T1JUIHZvaWQgZGlkQ29tcGxldGVRdWVyeShjb25zdCBXZWJWZWN0b3I8V2ViTWVkaWFTdHJlYW1T
b3VyY2U+JiBhdWRpb1NvdXJjZXMsIGNvbnN0IFdlYlZlY3RvcjxXZWJNZWRpYVN0cmVhbVNvdXJj
ZT4mIHZpZGVvU291cmNlcykgY29uc3Q7CiAKLSAgICAvLyBUaGlzIGZ1bmN0aW9uIGlzIGEgdGVt
cG9yYXJ5IGhhY2sgdG8gbWFrZSB0aGUgV2luZG93cyBjb21wb25lbnQgYnVpbGQKLSAgICAvLyBj
b21waWxlLiBXaXRob3V0IHRoaXMgZnVuY3Rpb24sIFdlYk1lZGlhU3RyZWFtU291cmNlc1JlcXVl
c3Qub2JqIHdvbid0Ci0gICAgLy8gYmUgcHVsbGVkIGludG8gd2Via2l0LmRsbCBhbmQgY29udGVu
dC5kbGwgd2lsbCBmYWlsIHRvIGxpbmsuIFRoaXMKLSAgICAvLyBmdW5jdGlvbiBpcyBub3QgdGhl
IGNvcnJlY3Qgc29sdXRpb24gdG8gdGhpcyBwcm9ibGVtIGJ1dCB3aWxsIGxldCB1cwotICAgIC8v
IGZpeCB0aGUgYnVpbGQgd2hpbGUgd2Ugd29yayBvbiBhIGNvcnJlY3Qgc29sdXRpb24uCi0gICAg
V0VCS0lUX0VYUE9SVCBzdGF0aWMgdm9pZCBkdW1teSgpOwotCiAjaWYgV0VCS0lUX0lNUExFTUVO
VEFUSU9OCiAgICAgV2ViTWVkaWFTdHJlYW1Tb3VyY2VzUmVxdWVzdChjb25zdCBXVEY6OlBhc3NS
ZWZQdHI8V2ViQ29yZTo6TWVkaWFTdHJlYW1Tb3VyY2VzUXVlcnlDbGllbnQ+Jik7CiAjZW5kaWYK
SW5kZXg6IFNvdXJjZS9XZWJDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvV2Vi
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDExMzE0MykKKysrIFNvdXJjZS9XZWJDb3JlL0NoYW5n
ZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDIxIEBACisyMDEyLTA0LTAzICBBZGFtIEJh
cnRoICA8YWJhcnRoQHdlYmtpdC5vcmc+CisKKyAgICAgICAgZmlndXJlIG91dCBob3cgdG8gZXhw
b3J0IHdlYmNvcmUgc3ltYm9scyBmcm9tIHdlYmtpdC5kbGwgcHJvcGVybHkKKyAgICAgICAgaHR0
cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTgzMTA1CisKKyAgICAgICAgUmV2
aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgKiBXZWJDb3JlLmd5cGk6CisgICAg
ICAgICAgICAtIFNlcGFyYXRlIHRoZSBwbGF0Zm9ybSBzdXBwb3J0IGZpbGVzIGludG8gYSBuZXcg
R1lQIHZhcmlhYmxlIHNvCisgICAgICAgICAgICAgIHRoYXQgdGhleSBjYW4gYmUgYnVpbGQgYXMg
cGFydCBvZiB3ZWJraXQuZGxsIHJhdGhlciB0aGFuIGluCisgICAgICAgICAgICAgIHdlYmNvcmVf
cGxhdGZvcm0ubGliLiBCdWlsZGluZyB0aGVtIGFzIHBhcnQgb2Ygd2Via2l0LmRsbCBlbnN1cmUK
KyAgICAgICAgICAgICAgdGhhdCB0aGUgc3ltYm9scyBtYXJrZWQgZm9yIGV4cG9ydCB3aWxsIGFj
dHVhbGx5IGJlIGluIHdlYmtpdC5kbGwKKyAgICAgICAgICAgICAgKGFuZCBoZW5jZSBleHBvcnRl
ZCksIGV2ZW4gaWYgbm90aGluZyBlbHNlIGluIHdlYmtpdC5kbGwKKyAgICAgICAgICAgICAgcmVm
ZXJlbmNlcyB0aGUgb2JqIGZpbGUgdGhhdCBjb250YWlucyB0aGUgc3ltYm9sLgorICAgICAgICAq
IHBsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViTWVkaWFTdHJlYW1Tb3VyY2VzUmVxdWVzdC5j
cHA6CisgICAgICAgICAgICAtIFVud2luZCBvdXIgdWdseSwgdWdseSBoYWNrIHRvIG1ha2UgdGhl
IFdpbmRvd3MgY29tcG9uZW50IGJ1aWxkCisgICAgICAgICAgICAgIHdvcmsuCisKIDIwMTItMDQt
MDMgIEFkYW0gQmFydGggIDxhYmFydGhAd2Via2l0Lm9yZz4KIAogICAgICAgICBJbXBsZW1lbnQg
PGlmcmFtZSBzcmNkb2M+CkluZGV4OiBTb3VyY2UvV2ViQ29yZS9XZWJDb3JlLmd5cGkKPT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PQotLS0gU291cmNlL1dlYkNvcmUvV2ViQ29yZS5neXBpCShyZXZpc2lvbiAxMTMxMzYpCisr
KyBTb3VyY2UvV2ViQ29yZS9XZWJDb3JlLmd5cGkJKHdvcmtpbmcgY29weSkKQEAgLTMyOTAsMjcg
KzMyOTAsNiBAQAogICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL1RoZW1lQ2hyb21pdW1N
YWMubW0nLAogICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL1RyYWNlRXZlbnQuaCcsCiAg
ICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vV2lkZ2V0Q2hyb21pdW0uY3BwJywKLSAgICAg
ICAgICAgICdwbGF0Zm9ybS9jaHJvbWl1bS9zdXBwb3J0L1dlYkF1ZGlvQnVzLmNwcCcsCi0gICAg
ICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XZWJEYXRhLmNwcCcsCi0gICAgICAg
ICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XZWJIVFRQQm9keS5jcHAnLAotICAgICAg
ICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViSFRUUExvYWRJbmZvLmNwcCcsCi0g
ICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XZWJJQ0VDYW5kaWRhdGVEZXNj
cmlwdG9yLmNwcCcsCi0gICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XZWJJ
Q0VPcHRpb25zLmNwcCcsCi0gICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9X
ZWJNZWRpYUhpbnRzLmNwcCcsCi0gICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9y
dC9XZWJNZWRpYUhpbnRzLmNwcCcsCi0gICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3Vw
cG9ydC9XZWJNZWRpYVN0cmVhbUNvbXBvbmVudC5jcHAnLAotICAgICAgICAgICAgJ3BsYXRmb3Jt
L2Nocm9taXVtL3N1cHBvcnQvV2ViTWVkaWFTdHJlYW1EZXNjcmlwdG9yLmNwcCcsCi0gICAgICAg
ICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XZWJNZWRpYVN0cmVhbVNvdXJjZS5jcHAn
LAotICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViTWVkaWFTdHJlYW1T
b3VyY2VzUmVxdWVzdC5jcHAnLAotICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL3N1cHBv
cnQvV2ViVGhyZWFkU2FmZURhdGEuY3BwJywKLSAgICAgICAgICAgICdwbGF0Zm9ybS9jaHJvbWl1
bS9zdXBwb3J0L1dlYlVSTC5jcHAnLAotICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL3N1
cHBvcnQvV2ViVVJMRXJyb3IuY3BwJywKLSAgICAgICAgICAgICdwbGF0Zm9ybS9jaHJvbWl1bS9z
dXBwb3J0L1dlYlVSTFJlcXVlc3QuY3BwJywKLSAgICAgICAgICAgICdwbGF0Zm9ybS9jaHJvbWl1
bS9zdXBwb3J0L1dlYlVSTFJlcXVlc3RQcml2YXRlLmgnLAotICAgICAgICAgICAgJ3BsYXRmb3Jt
L2Nocm9taXVtL3N1cHBvcnQvV2ViVVJMUmVzcG9uc2UuY3BwJywKLSAgICAgICAgICAgICdwbGF0
Zm9ybS9jaHJvbWl1bS9zdXBwb3J0L1dlYlVSTFJlc3BvbnNlUHJpdmF0ZS5oJywKLSAgICAgICAg
ICAgICdwbGF0Zm9ybS9jaHJvbWl1bS9zdXBwb3J0L1dyYXBwZWRSZXNvdXJjZVJlcXVlc3QuaCcs
Ci0gICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XcmFwcGVkUmVzb3VyY2VS
ZXNwb25zZS5oJywKICAgICAgICAgICAgICdwbGF0Zm9ybS9jb2NvYS9LZXlFdmVudENvY29hLmgn
LAogICAgICAgICAgICAgJ3BsYXRmb3JtL2NvY29hL0tleUV2ZW50Q29jb2EubW0nLAogICAgICAg
ICAgICAgJ3BsYXRmb3JtL2VmbC9DbGlwYm9hcmRFZmwuY3BwJywKQEAgLTgxNzUsNiArODE1NCwy
OSBAQAogICAgICAgICAgICAgJzwoUFJPRFVDVF9ESVIpL0Rlcml2ZWRTb3VyY2VzL1dlYkNvcmUv
WFBhdGhHcmFtbWFyLmNwcCcsCiAgICAgICAgICAgICAnPChQUk9EVUNUX0RJUikvRGVyaXZlZFNv
dXJjZXMvV2ViQ29yZS9YUGF0aEdyYW1tYXIuaCcsCiAgICAgICAgIF0sCisgICAgICAgICd3ZWJj
b3JlX3BsYXRmb3JtX3N1cHBvcnRfZmlsZXMnOiBbCisgICAgICAgICAgICAncGxhdGZvcm0vY2hy
b21pdW0vc3VwcG9ydC9XZWJBdWRpb0J1cy5jcHAnLAorICAgICAgICAgICAgJ3BsYXRmb3JtL2No
cm9taXVtL3N1cHBvcnQvV2ViRGF0YS5jcHAnLAorICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9t
aXVtL3N1cHBvcnQvV2ViSFRUUEJvZHkuY3BwJywKKyAgICAgICAgICAgICdwbGF0Zm9ybS9jaHJv
bWl1bS9zdXBwb3J0L1dlYkhUVFBMb2FkSW5mby5jcHAnLAorICAgICAgICAgICAgJ3BsYXRmb3Jt
L2Nocm9taXVtL3N1cHBvcnQvV2ViSUNFQ2FuZGlkYXRlRGVzY3JpcHRvci5jcHAnLAorICAgICAg
ICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViSUNFT3B0aW9ucy5jcHAnLAorICAg
ICAgICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViTWVkaWFIaW50cy5jcHAnLAor
ICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViTWVkaWFIaW50cy5jcHAn
LAorICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViTWVkaWFTdHJlYW1D
b21wb25lbnQuY3BwJywKKyAgICAgICAgICAgICdwbGF0Zm9ybS9jaHJvbWl1bS9zdXBwb3J0L1dl
Yk1lZGlhU3RyZWFtRGVzY3JpcHRvci5jcHAnLAorICAgICAgICAgICAgJ3BsYXRmb3JtL2Nocm9t
aXVtL3N1cHBvcnQvV2ViTWVkaWFTdHJlYW1Tb3VyY2UuY3BwJywKKyAgICAgICAgICAgICdwbGF0
Zm9ybS9jaHJvbWl1bS9zdXBwb3J0L1dlYk1lZGlhU3RyZWFtU291cmNlc1JlcXVlc3QuY3BwJywK
KyAgICAgICAgICAgICdwbGF0Zm9ybS9jaHJvbWl1bS9zdXBwb3J0L1dlYlRocmVhZFNhZmVEYXRh
LmNwcCcsCisgICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XZWJVUkwuY3Bw
JywKKyAgICAgICAgICAgICdwbGF0Zm9ybS9jaHJvbWl1bS9zdXBwb3J0L1dlYlVSTEVycm9yLmNw
cCcsCisgICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XZWJVUkxSZXF1ZXN0
LmNwcCcsCisgICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9ydC9XZWJVUkxSZXF1
ZXN0UHJpdmF0ZS5oJywKKyAgICAgICAgICAgICdwbGF0Zm9ybS9jaHJvbWl1bS9zdXBwb3J0L1dl
YlVSTFJlc3BvbnNlLmNwcCcsCisgICAgICAgICAgICAncGxhdGZvcm0vY2hyb21pdW0vc3VwcG9y
dC9XZWJVUkxSZXNwb25zZVByaXZhdGUuaCcsCisgICAgICAgICAgICAncGxhdGZvcm0vY2hyb21p
dW0vc3VwcG9ydC9XcmFwcGVkUmVzb3VyY2VSZXF1ZXN0LmgnLAorICAgICAgICAgICAgJ3BsYXRm
b3JtL2Nocm9taXVtL3N1cHBvcnQvV3JhcHBlZFJlc291cmNlUmVzcG9uc2UuaCcsCisgICAgICAg
IF0sCiAgICAgICAgICdleHBvcnRfZmlsZV9nZW5lcmF0b3JfZmlsZXMnOiBbCiAgICAgICAgICAg
ICAnPChQUk9EVUNUX0RJUikvRGVyaXZlZFNvdXJjZXMvV2ViQ29yZS9FeHBvcnRGaWxlR2VuZXJh
dG9yLmNwcCcsCiAgICAgICAgIF0sCkluZGV4OiBTb3VyY2UvV2ViQ29yZS9wbGF0Zm9ybS9jaHJv
bWl1bS9zdXBwb3J0L1dlYk1lZGlhU3RyZWFtU291cmNlc1JlcXVlc3QuY3BwCj09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K
LS0tIFNvdXJjZS9XZWJDb3JlL3BsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViTWVkaWFTdHJl
YW1Tb3VyY2VzUmVxdWVzdC5jcHAJKHJldmlzaW9uIDExMzEzNikKKysrIFNvdXJjZS9XZWJDb3Jl
L3BsYXRmb3JtL2Nocm9taXVtL3N1cHBvcnQvV2ViTWVkaWFTdHJlYW1Tb3VyY2VzUmVxdWVzdC5j
cHAJKHdvcmtpbmcgY29weSkKQEAgLTgyLDEwICs4Miw2IEBAIHZvaWQgV2ViTWVkaWFTdHJlYW1T
b3VyY2VzUmVxdWVzdDo6ZGlkQ28KICAgICBtX3ByaXZhdGUtPmRpZENvbXBsZXRlUXVlcnkoYXVk
aW8sIHZpZGVvKTsKIH0KIAotdm9pZCBXZWJNZWRpYVN0cmVhbVNvdXJjZXNSZXF1ZXN0OjpkdW1t
eSgpCi17Ci19Ci0KIH0gLy8gbmFtZXNwYWNlIFdlYktpdAogCiAjZW5kaWYgLy8gRU5BQkxFKE1F
RElBX1NUUkVBTSkKSW5kZXg6IFNvdXJjZS9XZWJLaXQvY2hyb21pdW0vQ2hhbmdlTG9nCj09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT0KLS0tIFNvdXJjZS9XZWJLaXQvY2hyb21pdW0vQ2hhbmdlTG9nCShyZXZpc2lvbiAxMTMx
NDMpCisrKyBTb3VyY2UvV2ViS2l0L2Nocm9taXVtL0NoYW5nZUxvZwkod29ya2luZyBjb3B5KQpA
QCAtMSwzICsxLDIwIEBACisyMDEyLTA0LTAzICBBZGFtIEJhcnRoICA8YWJhcnRoQHdlYmtpdC5v
cmc+CisKKyAgICAgICAgZmlndXJlIG91dCBob3cgdG8gZXhwb3J0IHdlYmNvcmUgc3ltYm9scyBm
cm9tIHdlYmtpdC5kbGwgcHJvcGVybHkKKyAgICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcv
c2hvd19idWcuY2dpP2lkPTgzMTA1CisKKyAgICAgICAgUmV2aWV3ZWQgYnkgTk9CT0RZIChPT1BT
ISkuCisKKyAgICAgICAgKiBXZWJLaXQuZ3lwOgorICAgICAgICAgICAgLSBXZSBub3cgY29tcGls
ZSB0aGUgcGxhdGZvcm0gc3VwcG9ydCBmaWxlcyBhcyBwYXJ0IG9mIHdlYmtpdC5kbGwKKyAgICAg
ICAgICAgICAgdG8gbWFrZSBzdXJlIHRoZSBsaWIgY29udGFpbnMgdGhlIG9iaiBmaWxlcyBhbmQg
dGhlcmVmb3JlIGV4cG9ydHMKKyAgICAgICAgICAgICAgdGhlIG5lY2Vzc2FyeSBzeW1ib2xzLiBJ
biBwcmluY2lwbGUsIHdlIGNvdWxkIHVzZSBhIGRlZnMgZmlsZSB0bworICAgICAgICAgICAgICBh
Y2hpZXZlIHRoZSBzYW1lIHRoaW5nLCBidXQgdGhvc2UgZmlsZXMgYXJlIGEgcGFpbiB0byBtYWlu
dGFpbi4KKyAgICAgICAgKiBzcmMvV2ViS2l0LmNwcDoKKyAgICAgICAgKFdlYktpdDo6c2h1dGRv
d24pOgorICAgICAgICAgICAgLSBVbndpbmQgb3VyIHVnbHksIHVnbHkgaGFjayB0byBtYWtlIHRo
ZSBXaW5kb3dzIGNvbXBvbmVudCBidWlsZAorICAgICAgICAgICAgICB3b3JrLgorCiAyMDEyLTA0
LTAzICBZdXRhIEtpdGFtdXJhICA8eXV0YWtAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIENyYXNo
IGluIFdlYkNvcmU6OldvcmtlclRocmVhZGFibGVXZWJTb2NrZXRDaGFubmVsOjpCcmlkZ2U6Om1h
aW5UaHJlYWRDcmVhdGVXZWJTb2NrZXRDaGFubmVsCkluZGV4OiBTb3VyY2UvV2ViS2l0L2Nocm9t
aXVtL1dlYktpdC5neXAKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gU291cmNlL1dlYktpdC9jaHJvbWl1bS9XZWJL
aXQuZ3lwCShyZXZpc2lvbiAxMTMxMzYpCisrKyBTb3VyY2UvV2ViS2l0L2Nocm9taXVtL1dlYktp
dC5neXAJKHdvcmtpbmcgY29weSkKQEAgLTkxLDYgKzkxLDcgQEAKICAgICAgICAgICAgICAgICAn
V0VCS0lUX0lNUExFTUVOVEFUSU9OPTEnLAogICAgICAgICAgICAgXSwKICAgICAgICAgICAgICdz
b3VyY2VzJzogWworICAgICAgICAgICAgICAgICc8QCh3ZWJjb3JlX3BsYXRmb3JtX3N1cHBvcnRf
ZmlsZXMpJywKICAgICAgICAgICAgICAgICAncHVibGljL1dlYkFjY2Vzc2liaWxpdHlOb3RpZmlj
YXRpb24uaCcsCiAgICAgICAgICAgICAgICAgJ3B1YmxpYy9XZWJBY2Nlc3NpYmlsaXR5T2JqZWN0
LmgnLAogICAgICAgICAgICAgICAgICdwdWJsaWMvV2ViQWNjZXNzaWJpbGl0eVJvbGUuaCcsCklu
ZGV4OiBTb3VyY2UvV2ViS2l0L2Nocm9taXVtL3NyYy9XZWJLaXQuY3BwCj09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t
IFNvdXJjZS9XZWJLaXQvY2hyb21pdW0vc3JjL1dlYktpdC5jcHAJKHJldmlzaW9uIDExMzEzNikK
KysrIFNvdXJjZS9XZWJLaXQvY2hyb21pdW0vc3JjL1dlYktpdC5jcHAJKHdvcmtpbmcgY29weSkK
QEAgLTQ2LDcgKzQ2LDYgQEAKICNpbmNsdWRlICJwbGF0Zm9ybS9XZWJUaHJlYWQuaCIKICNpbmNs
dWRlICJ2OC5oIgogI2luY2x1ZGUgPHB1YmxpYy9QbGF0Zm9ybS5oPgotI2luY2x1ZGUgPHB1Ymxp
Yy9XZWJNZWRpYVN0cmVhbVNvdXJjZXNSZXF1ZXN0Lmg+CiAjaW5jbHVkZSA8d3RmL0Fzc2VydGlv
bnMuaD4KICNpbmNsdWRlIDx3dGYvTWFpblRocmVhZC5oPgogI2luY2x1ZGUgPHd0Zi9UaHJlYWRp
bmcuaD4KQEAgLTE2NSwxNCArMTY0LDYgQEAgdm9pZCBzaHV0ZG93bigpCiAjZW5kaWYKICAgICBz
X3dlYktpdFBsYXRmb3JtU3VwcG9ydCA9IDA7CiAgICAgUGxhdGZvcm06OnNodXRkb3duKCk7Ci0K
LSAgICAvLyBUaGlzIGZ1bmN0aW9uIGNhbGwgZXhpc3RzIHRvIG1ha2Ugc3VyZSBXZWJNZWRpYVN0
cmVhbVNvdXJjZXNSZXF1ZXN0Lm9iagotICAgIC8vIGdldHMgcHVsbGVkIGludG8gdGhlIFdpbmRv
d3MgY29tcG9uZW50IGJ1aWxkLiAoU2VlIGNvbW1lbnQgaW4KLSAgICAvLyBXZWJNZWRpYVN0cmVh
bVNvdXJjZXNSZXF1ZXN0LmguKQotICAgIC8vCi0gICAgLy8gRklYTUU6IFJlbW92ZSB0aGlzIGNh
bGwgb25jZSB3ZSBmaWd1cmUgb3V0IHRoZSByaWdodCB3YXkgdG8gZml4IHRoZXNlCi0gICAgLy8g
bGluayBlcnJvcnMuCi0gICAgV2ViTWVkaWFTdHJlYW1Tb3VyY2VzUmVxdWVzdDo6ZHVtbXkoKTsK
IH0KIAogV2ViS2l0UGxhdGZvcm1TdXBwb3J0KiB3ZWJLaXRQbGF0Zm9ybVN1cHBvcnQoKQo=
</data>

          </attachment>
      

    </bug>

</bugzilla>