<?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>28886</bug_id>
          
          <creation_ts>2009-09-01 12:46:12 -0700</creation_ts>
          <short_desc>Build error using JIT with gcc 4.1.2 and ARM v5</short_desc>
          <delta_ts>2009-09-28 11:57:59 -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>Other</rep_platform>
          <op_sys>Linux</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="Andre Pedralho">apedralho</reporter>
          <assigned_to name="Nobody">webkit-unassigned</assigned_to>
          <cc>arabelo</cc>
    
    <cc>barraclough</cc>
    
    <cc>eric</cc>
    
    <cc>hausmann</cc>
    
    <cc>kenneth</cc>
    
    <cc>laszlo.gombos</cc>
    
    <cc>loki</cc>
    
    <cc>ricardo.salveti</cc>
    
    <cc>tonikitoo</cc>
    
    <cc>zherczeg</cc>
    
    <cc>zoltan</cc>
          

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>143979</commentid>
    <comment_count>0</comment_count>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-01 12:46:12 -0700</bug_when>
    <thetext>g++ -c -pipe -Wreturn-type -fno-strict-aliasing -ffunction-sections
-fdata-sections -O2 -D_REENTRANT -fPIC -DENABLE_YARR=1
-DENABLE_YARR_JIT=1 -DENABLE_JIT=1 -DBUILDING_QT__=1 -DUSE_SYSTEM_MALLOC
-DNDEBUG -DQT_MAKEDLL -DHAVE_STDINT_H -DBUILD_WEBKIT
-DENABLE_JAVASCRIPT_DEBUGGER=1 -DENABLE_DATABASE=1
-DENABLE_EVENTSOURCE=1 -DENABLE_OFFLINE_WEB_APPLICATIONS=1
-DENABLE_DOM_STORAGE=1 -DENABLE_ICONDATABASE=1
-DENABLE_CHANNEL_MESSAGING=1 -DENABLE_SQLITE=1
-DENABLE_DASHBOARD_SUPPORT=0 -DENABLE_FILTERS=0 -DENABLE_XPATH=1
-DENABLE_XSLT=0 -DENABLE_WCSS=0 -DENABLE_WML=0 -DENABLE_SHARED_WORKERS=0
-DENABLE_WORKERS=1 -DENABLE_XHTMLMP=0 -DENABLE_DATAGRID=1 -DENABLE_SVG=1
-DENABLE_SVG_FONTS=1 -DENABLE_SVG_FOREIGN_OBJECT=1
-DENABLE_SVG_ANIMATION=1 -DENABLE_SVG_AS_IMAGE=1 -DENABLE_SVG_USE=1
-DENABLE_RUBY=1 -DENABLE_VIDEO=1 -DENABLE_DATALIST=1
-DENABLE_NETSCAPE_PLUGIN_API=1 -DWTF_USE_JAVASCRIPTCORE_BINDINGS=1
-DWTF_CHANGES=1 -DBUILDING_QT__ -DBUILDING_JavaScriptCore -DBUILDING_WTF
-DENABLE_PLUGIN_PACKAGE_SIMPLE_HASH=1 -DXP_UNIX -DQT_NO_DEBUG
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/linux-g++ -I../../../WebCore
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork
-I/usr/include/qt4/QtGui -I/usr/include/qt4 -I../../../WebCore/bridge/qt
-I../../../WebCore/page/qt -I../../../WebCore/platform/graphics/qt
-I../../../WebCore/platform/network/qt -I../../../WebCore/platform/qt
-I../../../WebKit/qt/WebCoreSupport -I../../../WebCore
-I../../../WebCore/accessibility -I../../../WebCore/bindings/js
-I../../../WebCore/bridge -I../../../WebCore/bridge/c
-I../../../WebCore/css -I../../../WebCore/dom
-I../../../WebCore/dom/default -I../../../WebCore/editing
-I../../../WebCore/history -I../../../WebCore/html
-I../../../WebCore/html/canvas -I../../../WebCore/inspector
-I../../../WebCore/loader -I../../../WebCore/loader/appcache
-I../../../WebCore/loader/archive -I../../../WebCore/loader/icon
-I../../../WebCore/notifications -I../../../WebCore/page
-I../../../WebCore/page/animation -I../../../WebCore/platform
-I../../../WebCore/platform/animation
-I../../../WebCore/platform/graphics
-I../../../WebCore/platform/graphics/filters
-I../../../WebCore/platform/graphics/transforms
-I../../../WebCore/platform/image-decoders
-I../../../WebCore/platform/network -I../../../WebCore/platform/sql
-I../../../WebCore/platform/text -I../../../WebCore/plugins
-I../../../WebCore/rendering -I../../../WebCore/rendering/style
-I../../../WebCore/storage -I../../../WebCore/svg
-I../../../WebCore/svg/animation -I../../../WebCore/svg/graphics
-I../../../WebCore/svg/graphics/filters -I../../../WebCore/wml
-I../../../WebCore/workers -I../../../WebCore/xml -Igenerated/release
-I../../../JavaScriptCore -I../../../../webkit
-I../../../JavaScriptCore/assembler -I../../../JavaScriptCore/bytecode
-I../../../JavaScriptCore/bytecompiler
-I../../../JavaScriptCore/debugger -I../../../JavaScriptCore/interpreter
-I../../../JavaScriptCore/jit -I../../../JavaScriptCore/parser
-I../../../JavaScriptCore/profiler -I../../../JavaScriptCore/runtime
-I../../../JavaScriptCore/wrec -I../../../JavaScriptCore/wtf
-I../../../JavaScriptCore/wtf/unicode -I../../../JavaScriptCore/yarr
-I../../../JavaScriptCore/API
-I../../../JavaScriptCore/ForwardingHeaders -Igenerated/release
-I../../../WebKit/qt/Api -I../../../JavaScriptCore/pcre
-I/home/root/webkit/WebKitBuild/Release/JavaScriptCore/tmp
-I/usr/src/3rdparty/sqlite/ -I/usr/include/qt4/phonon
-I/usr/X11R6/include -I. -I../../../WebCore -I. -o obj/release/JSBase.o
../../../JavaScriptCore/API/JSBase.cpp
../../../JavaScriptCore/jit/ExecutableAllocator.h: In static member
function &apos;static void JSC::ExecutableAllocator::cacheFlush(void*, size_t)&apos;:
../../../JavaScriptCore/jit/ExecutableAllocator.h:189: error:
&apos;__clear_cache&apos; was not declared in this scope
make[1]: *** [obj/release/JSBase.o] Error 1

The error persists even building with the command below:
WebKitTools/Scripts/build-webkit --qt ENABLE_YARR=1 ENABLE_YARR_JIT=1 ENABLE_JIT=1 WTF_USE_JSVALUE32=1</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>144479</commentid>
    <comment_count>1</comment_count>
    <who name="Antonio Gomes">tonikitoo</who>
    <bug_when>2009-09-03 04:41:24 -0700</bug_when>
    <thetext>pedralho, any luck to build w/ jit, yacc and friends all off ?

please also inform revision you were at.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>144495</commentid>
    <comment_count>2</comment_count>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-03 06:21:57 -0700</bug_when>
    <thetext>(In reply to comment #1)
&gt; pedralho, any luck to build w/ jit, yacc and friends all off ?
&gt; 
&gt; please also inform revision you were at.

No luck, I reseted my tree to ToT (svn r48016) and tried to rebuild getting the following error:

g++ -c -pipe -Wreturn-type -fno-strict-aliasing -ffunction-sections -fdata-sections -O2 -D_REENTRANT -fPIC -DENABLE_VIDEO=0 -DBUILDING_QT__=1 -DUSE_SYSTEM_MALLOC -DNDEBUG -DQT_MAKEDLL -DHAVE_STDINT_H -DBUILD_WEBKIT -DENABLE_JAVASCRIPT_DEBUGGER=1 -DENABLE_DATABASE=1 -DENABLE_EVENTSOURCE=1 -DENABLE_OFFLINE_WEB_APPLICATIONS=1 -DENABLE_DOM_STORAGE=1 -DENABLE_ICONDATABASE=1 -DENABLE_CHANNEL_MESSAGING=1 -DENABLE_SQLITE=1 -DENABLE_DASHBOARD_SUPPORT=0 -DENABLE_FILTERS=0 -DENABLE_XPATH=1 -DENABLE_XSLT=0 -DENABLE_WCSS=0 -DENABLE_WML=0 -DENABLE_SHARED_WORKERS=0 -DENABLE_WORKERS=1 -DENABLE_XHTMLMP=0 -DENABLE_DATAGRID=1 -DENABLE_SVG=1 -DENABLE_SVG_FONTS=1 -DENABLE_SVG_FOREIGN_OBJECT=1 -DENABLE_SVG_ANIMATION=1 -DENABLE_SVG_AS_IMAGE=1 -DENABLE_SVG_USE=1 -DENABLE_RUBY=1 -DENABLE_DATALIST=1 -DENABLE_NETSCAPE_PLUGIN_API=1 -DWTF_USE_JAVASCRIPTCORE_BINDINGS=1 -DWTF_CHANGES=1 -DBUILDING_QT__ -DBUILDING_JavaScriptCore -DBUILDING_WTF -DENABLE_PLUGIN_PACKAGE_SIMPLE_HASH=1 -DXP_UNIX -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I../../../WebCore -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I../../../WebCore/bridge/qt -I../../../WebCore/page/qt -I../../../WebCore/platform/graphics/qt -I../../../WebCore/platform/network/qt -I../../../WebCore/platform/qt -I../../../WebKit/qt/WebCoreSupport -I../../../WebCore -I../../../WebCore/accessibility -I../../../WebCore/bindings/js -I../../../WebCore/bridge -I../../../WebCore/bridge/c -I../../../WebCore/css -I../../../WebCore/dom -I../../../WebCore/dom/default -I../../../WebCore/editing -I../../../WebCore/history -I../../../WebCore/html -I../../../WebCore/html/canvas -I../../../WebCore/inspector -I../../../WebCore/loader -I../../../WebCore/loader/appcache -I../../../WebCore/loader/archive -I../../../WebCore/loader/icon -I../../../WebCore/notifications -I../../../WebCore/page -I../../../WebCore/page/animation -I../../../WebCore/platform -I../../../WebCore/platform/animation -I../../../WebCore/platform/graphics -I../../../WebCore/platform/graphics/filters -I../../../WebCore/platform/graphics/transforms -I../../../WebCore/platform/image-decoders -I../../../WebCore/platform/network -I../../../WebCore/platform/sql -I../../../WebCore/platform/text -I../../../WebCore/plugins -I../../../WebCore/rendering -I../../../WebCore/rendering/style -I../../../WebCore/storage -I../../../WebCore/svg -I../../../WebCore/svg/animation -I../../../WebCore/svg/graphics -I../../../WebCore/svg/graphics/filters -I../../../WebCore/wml -I../../../WebCore/workers -I../../../WebCore/xml -Igenerated/release -I../../../JavaScriptCore -I../../../../mainline -I../../../JavaScriptCore/assembler -I../../../JavaScriptCore/bytecode -I../../../JavaScriptCore/bytecompiler -I../../../JavaScriptCore/debugger -I../../../JavaScriptCore/interpreter -I../../../JavaScriptCore/jit -I../../../JavaScriptCore/parser -I../../../JavaScriptCore/profiler -I../../../JavaScriptCore/runtime -I../../../JavaScriptCore/wrec -I../../../JavaScriptCore/wtf -I../../../JavaScriptCore/wtf/unicode -I../../../JavaScriptCore/yarr -I../../../JavaScriptCore/API -I../../../JavaScriptCore/ForwardingHeaders -Igenerated/release -I../../../WebKit/qt/Api -I../../../JavaScriptCore/pcre -I/home/root/bluebox/webkit/mainline/WebKitBuild/Release/JavaScriptCore/tmp -I/usr/src/3rdparty/sqlite/ -I/usr/X11R6/include -I. -I../../../WebCore -I. -o obj/release/JSBase.o ../../../JavaScriptCore/API/JSBase.cpp
../../../JavaScriptCore/jit/ExecutableAllocator.h: In static member function &apos;static void JSC::ExecutableAllocator::cacheFlush(void*, size_t)&apos;:
../../../JavaScriptCore/jit/ExecutableAllocator.h:189: error: &apos;__clear_cache&apos; was not declared in this scope
make[1]: *** [obj/release/JSBase.o] Error 1
make[1]: Leaving directory `/home/root/bluebox/webkit/mainline/WebKitBuild/Release/WebCore&apos;
make: *** [sub-WebCore-make_default-ordered] Error 2</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>144527</commentid>
    <comment_count>3</comment_count>
    <who name="Zoltan Herczeg">zherczeg</who>
    <bug_when>2009-09-03 08:24:59 -0700</bug_when>
    <thetext>I think this cause the issue:

&gt; &apos;__clear_cache&apos; was not declared in this scope
&gt; make[1]: *** [obj/release/JSBase.o] Error 1

This is a gcc builtin function. Please check if its interface is declared.

see the &quot;static void cacheFlush(void* code, size_t size)&quot; in
JavaScriptCore/jit/ExecutableAllocator.h

This function calls a kernel utility to flush data cache memory (unfortunately the required mrc instruction is only executable in kernel level).

There is a native NAPI implementation in the code if __clear_cache is not declared in your gcc. If you have other solution for flushing the data cache, just call that function.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>144929</commentid>
    <comment_count>4</comment_count>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-04 15:15:01 -0700</bug_when>
    <thetext>(In reply to comment #3)
&gt; I think this cause the issue:
&gt; 
&gt; This is a gcc builtin function. Please check if its interface is declared.
&gt; 
I copied a simple test (from here http://code.google.com/p/android/issues/detail?id=1803) and it builds and runs fine in the same environment.

#include &lt;stdio.h&gt;

int main(int argc, char **argv)
{
    printf(&quot;attempting toolchain clearcache syscall:\n&quot;);
    __clear_cache(0, 0);
    return 0;                                        
}

I couldn&apos;t find the __clear_cache in any system header file, but could find it in 4.1.2/libgcc.a and 4.1.2/libgcc_s.so.

Then I added an &quot;extern void __clear_cache (char *beg, char *end);&quot; before using __clear_cache in ExecutableAllocator.h. The result:

obj/release/ARMAssembler.o: In function `JSC::ARMAssembler::linkBranch(void*, JSC::ARMAssembler::JmpSrc, void*, int)&apos;:
ARMAssembler.cpp:(.text+0x1b8): undefined reference to `JSC::__clear_cache(char*, char*)&apos;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>144987</commentid>
    <comment_count>5</comment_count>
    <who name="Zoltan Herczeg">zherczeg</who>
    <bug_when>2009-09-05 00:28:34 -0700</bug_when>
    <thetext>&gt; I couldn&apos;t find the __clear_cache in any system header file, but could find it
&gt; in 4.1.2/libgcc.a and 4.1.2/libgcc_s.so.

Good!

&gt; Then I added an &quot;extern void __clear_cache (char *beg, char *end);&quot; before
&gt; using __clear_cache in ExecutableAllocator.h. The result:
&gt; 
&gt; obj/release/ARMAssembler.o: In function `JSC::ARMAssembler::linkBranch(void*,
&gt; JSC::ARMAssembler::JmpSrc, void*, int)&apos;:
&gt; ARMAssembler.cpp:(.text+0x1b8): undefined reference to
&gt; `JSC::__clear_cache(char*, char*)&apos;

__clear_cache is a C function not C++, and does not belongs to JSC namespace.

try this (outside of &quot;namespace JSC&quot;, for example put it before the #include-s in a C++ file)

extern &quot;C&quot; {
    void __clear_cache (char *beg, char *end);
}

(You don&apos;t need to put extern before a function declaration. The semicolon does the magic.)</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145357</commentid>
    <comment_count>6</comment_count>
      <attachid>39186</attachid>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-08 08:06:33 -0700</bug_when>
    <thetext>Created attachment 39186
Adding the __clear_cache header according to the comment above.

This patch fixes this bug.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145361</commentid>
    <comment_count>7</comment_count>
    <who name="Zoltan Herczeg">zherczeg</who>
    <bug_when>2009-09-08 08:33:37 -0700</bug_when>
    <thetext>(In reply to comment #6)
&gt; Created an attachment (id=39186) [details]
&gt; Adding the __clear_cache header according to the comment above.
&gt; 
&gt; This patch fixes this bug.

Please put #if PLATFORM(ARM) around the definition. Anyway, do you know why this function is not defined in your gcc? Are you tested it on your platform?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145362</commentid>
    <comment_count>8</comment_count>
      <attachid>39188</attachid>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-08 08:34:11 -0700</bug_when>
    <thetext>Created attachment 39188
Updated ToT, added ifdefs and changelog according to loki04 suggestions in #qtwebkit.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145412</commentid>
    <comment_count>9</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-09-08 10:07:48 -0700</bug_when>
    <thetext>Should this be guarded &lt;= a GCC version?  Or is this expected that this symbol will always be missing and need our own extern declaration?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145425</commentid>
    <comment_count>10</comment_count>
    <who name="Zoltan Herczeg">zherczeg</who>
    <bug_when>2009-09-08 10:26:32 -0700</bug_when>
    <thetext>(In reply to comment #9)
&gt; Should this be guarded &lt;= a GCC version?  Or is this expected that this symbol
&gt; will always be missing and need our own extern declaration?

I was wondering about it myself. If __clear_cache is defined in the same way, it doesn&apos;t matter duplicating it. However, what&apos;s happen if not? (I saw a macro definition for __clear_cache somewhere else, which replaces it another function. Unfortunately I didn&apos;t remember where) The strange thing is for me, that GCC 4.1.2 should define this function... Especially because only its forward declaration is missing, not the function body.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145426</commentid>
    <comment_count>11</comment_count>
    <who name="Zoltan Herczeg">zherczeg</who>
    <bug_when>2009-09-08 10:28:39 -0700</bug_when>
    <thetext>http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gccint/Miscellaneous-routines.html

Misc function for gcc 4.1.2</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145427</commentid>
    <comment_count>12</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-09-08 10:29:18 -0700</bug_when>
    <thetext>Probably not related, but just in case: http://code.google.com/p/android/issues/detail?id=1803</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145431</commentid>
    <comment_count>13</comment_count>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-09-08 10:32:15 -0700</bug_when>
    <thetext>Searching for __clear_cache in gcc&apos;s bugzilla yields no results: http://gcc.gnu.org/bugzilla/  It seems we should file one and reference it in whatever fix we take.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145553</commentid>
    <comment_count>14</comment_count>
      <attachid>39188</attachid>
    <who name="Eric Seidel (no email)">eric</who>
    <bug_when>2009-09-08 14:55:33 -0700</bug_when>
    <thetext>Comment on attachment 39188
Updated ToT, added ifdefs and changelog according to loki04 suggestions in #qtwebkit.

We really should file a bug with GCC (per their public bug tracker) and link to it in this ChangeLog.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145643</commentid>
    <comment_count>15</comment_count>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-08 21:26:20 -0700</bug_when>
    <thetext>(In reply to comment #14)
&gt; (From update of attachment 39188 [details])
&gt; We really should file a bug with GCC (per their public bug tracker) and link to
&gt; it in this ChangeLog.

It is not a GCC bug. I could build* and run the example given in the link in comment #12:

 #include &lt;stdio.h&gt;

 int main(int argc, char **argv)
 {
    printf(&quot;attempting toolchain clearcache syscall:\n&quot;);
    __clear_cache(0, 0);
    return 0;
 }

* no extra arguments given to build nor run.

ps. There were no need even to add the __clear_cache header definition.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145711</commentid>
    <comment_count>16</comment_count>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-09 05:28:12 -0700</bug_when>
    <thetext>(In reply to comment #14)
&gt; (From update of attachment 39188 [details])
&gt; We really should file a bug with GCC (per their public bug tracker) and link to
&gt; it in this ChangeLog.

I did the same test in comment #15 but using a .cpp file and building using g++:

teste.cpp:6: error: &apos;__clear_cache&apos; was not declared in this scope</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145721</commentid>
    <comment_count>17</comment_count>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-09 06:39:39 -0700</bug_when>
    <thetext>I did a quick test with 4.3.2, and the example works with gcc and g++ as well.
I am going to examine what this is about gcc 4.1.2 .</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>145751</commentid>
    <comment_count>18</comment_count>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-09 07:56:35 -0700</bug_when>
    <thetext>(In reply to comment #17)
&gt; I did a quick test with 4.3.2, and the example works with gcc and g++ as well.
&gt; I am going to examine what this is about gcc 4.1.2 .

Well, this is not a WebKit bug. G++ 4.1.1 from CodeSourcery (2006q3) also has this bug. The most common error, which could cause this kind of error, is that in the first compilation of gcc have to be compiled without headers and the 2nd one should use library headers. I do not think that they did a wrong packaging/configuring.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>146547</commentid>
    <comment_count>19</comment_count>
    <who name="Laszlo Gombos">laszlo.gombos</who>
    <bug_when>2009-09-11 07:17:02 -0700</bug_when>
    <thetext>I think Andre Pedralho or someone else should not only check that it compiles and links, but also that the __clear_cache actually clears the instruction cache. As it was pointed in the Android related discussion (http://code.google.com/p/android/issues/detail?id=1803) the __clear_cache call could be a no-op, which would than break the JIT functionality.

Also maybe WebKit can do a bit better guarding the __clear_cache call and the fallback assembly code. Fill post a patch for consideration.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>146550</commentid>
    <comment_count>20</comment_count>
      <attachid>39430</attachid>
    <who name="Laszlo Gombos">laszlo.gombos</who>
    <bug_when>2009-09-11 07:26:12 -0700</bug_when>
    <thetext>Created attachment 39430
Be more specific with guards.

1./ It looks to me that not only the __clear_cache call but also the fallback assembly assumes GCC (as the assembly syntax is compiler specific) - so maybe this whole code section should be guarded with COMPILER(GCC).

2./ It might be better to use the CLEAR_INSN_CACHE guard to test if __clear_cache is available than testing for a specific GCC version. Andre can you see if CLEAR_INSN_CACHE is defined in your environment.

3./ The fallback ARM code seems to call a Linux system call and as such it would only work on Linux, so maybe we should have a guard for that as well. 

4./ I would also suggest #error messages for the platforms currently not supported</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>146606</commentid>
    <comment_count>21</comment_count>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-11 09:31:13 -0700</bug_when>
    <thetext>&gt; 2./ It might be better to use the CLEAR_INSN_CACHE guard to test if
&gt; __clear_cache is available than testing for a specific GCC version. Andre can
&gt; you see if CLEAR_INSN_CACHE is defined in your environment.

CLEAR_INSN_CACHE is definied in gcc/config/arm/linux-eabi.h (GCC source), but it is not explicitly exported. You can check the predefinied macros with &apos;gcc -c -E -dM empty.file&apos; command.

So, we are not able to use CLEAR_INSN_CACHE. The current guard it better. The _clear_cache function is available since GCC 3.4.6 from lib1funcs.asm.

Btw, please use &apos;#else&apos; directive instead of &apos;#elif&apos; without expression.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>146643</commentid>
    <comment_count>22</comment_count>
      <attachid>39450</attachid>
    <who name="Laszlo Gombos">laszlo.gombos</who>
    <bug_when>2009-09-11 10:51:01 -0700</bug_when>
    <thetext>Created attachment 39450
incorporate Gabor&apos;s comments.

Gabor thanks for the review. If CLEAR_INSN_CACHE test does not work than the patch is less useful, but maybe still valid.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>147129</commentid>
    <comment_count>23</comment_count>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-14 12:01:56 -0700</bug_when>
    <thetext>Sorry by the delay!

(In reply to comment #19)
&gt; I think Andre Pedralho or someone else should not only check that it compiles
&gt; and links, but also that the __clear_cache actually clears the instruction
&gt; cache. As it was pointed in the Android related discussion
&gt; (http://code.google.com/p/android/issues/detail?id=1803) the __clear_cache call
&gt; could be a no-op, which would than break the JIT functionality.
&gt;
I could run it using strace and it calls both operation (the g++ __clear_cache and th system __asm __volatile...) defined in http://code.google.com/p/android/issues/detail?id=1803

cacheflush(0, 0, 0, 0x1, 0x40022db0)    = 0
cacheflush(0, 0, 0, 0xf0002, 0x40022db0) = 0

&gt; Also maybe WebKit can do a bit better guarding the __clear_cache call and the
&gt; fallback assembly code. Fill post a patch for consideration.


(In reply to comment #20)
&gt; Created an attachment (id=39430) [details]
&gt; Be more specific with guards.
&gt; 
&gt; 2./ It might be better to use the CLEAR_INSN_CACHE guard to test if
&gt; __clear_cache is available than testing for a specific GCC version. Andre can
&gt; you see if CLEAR_INSN_CACHE is defined in your environment.
&gt;
No, it is not defined. So I don&apos;t know if __clear_cache is really clearing cache. The code below builds fine:

#ifdef CLEAR_INSN_CACHE
    xxxxxx
#endif</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149052</commentid>
    <comment_count>24</comment_count>
      <attachid>39925</attachid>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-22 08:01:06 -0700</bug_when>
    <thetext>Created attachment 39925
Avoid __clear_cache built-in function if NO_CLEAR_CACHE define is set

This patch adds an additional check for __clear_cache. If NO_CLEAR_CACHE is set the execution will skip __clear_cache case.

I have also fixed a silly typo in the inline assembly.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149053</commentid>
    <comment_count>25</comment_count>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-22 08:04:38 -0700</bug_when>
    <thetext>(In reply to comment #22)
&gt; Created an attachment (id=39450) [details]

Laszlo, I think your patch is obsolete now. I did a small refactoring earlier.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149055</commentid>
    <comment_count>26</comment_count>
      <attachid>39925</attachid>
    <who name="Darin Adler">darin</who>
    <bug_when>2009-09-22 08:21:16 -0700</bug_when>
    <thetext>Comment on attachment 39925
Avoid __clear_cache built-in function if NO_CLEAR_CACHE define is set

The change log mentions only one change, but there&apos;s also a change to the assembly code. Is that second change unintentional or is it the change log that needs to be updated?</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149057</commentid>
    <comment_count>27</comment_count>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-22 08:37:46 -0700</bug_when>
    <thetext>(In reply to comment #24)
&gt; Created an attachment (id=39925) [details]
&gt; Avoid __clear_cache built-in function if NO_CLEAR_CACHE define is set
&gt; 
&gt; This patch adds an additional check for __clear_cache. If NO_CLEAR_CACHE is set
&gt; the execution will skip __clear_cache case.
&gt; 
&gt; I have also fixed a silly typo in the inline assembly.

As I told you in #qtwebkit: we are fixing the issue disabling the feature,
aren&apos;t we? I know it is a very specific case (ARM and GCC 4.1.2).

Couldn&apos;t we do something using CLEAR_INSN_CACHE (as we don&apos;t have it defined)?
BTW, does anybody have it defined?

- #elif PLATFORM(ARM) &amp;&amp; COMPILER(GCC) &amp;&amp; (GCC_VERSION &gt;= 30406)
+ #elif PLATFORM(ARM) &amp;&amp; COMPILER(GCC) &amp;&amp; (GCC_VERSION &gt;= 30406) &amp;&amp;
defined(CLEAR_INSN_CACHE)   
     static void cacheFlush(void* code, size_t size)
     {   
         __clear_cache(reinterpret_cast&lt;char*&gt;(code),
reinterpret_cast&lt;char*&gt;(code) + size);
     }
- #elif PLATFORM(ARM_TRADITIONAL) &amp;&amp; PLATFORM(LINUX)
+ #elif PLATFORM(ARM_TRADITIONAL) &amp;&amp; PLATFORM(LINUX) ||
!defined(CLEAR_INSN_CACHE)
     static void cacheFlush(void* code, size_t size)
     {   
         asm volatile (
             &quot;push    {r7}\n&quot;
             &quot;mov     r0, %0\n&quot;</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149061</commentid>
    <comment_count>28</comment_count>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-22 08:54:42 -0700</bug_when>
    <thetext>(In reply to comment #26)
&gt; The change log mentions only one change, but there&apos;s also a change to the
&gt; assembly code.

You are right. There was a small typo in the inline asm. I will update the ChangeLog if this solution is fine for Andre as well.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149066</commentid>
    <comment_count>29</comment_count>
      <attachid>39927</attachid>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-22 09:23:51 -0700</bug_when>
    <thetext>Created attachment 39927
Avoid __clear_cache built-in function if DISABLE_BUILTIN_CLEAR_CACHE define is set

Updated the name of the define and the ChangeLog entry as well.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149123</commentid>
    <comment_count>30</comment_count>
    <who name="Andre Pedralho">apedralho</who>
    <bug_when>2009-09-22 11:01:40 -0700</bug_when>
    <thetext>(In reply to comment #28)
&gt; (In reply to comment #26)
&gt; &gt; The change log mentions only one change, but there&apos;s also a change to the
&gt; &gt; assembly code.
&gt; 
&gt; You are right. There was a small typo in the inline asm. I will update the
&gt; ChangeLog if this solution is fine for Andre as well.

It is fine for me. Thanks again Loki!

The new define name (DISABLE_BUILTIN_CLEAR_CACHE) is more intuitive than the older (NO_CLEAR_CACHE) for what it really does and unfortunately my suggestion in comment #23 would not work as CLEAR_INSN_CACHE is a GCC internal define.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149155</commentid>
    <comment_count>31</comment_count>
      <attachid>39450</attachid>
    <who name="Laszlo Gombos">laszlo.gombos</who>
    <bug_when>2009-09-22 12:49:54 -0700</bug_when>
    <thetext>Comment on attachment 39450
incorporate Gabor&apos;s comments.

This is now obsolete thanks to Gabor after http://trac.webkit.org/changeset/48527. Laszlo.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149523</commentid>
    <comment_count>32</comment_count>
    <who name="Gavin Barraclough">barraclough</who>
    <bug_when>2009-09-23 15:33:41 -0700</bug_when>
    <thetext>Just r+ing the last patch, since it is not clear to me from the comments whether the first is still required by anyone.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149654</commentid>
    <comment_count>33</comment_count>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-23 21:57:47 -0700</bug_when>
    <thetext>(In reply to comment #32)
&gt; Just r+ing the last patch, since it is not clear to me from the comments
&gt; whether the first is still required by anyone.

AFAIK Andre is happy with the last patch. 

The attachment 39188 (the first patch) is not a good approach to achieve access to clear cache.

I will file a bug report about this in GCC&apos;s bugzilla.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>149676</commentid>
    <comment_count>34</comment_count>
    <who name="Zoltan Horvath">zoltan</who>
    <bug_when>2009-09-23 23:12:48 -0700</bug_when>
    <thetext>Landed in @48702. http://trac.webkit.org/changeset/48702</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>150523</commentid>
    <comment_count>35</comment_count>
      <attachid>40240</attachid>
    <who name="Gabor Loki">loki</who>
    <bug_when>2009-09-28 09:19:35 -0700</bug_when>
    <thetext>Created attachment 40240
Remove __clear_cache which is an internal function of GCC

Finally I got an concrete answer from GCC about __clear_cache.

Although __clear_cache is exported from GCC, it is an internal function. GCC makes no promises about it. So, we should remove it.

The remaining flushing mechanism will be the inline assembly on ARM-Linux.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>150592</commentid>
    <comment_count>36</comment_count>
      <attachid>40240</attachid>
    <who name="Simon Hausmann">hausmann</who>
    <bug_when>2009-09-28 11:56:26 -0700</bug_when>
    <thetext>Comment on attachment 40240
Remove __clear_cache which is an internal function of GCC

Thanks Gabor!</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>150594</commentid>
    <comment_count>37</comment_count>
    <who name="Simon Hausmann">hausmann</who>
    <bug_when>2009-09-28 11:57:59 -0700</bug_when>
    <thetext>Committed r48824: &lt;http://trac.webkit.org/changeset/48824&gt;</thetext>
  </long_desc>
      
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>39186</attachid>
            <date>2009-09-08 08:06:33 -0700</date>
            <delta_ts>2009-09-08 08:34:11 -0700</delta_ts>
            <desc>Adding the __clear_cache header according to the comment above.</desc>
            <filename>added_clear_cache_header.diff</filename>
            <type>text/plain</type>
            <size>558</size>
            <attacher name="Andre Pedralho">apedralho</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL2ppdC9FeGVjdXRhYmxlQWxsb2NhdG9yLmggYi9K
YXZhU2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJsZUFsbG9jYXRvci5oCmluZGV4IDRlZDQ3ZTMuLmU0
MGZhN2QgMTAwNjQ0Ci0tLSBhL0phdmFTY3JpcHRDb3JlL2ppdC9FeGVjdXRhYmxlQWxsb2NhdG9y
LmgKKysrIGIvSmF2YVNjcmlwdENvcmUvaml0L0V4ZWN1dGFibGVBbGxvY2F0b3IuaApAQCAtMjYs
NiArMjYsMTAgQEAKICNpZm5kZWYgRXhlY3V0YWJsZUFsbG9jYXRvcl9oCiAjZGVmaW5lIEV4ZWN1
dGFibGVBbGxvY2F0b3JfaAogCitleHRlcm4gIkMiIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKKyAgICB2b2lk
IF9fY2xlYXJfY2FjaGUoY2hhciAqYmVnLCBjaGFyICplbmQpOyAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIAorfQorCiAjaW5jbHVkZSA8bGltaXRzPgogI2luY2x1ZGUgPHd0
Zi9Bc3NlcnRpb25zLmg+CiAjaW5jbHVkZSA8d3RmL1Bhc3NSZWZQdHIuaD4K
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>39188</attachid>
            <date>2009-09-08 08:34:11 -0700</date>
            <delta_ts>2009-09-08 14:55:33 -0700</delta_ts>
            <desc>Updated ToT, added ifdefs and changelog according to loki04 suggestions in #qtwebkit.</desc>
            <filename>added_clear_cache_header.diff</filename>
            <type>text/plain</type>
            <size>1149</size>
            <attacher name="Andre Pedralho">apedralho</attacher>
            
              <data encoding="base64">ZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZyBiL0phdmFTY3JpcHRDb3JlL0No
YW5nZUxvZwppbmRleCBiMzAwNmJmLi5mZjM4ZGViIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29y
ZS9DaGFuZ2VMb2cKKysrIGIvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTIg
QEAKKzIwMDktMDktMDggIEFuZHJlIFBlZHJhbGhvICA8YW5kcmUucGVkcmFsaG9Ab3BlbmJvc3Nh
Lm9yZz4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBG
aXhlZCBidWlsZCBlcnJvciB1c2luZyBKSVQgd2l0aCBnY2MgNC4xLjIgYW5kIEFSTSB2NS4KKyAg
ICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTI4ODg2CisKKyAg
ICAgICAgKiBqaXQvRXhlY3V0YWJsZUFsbG9jYXRvci5oOgorCiAyMDA5LTA5LTA3ICBab2x0YW4g
SG9ydmF0aCAgPHpvbHRhbkB3ZWJraXQub3JnPgogCiAgICAgICAgIFJldmlld2VkIGJ5IERhcmlu
IEFkbGVyLgpkaWZmIC0tZ2l0IGEvSmF2YVNjcmlwdENvcmUvaml0L0V4ZWN1dGFibGVBbGxvY2F0
b3IuaCBiL0phdmFTY3JpcHRDb3JlL2ppdC9FeGVjdXRhYmxlQWxsb2NhdG9yLmgKaW5kZXggNGVk
NDdlMy4uYTkyYTNjMSAxMDA2NDQKLS0tIGEvSmF2YVNjcmlwdENvcmUvaml0L0V4ZWN1dGFibGVB
bGxvY2F0b3IuaAorKysgYi9KYXZhU2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJsZUFsbG9jYXRvci5o
CkBAIC0yNiw2ICsyNiwxMiBAQAogI2lmbmRlZiBFeGVjdXRhYmxlQWxsb2NhdG9yX2gKICNkZWZp
bmUgRXhlY3V0YWJsZUFsbG9jYXRvcl9oCiAKKyNpZiBQTEFURk9STShBUk0pICYmIENPTVBJTEVS
KEdDQykgJiYgKEdDQ19WRVJTSU9OID49IDMwNDA2KQorZXh0ZXJuICJDIiB7ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgCisgICAgdm9pZCBfX2NsZWFyX2NhY2hlKGNoYXIgKmJlZywgY2hhciAqZW5kKTsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKK30KKyNlbmRpZgorCiAjaW5jbHVkZSA8
bGltaXRzPgogI2luY2x1ZGUgPHd0Zi9Bc3NlcnRpb25zLmg+CiAjaW5jbHVkZSA8d3RmL1Bhc3NS
ZWZQdHIuaD4K
</data>
<flag name="review"
          id="20249"
          type_id="1"
          status="-"
          setter="eric"
    />
          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>39430</attachid>
            <date>2009-09-11 07:26:12 -0700</date>
            <delta_ts>2009-09-11 10:51:01 -0700</delta_ts>
            <desc>Be more specific with guards.</desc>
            <filename>patch_28886.txt</filename>
            <type>text/plain</type>
            <size>2055</size>
            <attacher name="Laszlo Gombos">laszlo.gombos</attacher>
            
              <data encoding="base64">SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDQ4MzAwKQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTggQEAKKzIwMDktMDktMTEgIExhc3psbyBH
b21ib3MgIDxsYXN6bG8uMS5nb21ib3NAbm9raWEuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5
IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEJ1aWxkIGVycm9yIHVzaW5nIEpJVCB3aXRoIGdj
YyA0LjEuMiBhbmQgQVJNIHY1CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df
YnVnLmNnaT9pZD0yODg4NgorCisgICAgICAgIEd1YXJkIEdDQyBzcGVjaWZpYyBjb2RlIHdpdGgg
Q09NUElMRVIoR0NDKS4KKyAgICAgICAgR3VhcmQgTElOVVggc3BlY2lmaWMgY29kZSB3aXRoIFBM
QVRGT1JNKExJTlVYKS4KKyAgICAgICAgQWRkICNlcnJvciBtc2cgZm9yIG5vbi1zdXBwb3J0ZWQg
Y29uZmlndXJhdGlvbi4KKyAgICAgICAgVGVzdCBmb3IgQ0xFQVJfSU5TTl9DQUNIRSBpbnN0ZWFk
IG9mIGEgc3BlY2lmaWMgR0NDIHZlcnNpb24uCisKKyAgICAgICAgKiBqaXQvRXhlY3V0YWJsZUFs
bG9jYXRvci5oOgorICAgICAgICAoSlNDOjpFeGVjdXRhYmxlQWxsb2NhdG9yOjpjYWNoZUZsdXNo
KToKKwogMjAwOS0wOS0xMSAgSm9jZWx5biBUdXJjb3R0ZSAgPGpvY2VseW4udHVyY290dGVAbm9r
aWEuY29tPgogCiAgICAgICAgIFJldmlld2VkIGJ5IFNpbW9uIEhhdXNtYW5uLgpJbmRleDogSmF2
YVNjcmlwdENvcmUvaml0L0V4ZWN1dGFibGVBbGxvY2F0b3IuaAo9PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZh
U2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJsZUFsbG9jYXRvci5oCShyZXZpc2lvbiA0ODI5MikKKysr
IEphdmFTY3JpcHRDb3JlL2ppdC9FeGVjdXRhYmxlQWxsb2NhdG9yLmgJKHdvcmtpbmcgY29weSkK
QEAgLTE5MSwxMiArMTkxLDEyIEBAIHB1YmxpYzoKICAgICB7CiAgICAgICAgIFVzZXI6OklNQl9S
YW5nZShjb2RlLCBzdGF0aWNfY2FzdDxjaGFyKj4oY29kZSkgKyBzaXplKTsKICAgICB9Ci0jZWxp
ZiBQTEFURk9STShBUk0pCisjZWxpZiBQTEFURk9STShBUk0pICYmIENPTVBJTEVSKEdDQykKICAg
ICBzdGF0aWMgdm9pZCBjYWNoZUZsdXNoKHZvaWQqIGNvZGUsIHNpemVfdCBzaXplKQogICAgIHsK
LSAgICAjaWYgQ09NUElMRVIoR0NDKSAmJiAoR0NDX1ZFUlNJT04gPj0gMzA0MDYpCisgICAgI2lm
ZGVmIENMRUFSX0lOU05fQ0FDSEUKICAgICAgICAgX19jbGVhcl9jYWNoZShyZWludGVycHJldF9j
YXN0PGNoYXIqPihjb2RlKSwgcmVpbnRlcnByZXRfY2FzdDxjaGFyKj4oY29kZSkgKyBzaXplKTsK
LSAgICAjZWxzZQorICAgICNlbGlmIFBMQVRGT1JNKExJTlVYKQogICAgICAgICBjb25zdCBpbnQg
c3lzY2FsbCA9IDB4ZjAwMDI7CiAgICAgICAgIF9fYXNtIF9fdm9sYXRpbGUgKAogICAgICAgICAg
ICAgICAgIm1vdiAgICAgcjAsICUwXG4iCkBAIC0yMDcsOCArMjA3LDEyIEBAIHB1YmxpYzoKICAg
ICAgICAgICAgOgogICAgICAgICAgICA6ICAgInIiIChjb2RlKSwgInIiIChyZWludGVycHJldF9j
YXN0PGNoYXIqPihjb2RlKSArIHNpemUpLCAiciIgKHN5c2NhbGwpCiAgICAgICAgICAgIDogICAi
cjAiLCAicjEiLCAicjciKTsKLSAgICAjZW5kaWYgLy8gQ09NUElMRVIoR0NDKSAmJiAoR0NDX1ZF
UlNJT04gPj0gMzA0MDYpCisgICAgI2VsaWYKKyAgICAjZXJyb3IgTmVlZCBhIHdheSB0byBjbGVh
ciB0aGUgaW5zdHJ1Y3Rpb24gY2FjaGUgb24gdGhpcyBwbGF0Zm9ybQorICAgICNlbmRpZiAvLyBD
TEVBUl9JTlNOX0NBQ0hFCiAgICAgfQorI2VsaWYKKyNlcnJvciBOZWVkIGEgd2F5IHRvIGNsZWFy
IHRoZSBpbnN0cnVjdGlvbiBjYWNoZSBvbiB0aGlzIHBsYXRmb3JtCiAjZW5kaWYKIAogcHJpdmF0
ZToK
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>39450</attachid>
            <date>2009-09-11 10:51:01 -0700</date>
            <delta_ts>2009-09-22 12:49:54 -0700</delta_ts>
            <desc>incorporate Gabor&apos;s comments.</desc>
            <filename>patch_28886.txt</filename>
            <type>text/plain</type>
            <size>1994</size>
            <attacher name="Laszlo Gombos">laszlo.gombos</attacher>
            
              <data encoding="base64">SW5kZXg6IEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBKYXZhU2NyaXB0
Q29yZS9DaGFuZ2VMb2cJKHJldmlzaW9uIDQ4MzAwKQorKysgSmF2YVNjcmlwdENvcmUvQ2hhbmdl
TG9nCSh3b3JraW5nIGNvcHkpCkBAIC0xLDMgKzEsMTcgQEAKKzIwMDktMDktMTEgIExhc3psbyBH
b21ib3MgIDxsYXN6bG8uMS5nb21ib3NAbm9raWEuY29tPgorCisgICAgICAgIFJldmlld2VkIGJ5
IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEJ1aWxkIGVycm9yIHVzaW5nIEpJVCB3aXRoIGdj
YyA0LjEuMiBhbmQgQVJNIHY1CisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3df
YnVnLmNnaT9pZD0yODg4NgorCisgICAgICAgIEd1YXJkIEdDQyBzcGVjaWZpYyBjb2RlIHdpdGgg
Q09NUElMRVIoR0NDKS4KKyAgICAgICAgR3VhcmQgTElOVVggc3BlY2lmaWMgY29kZSB3aXRoIFBM
QVRGT1JNKExJTlVYKS4KKyAgICAgICAgQWRkICNlcnJvciBtc2cgZm9yIG5vbi1zdXBwb3J0ZWQg
Y29uZmlndXJhdGlvbi4KKworICAgICAgICAqIGppdC9FeGVjdXRhYmxlQWxsb2NhdG9yLmg6Cisg
ICAgICAgIChKU0M6OkV4ZWN1dGFibGVBbGxvY2F0b3I6OmNhY2hlRmx1c2gpOgorCiAyMDA5LTA5
LTExICBKb2NlbHluIFR1cmNvdHRlICA8am9jZWx5bi50dXJjb3R0ZUBub2tpYS5jb20+CiAKICAg
ICAgICAgUmV2aWV3ZWQgYnkgU2ltb24gSGF1c21hbm4uCkluZGV4OiBKYXZhU2NyaXB0Q29yZS9q
aXQvRXhlY3V0YWJsZUFsbG9jYXRvci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIEphdmFTY3JpcHRDb3JlL2pp
dC9FeGVjdXRhYmxlQWxsb2NhdG9yLmgJKHJldmlzaW9uIDQ4MjkyKQorKysgSmF2YVNjcmlwdENv
cmUvaml0L0V4ZWN1dGFibGVBbGxvY2F0b3IuaAkod29ya2luZyBjb3B5KQpAQCAtMTkxLDEyICsx
OTEsMTIgQEAgcHVibGljOgogICAgIHsKICAgICAgICAgVXNlcjo6SU1CX1JhbmdlKGNvZGUsIHN0
YXRpY19jYXN0PGNoYXIqPihjb2RlKSArIHNpemUpOwogICAgIH0KLSNlbGlmIFBMQVRGT1JNKEFS
TSkKKyNlbGlmIFBMQVRGT1JNKEFSTSkgJiYgQ09NUElMRVIoR0NDKQogICAgIHN0YXRpYyB2b2lk
IGNhY2hlRmx1c2godm9pZCogY29kZSwgc2l6ZV90IHNpemUpCiAgICAgewotICAgICNpZiBDT01Q
SUxFUihHQ0MpICYmIChHQ0NfVkVSU0lPTiA+PSAzMDQwNikKKyAgICAjaWYgKEdDQ19WRVJTSU9O
ID49IDMwNDA2KQogICAgICAgICBfX2NsZWFyX2NhY2hlKHJlaW50ZXJwcmV0X2Nhc3Q8Y2hhcio+
KGNvZGUpLCByZWludGVycHJldF9jYXN0PGNoYXIqPihjb2RlKSArIHNpemUpOwotICAgICNlbHNl
CisgICAgI2VsaWYgUExBVEZPUk0oTElOVVgpCiAgICAgICAgIGNvbnN0IGludCBzeXNjYWxsID0g
MHhmMDAwMjsKICAgICAgICAgX19hc20gX192b2xhdGlsZSAoCiAgICAgICAgICAgICAgICAibW92
ICAgICByMCwgJTBcbiIKQEAgLTIwNyw4ICsyMDcsMTIgQEAgcHVibGljOgogICAgICAgICAgICA6
CiAgICAgICAgICAgIDogICAiciIgKGNvZGUpLCAiciIgKHJlaW50ZXJwcmV0X2Nhc3Q8Y2hhcio+
KGNvZGUpICsgc2l6ZSksICJyIiAoc3lzY2FsbCkKICAgICAgICAgICAgOiAgICJyMCIsICJyMSIs
ICJyNyIpOwotICAgICNlbmRpZiAvLyBDT01QSUxFUihHQ0MpICYmIChHQ0NfVkVSU0lPTiA+PSAz
MDQwNikKKyAgICAjZWxzZQorICAgICNlcnJvciBOZWVkIGEgd2F5IHRvIGNsZWFyIHRoZSBpbnN0
cnVjdGlvbiBjYWNoZSBvbiB0aGlzIHBsYXRmb3JtCisgICAgI2VuZGlmIC8vIChHQ0NfVkVSU0lP
TiA+PSAzMDQwNikKICAgICB9CisjZWxzZQorI2Vycm9yIE5lZWQgYSB3YXkgdG8gY2xlYXIgdGhl
IGluc3RydWN0aW9uIGNhY2hlIG9uIHRoaXMgcGxhdGZvcm0KICNlbmRpZgogCiBwcml2YXRlOgo=
</data>

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>39925</attachid>
            <date>2009-09-22 08:01:06 -0700</date>
            <delta_ts>2009-09-22 09:23:51 -0700</delta_ts>
            <desc>Avoid __clear_cache built-in function if NO_CLEAR_CACHE define is set</desc>
            <filename>0001-Avoid-__clear_cache-built-in-function-if-NO_CLEAR_CA.patch</filename>
            <type>text/plain</type>
            <size>2253</size>
            <attacher name="Gabor Loki">loki</attacher>
            
              <data encoding="base64">RnJvbSBlNjc1M2E4ZTc3OWQ2Y2RiYWJhYzIxN2Q0ZTQ4MWE2NDYwODdjOGRlIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBHYWJvciBMb2tpIDxsb2tpQGluZi51LXN6ZWdlZC5odT4KRGF0
ZTogVHVlLCAyMiBTZXAgMjAwOSAxNjo0OTowNyArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIEF2b2lk
IF9fY2xlYXJfY2FjaGUgYnVpbHQtaW4gZnVuY3Rpb24gaWYgTk9fQ0xFQVJfQ0FDSEUgZGVmaW5l
IGlzIHNldAoKU2lnbmVkLW9mZi1ieTogR2Fib3IgTG9raSA8bG9raUBpbmYudS1zemVnZWQuaHU+
Ci0tLQogSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nICAgICAgICAgICAgICAgICB8ICAgMTQgKysr
KysrKysrKysrKysKIEphdmFTY3JpcHRDb3JlL2ppdC9FeGVjdXRhYmxlQWxsb2NhdG9yLmggfCAg
ICA1ICsrKy0tCiAyIGZpbGVzIGNoYW5nZWQsIDE3IGluc2VydGlvbnMoKyksIDIgZGVsZXRpb25z
KC0pCgpkaWZmIC0tZ2l0IGEvSmF2YVNjcmlwdENvcmUvQ2hhbmdlTG9nIGIvSmF2YVNjcmlwdENv
cmUvQ2hhbmdlTG9nCmluZGV4IDA2MzhlMWQuLjM2NDUwMTMgMTAwNjQ0Ci0tLSBhL0phdmFTY3Jp
cHRDb3JlL0NoYW5nZUxvZworKysgYi9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKQEAgLTEsMyAr
MSwxNyBAQAorMjAwOS0wOS0yMiAgR2Fib3IgTG9raSAgPGxva2lAaW5mLnUtc3plZ2VkLmh1Pgor
CisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIEF2b2lkIF9f
Y2xlYXJfY2FjaGUgYnVpbHQtaW4gZnVuY3Rpb24gaWYgTk9fQ0xFQVJfQ0FDSEUgZGVmaW5lIGlz
IHNldAorICAgICAgICBodHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Mjg4
ODYKKworICAgICAgICBUaGVyZSBhcmUgc29tZSBHQ0MgcGFja2FnZXMgKGZvciBleGFtcGxlIEdD
Qy0yMDA2cTMgZnJvbSBDb2RlU291cmNlcnkpCisgICAgICAgIHdoaWNoIGNvbnRhaW4gX19jbGVh
cl9jYWNoZSBidWlsdC1pbiBmdW5jdGlvbiBvbmx5IGZvciBDIHdoaWxlIHRoZSBDKysKKyAgICAg
ICAgdmVyc2lvbiBvZiBfX2NsZWFyX2NhY2hlIGlzIG1pc3Npbmcgb24gQVJNIGFyY2hpdGVjdHVy
ZXMuCisKKyAgICAgICAgKiBqaXQvRXhlY3V0YWJsZUFsbG9jYXRvci5oOgorICAgICAgICAoSlND
OjpFeGVjdXRhYmxlQWxsb2NhdG9yOjpjYWNoZUZsdXNoKToKKwogMjAwOS0wOS0yMiAgVGhpYWdv
IE1hY2llaXJhICA8dGhpYWdvLm1hY2llaXJhQG5va2lhLmNvbT4KIAogICAgICAgICBSZXZpZXdl
ZCBieSBTaW1vbiBIYXVzbWFubi4KZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL2ppdC9FeGVj
dXRhYmxlQWxsb2NhdG9yLmggYi9KYXZhU2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJsZUFsbG9jYXRv
ci5oCmluZGV4IDBiMjViYzAuLjBiMDUxOTIgMTAwNjQ0Ci0tLSBhL0phdmFTY3JpcHRDb3JlL2pp
dC9FeGVjdXRhYmxlQWxsb2NhdG9yLmgKKysrIGIvSmF2YVNjcmlwdENvcmUvaml0L0V4ZWN1dGFi
bGVBbGxvY2F0b3IuaApAQCAtMTkxLDcgKzE5MSw3IEBAIHB1YmxpYzoKICAgICB7CiAgICAgICAg
IFVzZXI6OklNQl9SYW5nZShjb2RlLCBzdGF0aWNfY2FzdDxjaGFyKj4oY29kZSkgKyBzaXplKTsK
ICAgICB9Ci0jZWxpZiBQTEFURk9STShBUk0pICYmIENPTVBJTEVSKEdDQykgJiYgKEdDQ19WRVJT
SU9OID49IDMwNDA2KQorI2VsaWYgUExBVEZPUk0oQVJNKSAmJiBDT01QSUxFUihHQ0MpICYmIChH
Q0NfVkVSU0lPTiA+PSAzMDQwNikgJiYgIWRlZmluZWQoTk9fQ0xFQVJfQ0FDSEUpCiAgICAgc3Rh
dGljIHZvaWQgY2FjaGVGbHVzaCh2b2lkKiBjb2RlLCBzaXplX3Qgc2l6ZSkKICAgICB7CiAgICAg
ICAgIF9fY2xlYXJfY2FjaGUocmVpbnRlcnByZXRfY2FzdDxjaGFyKj4oY29kZSksIHJlaW50ZXJw
cmV0X2Nhc3Q8Y2hhcio+KGNvZGUpICsgc2l6ZSk7CkBAIC0yMDMsNyArMjAzLDggQEAgcHVibGlj
OgogICAgICAgICAgICAgInB1c2ggICAge3I3fVxuIgogICAgICAgICAgICAgIm1vdiAgICAgcjAs
ICUwXG4iCiAgICAgICAgICAgICAibW92ICAgICByMSwgJTFcbiIKLSAgICAgICAgICAgICJtb3Yg
ICAgIHI3LCAweGYwMDAyXG4iCisgICAgICAgICAgICAibW92ICAgICByNywgIzB4ZjAwMDBcbiIK
KyAgICAgICAgICAgICJhZGQgICAgIHI3LCByNywgIzB4MlxuIgogICAgICAgICAgICAgIm1vdiAg
ICAgcjIsICMweDBcbiIKICAgICAgICAgICAgICJzdmMgICAgIDB4MFxuIgogICAgICAgICAgICAg
InBvcCAgICAge3I3fVxuIgotLSAKMS42LjAuNAoK
</data>

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>39927</attachid>
            <date>2009-09-22 09:23:51 -0700</date>
            <delta_ts>2009-09-23 15:18:00 -0700</delta_ts>
            <desc>Avoid __clear_cache built-in function if DISABLE_BUILTIN_CLEAR_CACHE define is set</desc>
            <filename>0001-Avoid-__clear_cache-built-in-function-if-DISABLE_BUI.patch</filename>
            <type>text/plain</type>
            <size>2399</size>
            <attacher name="Gabor Loki">loki</attacher>
            
              <data encoding="base64">RnJvbSBiMTJkODlmNzI0Nzc5NWFmNzQ4NmFmNDU5YWQwOGFlYTgwOGIxNDk5IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBHYWJvciBMb2tpIDxsb2tpQGluZi51LXN6ZWdlZC5odT4KRGF0
ZTogVHVlLCAyMiBTZXAgMjAwOSAxODoyMDoyMSArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIEF2b2lk
IF9fY2xlYXJfY2FjaGUgYnVpbHQtaW4gZnVuY3Rpb24gaWYgRElTQUJMRV9CVUlMVElOX0NMRUFS
X0NBQ0hFIGRlZmluZSBpcyBzZXQKClNpZ25lZC1vZmYtYnk6IEdhYm9yIExva2kgPGxva2lAaW5m
LnUtc3plZ2VkLmh1PgotLS0KIEphdmFTY3JpcHRDb3JlL0NoYW5nZUxvZyAgICAgICAgICAgICAg
ICAgfCAgIDE3ICsrKysrKysrKysrKysrKysrCiBKYXZhU2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJs
ZUFsbG9jYXRvci5oIHwgICAgNSArKystLQogMiBmaWxlcyBjaGFuZ2VkLCAyMCBpbnNlcnRpb25z
KCspLCAyIGRlbGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxv
ZyBiL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwppbmRleCAwNjM4ZTFkLi5iMmExMjEzIDEwMDY0
NAotLS0gYS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cKKysrIGIvSmF2YVNjcmlwdENvcmUvQ2hh
bmdlTG9nCkBAIC0xLDMgKzEsMjAgQEAKKzIwMDktMDktMjIgIEdhYm9yIExva2kgIDxsb2tpQGlu
Zi51LXN6ZWdlZC5odT4KKworICAgICAgICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKwor
ICAgICAgICBBdm9pZCBfX2NsZWFyX2NhY2hlIGJ1aWx0LWluIGZ1bmN0aW9uIGlmIERJU0FCTEVf
QlVJTFRJTl9DTEVBUl9DQUNIRSBkZWZpbmUgaXMgc2V0CisgICAgICAgIGh0dHBzOi8vYnVncy53
ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yODg4NgorCisgICAgICAgIFRoZXJlIGFyZSBzb21l
IEdDQyBwYWNrYWdlcyAoZm9yIGV4YW1wbGUgR0NDLTIwMDZxMyBmcm9tIENvZGVTb3VyY2VyeSkK
KyAgICAgICAgd2hpY2ggY29udGFpbiBfX2NsZWFyX2NhY2hlIGJ1aWx0LWluIGZ1bmN0aW9uIG9u
bHkgZm9yIEMgd2hpbGUgdGhlIEMrKworICAgICAgICB2ZXJzaW9uIG9mIF9fY2xlYXJfY2FjaGUg
aXMgbWlzc2luZyBvbiBBUk0gYXJjaGl0ZWN0dXJlcy4KKworICAgICAgICBGaXhlZCBhIHNtYWxs
IGJ1ZyBpbiB0aGUgaW5saW5lIGFzc2VtYmx5IG9mIGNhY2hlRmx1c2ggZnVuY3Rpb24gb24KKyAg
ICAgICAgQVJNX1RSQURJVElPTkFMLgorCisgICAgICAgICogaml0L0V4ZWN1dGFibGVBbGxvY2F0
b3IuaDoKKyAgICAgICAgKEpTQzo6RXhlY3V0YWJsZUFsbG9jYXRvcjo6Y2FjaGVGbHVzaCk6CisK
IDIwMDktMDktMjIgIFRoaWFnbyBNYWNpZWlyYSAgPHRoaWFnby5tYWNpZWlyYUBub2tpYS5jb20+
CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgU2ltb24gSGF1c21hbm4uCmRpZmYgLS1naXQgYS9KYXZh
U2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJsZUFsbG9jYXRvci5oIGIvSmF2YVNjcmlwdENvcmUvaml0
L0V4ZWN1dGFibGVBbGxvY2F0b3IuaAppbmRleCAwYjI1YmMwLi4xMmUyYTMyIDEwMDY0NAotLS0g
YS9KYXZhU2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJsZUFsbG9jYXRvci5oCisrKyBiL0phdmFTY3Jp
cHRDb3JlL2ppdC9FeGVjdXRhYmxlQWxsb2NhdG9yLmgKQEAgLTE5MSw3ICsxOTEsNyBAQCBwdWJs
aWM6CiAgICAgewogICAgICAgICBVc2VyOjpJTUJfUmFuZ2UoY29kZSwgc3RhdGljX2Nhc3Q8Y2hh
cio+KGNvZGUpICsgc2l6ZSk7CiAgICAgfQotI2VsaWYgUExBVEZPUk0oQVJNKSAmJiBDT01QSUxF
UihHQ0MpICYmIChHQ0NfVkVSU0lPTiA+PSAzMDQwNikKKyNlbGlmIFBMQVRGT1JNKEFSTSkgJiYg
Q09NUElMRVIoR0NDKSAmJiAoR0NDX1ZFUlNJT04gPj0gMzA0MDYpICYmICFkZWZpbmVkKERJU0FC
TEVfQlVJTFRJTl9DTEVBUl9DQUNIRSkKICAgICBzdGF0aWMgdm9pZCBjYWNoZUZsdXNoKHZvaWQq
IGNvZGUsIHNpemVfdCBzaXplKQogICAgIHsKICAgICAgICAgX19jbGVhcl9jYWNoZShyZWludGVy
cHJldF9jYXN0PGNoYXIqPihjb2RlKSwgcmVpbnRlcnByZXRfY2FzdDxjaGFyKj4oY29kZSkgKyBz
aXplKTsKQEAgLTIwMyw3ICsyMDMsOCBAQCBwdWJsaWM6CiAgICAgICAgICAgICAicHVzaCAgICB7
cjd9XG4iCiAgICAgICAgICAgICAibW92ICAgICByMCwgJTBcbiIKICAgICAgICAgICAgICJtb3Yg
ICAgIHIxLCAlMVxuIgotICAgICAgICAgICAgIm1vdiAgICAgcjcsIDB4ZjAwMDJcbiIKKyAgICAg
ICAgICAgICJtb3YgICAgIHI3LCAjMHhmMDAwMFxuIgorICAgICAgICAgICAgImFkZCAgICAgcjcs
IHI3LCAjMHgyXG4iCiAgICAgICAgICAgICAibW92ICAgICByMiwgIzB4MFxuIgogICAgICAgICAg
ICAgInN2YyAgICAgMHgwXG4iCiAgICAgICAgICAgICAicG9wICAgICB7cjd9XG4iCi0tIAoxLjYu
MC40Cgo=
</data>
<flag name="review"
          id="21071"
          type_id="1"
          status="+"
          setter="barraclough"
    />
          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>40240</attachid>
            <date>2009-09-28 09:19:35 -0700</date>
            <delta_ts>2009-09-28 11:56:26 -0700</delta_ts>
            <desc>Remove __clear_cache which is an internal function of GCC</desc>
            <filename>0001-Remove-__clear_cache-which-is-an-internal-function-o.patch</filename>
            <type>text/plain</type>
            <size>1863</size>
            <attacher name="Gabor Loki">loki</attacher>
            
              <data encoding="base64">RnJvbSBkNjJkZjMwZGZiOWRhYWIzNDYzMjk4NTA3M2E0ZmJjNWJiNzI1NTk1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBHYWJvciBMb2tpIDxsb2tpQGluZi51LXN6ZWdlZC5odT4KRGF0
ZTogTW9uLCAyOCBTZXAgMjAwOSAxODoxMDozNSArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIFJlbW92
ZSBfX2NsZWFyX2NhY2hlIHdoaWNoIGlzIGFuIGludGVybmFsIGZ1bmN0aW9uIG9mIEdDQwoKU2ln
bmVkLW9mZi1ieTogR2Fib3IgTG9raSA8bG9raUBpbmYudS1zemVnZWQuaHU+Ci0tLQogSmF2YVNj
cmlwdENvcmUvQ2hhbmdlTG9nICAgICAgICAgICAgICAgICB8ICAgMTMgKysrKysrKysrKysrKwog
SmF2YVNjcmlwdENvcmUvaml0L0V4ZWN1dGFibGVBbGxvY2F0b3IuaCB8ICAgIDUgLS0tLS0KIDIg
ZmlsZXMgY2hhbmdlZCwgMTMgaW5zZXJ0aW9ucygrKSwgNSBkZWxldGlvbnMoLSkKCmRpZmYgLS1n
aXQgYS9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cgYi9KYXZhU2NyaXB0Q29yZS9DaGFuZ2VMb2cK
aW5kZXggYmM1MmQwMi4uZTY1NzZkMiAxMDA2NDQKLS0tIGEvSmF2YVNjcmlwdENvcmUvQ2hhbmdl
TG9nCisrKyBiL0phdmFTY3JpcHRDb3JlL0NoYW5nZUxvZwpAQCAtMSwzICsxLDE2IEBACisyMDA5
LTA5LTI4ICBHYWJvciBMb2tpICA8bG9raUBpbmYudS1zemVnZWQuaHU+CisKKyAgICAgICAgUmV2
aWV3ZWQgYnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgUmVtb3ZlIF9fY2xlYXJfY2FjaGUg
d2hpY2ggaXMgYW4gaW50ZXJuYWwgZnVuY3Rpb24gb2YgR0NDCisgICAgICAgIGh0dHBzOi8vYnVn
cy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD0yODg4NgorCisgICAgICAgIEFsdGhvdWdoIF9f
Y2xlYXJfY2FjaGUgaXMgZXhwb3J0ZWQgZnJvbSBHQ0MsIHRoaXMgaXMgYW4gaW50ZXJuYWwKKyAg
ICAgICAgZnVuY3Rpb24uIEdDQyBtYWtlcyBubyBwcm9taXNlcyBhYm91dCBpdC4KKworICAgICAg
ICAqIGppdC9FeGVjdXRhYmxlQWxsb2NhdG9yLmg6CisgICAgICAgIChKU0M6OkV4ZWN1dGFibGVB
bGxvY2F0b3I6OmNhY2hlRmx1c2gpOgorCiAyMDA5LTA5LTI2ICBZb25nanVuIFpoYW5nICA8eW9u
Z2p1bi56aGFuZ0Bub2tpYS5jb20+CiAKICAgICAgICAgUmV2aWV3ZWQgYnkgU2ltb24gSGF1c21h
bm4uCmRpZmYgLS1naXQgYS9KYXZhU2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJsZUFsbG9jYXRvci5o
IGIvSmF2YVNjcmlwdENvcmUvaml0L0V4ZWN1dGFibGVBbGxvY2F0b3IuaAppbmRleCAxMmUyYTMy
Li4zMjc0ZmNjIDEwMDY0NAotLS0gYS9KYXZhU2NyaXB0Q29yZS9qaXQvRXhlY3V0YWJsZUFsbG9j
YXRvci5oCisrKyBiL0phdmFTY3JpcHRDb3JlL2ppdC9FeGVjdXRhYmxlQWxsb2NhdG9yLmgKQEAg
LTE5MSwxMSArMTkxLDYgQEAgcHVibGljOgogICAgIHsKICAgICAgICAgVXNlcjo6SU1CX1Jhbmdl
KGNvZGUsIHN0YXRpY19jYXN0PGNoYXIqPihjb2RlKSArIHNpemUpOwogICAgIH0KLSNlbGlmIFBM
QVRGT1JNKEFSTSkgJiYgQ09NUElMRVIoR0NDKSAmJiAoR0NDX1ZFUlNJT04gPj0gMzA0MDYpICYm
ICFkZWZpbmVkKERJU0FCTEVfQlVJTFRJTl9DTEVBUl9DQUNIRSkKLSAgICBzdGF0aWMgdm9pZCBj
YWNoZUZsdXNoKHZvaWQqIGNvZGUsIHNpemVfdCBzaXplKQotICAgIHsKLSAgICAgICAgX19jbGVh
cl9jYWNoZShyZWludGVycHJldF9jYXN0PGNoYXIqPihjb2RlKSwgcmVpbnRlcnByZXRfY2FzdDxj
aGFyKj4oY29kZSkgKyBzaXplKTsKLSAgICB9CiAjZWxpZiBQTEFURk9STShBUk1fVFJBRElUSU9O
QUwpICYmIFBMQVRGT1JNKExJTlVYKQogICAgIHN0YXRpYyB2b2lkIGNhY2hlRmx1c2godm9pZCog
Y29kZSwgc2l6ZV90IHNpemUpCiAgICAgewotLSAKMS42LjAuNAoK
</data>
<flag name="review"
          id="21427"
          type_id="1"
          status="+"
          setter="hausmann"
    />
          </attachment>
      

    </bug>

</bugzilla>