diff options
author | asharif@chromium.org <asharif@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-04-24 23:56:07 +0000 |
---|---|---|
committer | asharif@chromium.org <asharif@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2012-04-24 23:56:07 +0000 |
commit | fde23027bb02883852c2c626d63ac25c44c7d52b (patch) | |
tree | bf81886d5e4125a35b688a6ea6f2b6b82dc35a8d /third_party | |
parent | 80ec0c328c49a012c21b6b47e1239f5460fa5348 (diff) | |
download | chromium_src-fde23027bb02883852c2c626d63ac25c44c7d52b.zip chromium_src-fde23027bb02883852c2c626d63ac25c44c7d52b.tar.gz chromium_src-fde23027bb02883852c2c626d63ac25c44c7d52b.tar.bz2 |
Added compile-time define to gate "initial-exec" attribute.
The "initial-exec" attribute is added to the ThreadCache::threadlocal_heap_
variable under normal compilation. This causes the linker to emit a
R_X86_64_TPOFF64 relocation in the _pyautolib.so shared object. This relocation
can cause python to error with:
cannot allocate memory in static TLS block
when it calls dlopen() on _pyautolib.so (when the import statement is
interpreted).
This only happens when the TLS section is large enough. Building Chrome with
-fprofile-generate to add some instrumentation-related data to the TLS is enough
to trigger this condition.
This CL encloses the function attribute in #if ! defined(PGO_GENERATE). When
Chrome is built with -fprofile-generate, we will also pass in -DPGO_GENERATE and
-ftls-model=global-dynamic so profile data can be collected without any errors.
BUG=none
TEST=Rebuilt chromeos-chrome in the chroot with -fprofile-generate
-ftls-model=global-dynamic -DPGO_GENERATE && ran pyautoperf autotests.
Review URL: http://codereview.chromium.org/10035012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@133810 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'third_party')
-rw-r--r-- | third_party/tcmalloc/chromium/src/thread_cache.cc | 4 | ||||
-rw-r--r-- | third_party/tcmalloc/chromium/src/thread_cache.h | 11 |
2 files changed, 13 insertions, 2 deletions
diff --git a/third_party/tcmalloc/chromium/src/thread_cache.cc b/third_party/tcmalloc/chromium/src/thread_cache.cc index 765786ff..1ad0f6d 100644 --- a/third_party/tcmalloc/chromium/src/thread_cache.cc +++ b/third_party/tcmalloc/chromium/src/thread_cache.cc @@ -64,7 +64,9 @@ int ThreadCache::thread_heap_count_ = 0; ThreadCache* ThreadCache::next_memory_steal_ = NULL; #ifdef HAVE_TLS __thread ThreadCache* ThreadCache::threadlocal_heap_ -# ifdef HAVE___ATTRIBUTE__ +// See comments in thread_cache.h about this. Bug here: +// http://code.google.com/p/chromium/issues/detail?id=124489 +#if defined(HAVE___ATTRIBUTE__) && !defined(PGO_GENERATE) __attribute__ ((tls_model ("initial-exec"))) # endif ; diff --git a/third_party/tcmalloc/chromium/src/thread_cache.h b/third_party/tcmalloc/chromium/src/thread_cache.h index 5294029..221cacb 100644 --- a/third_party/tcmalloc/chromium/src/thread_cache.h +++ b/third_party/tcmalloc/chromium/src/thread_cache.h @@ -259,7 +259,16 @@ class ThreadCache { // a good tradeoff for us. #ifdef HAVE_TLS static __thread ThreadCache* threadlocal_heap_ -# ifdef HAVE___ATTRIBUTE__ + // This code links against pyautolib.so, which causes dlopen() on that shared + // object to fail when -fprofile-generate is used with it. Ideally + // pyautolib.so should not link against this code. There is a bug filed for + // that: + // http://code.google.com/p/chromium/issues/detail?id=124489 + // For now the workaround is to pass in -DPGO_GENERATE when building Chrome + // for instrumentation (-fprofile-generate). + // For all non-instrumentation builds, this define will not be set and the + // performance benefit of "intial-exec" will be achieved. +#if defined(HAVE___ATTRIBUTE__) && !defined(PGO_GENERATE) __attribute__ ((tls_model ("initial-exec"))) # endif ; |