On Wed, Jul 29, 2009 at 2:16 PM, Antoine Labour <[email protected]> wrote:
> On Wed, Jul 29, 2009 at 10:46 AM, Evan Martin<[email protected]> wrote: > > > > On Tue, Jul 28, 2009 at 11:18 PM, Brian Ryner<[email protected]> wrote: > >>>> > The -fvisibility=hidden flag is maybe supposed to do this (see > >>>> > discussion on http://gcc.gnu.org/wiki/Visibility ), but I tried > >>>> > building both with and without it and found that: > >>>> > - in debug builds, objdump -T shows all of our symbols, regardless > of > >>>> > the flags I pass to gcc or strip > >> > >> Can you paste a snippet of the objdump -T output you see for a debug > binary? > >> I'd also be interested in the answer to Mark's question -- is the > binary > >> being linked with -E? > > > > As I said before, I don't really know what I'm doing -- I wrote my > > mail to mostly summarize the result of "tried building it both with > > and without this flag and saw no difference". > > > > There is no -E. Maybe I don't understand what objdump -CT is telling > > me... aha! > > > > It turns out that the vast majority of the symbols I mentioned are C++ > > templates. > > % objdump -CT out/Debug/chrome | wc -l > > 43740 > > % objdump -CT out/Debug/chrome | egrep -v 'std|cxx' | wc -l > > 2591 > > > > Here are a few examples of the output pre-filtering: > > > > 083fa306 w DF .text 00000011 Base > > std::reverse_iterator<std::_List_iterator<std::pair<RenderWidgetHost*, > > BackingStore*> > >::base() const > > 090104dc w DF .text 00000022 Base void > > std::swap<WebCore::CSSFontFace*>(WebCore::CSSFontFace*&, > > WebCore::CSSFontFace*&) > > 0 > > > > Of the remaining symbols after that egrep -v, it's mostly stuff I'd > > expect, though I still see v8 templates marked weak: > > > > 091b7d12 w DF .text 00000013 Base > v8::Local<v8::Integer>::Local() > > 00000000 DF *UND* 00000000 Base gtk_tree_model_get_value > > 0884d056 w DF .text 0000001a Base > > v8::Local<v8::String>::Local<v8::String>(v8::String*) > > 00000000 DF *UND* 00000000 Base gtk_grab_add > > 00000000 DF *UND* 00000000 Base gtk_hbutton_box_new > > 00000000 DF *UND* 00000000 NSS_3.4 SSL_GetChannelInfo > > 00000000 DF *UND* 00000000 GLIBC_2.4 __stack_chk_fail > > 086a6698 g DF .text 0000010a Base uprv_ebcdicFromAscii_3_8 > > 0866af2e g DF .text 000000d1 Base uprv_fmin_3_8 > > 00000000 DF *UND* 00000000 Base gtk_widget_get_visual > > 091ab20c g DF .text 0000005d Base > > v8::ObjectTemplate::InternalFieldCount() > > 0885e164 w DF .text 00000013 Base > > v8::Persistent<v8::String>::Persistent() > > 00000000 DF *UND* 00000000 Base > > gtk_file_chooser_set_preview_widget_active > > 00000000 DF *UND* 00000000 Base gdk_display_get_pointer > > 0880e3a2 g DF .text 000002f4 Base > ucol_tok_getNextArgument_3_8 > > 086e6d5c g DF .text 000001a1 Base upname_swap_3_8 > > > > > > Flags we use follow: > > > > # Enable -Werror by default, but put it in a variable so it can > > # be disabled in ~/.gyp/include.gypi on the valgrind builders. > > 'variables': { > > 'werror%': '-Werror', > > }, > > 'cflags': [ > > '<(werror)', # See note above about the werror variable. > > '-pthread', > > '-fno-exceptions', > > '-Wall', > > ], > > 'cflags_cc': [ > > '-fno-threadsafe-statics', > > ], > > 'ldflags': [ > > '-pthread', > > ], > > I have been going through the same pains with o3d, trying to get rid > of all exports, see http://codereview.chromium.org/160317 though I > haven't removed all of them. > It turns out that both ICU (all your u.*3_8) and v8 (that we both use > in o3d) force __attribute__((visibility("default"))) on some API > symbols (ie force export regardless of -fvisibility). You can get rid > of most of the ICU ones if you compile with U_STATIC_IMPLEMENTATION > but not U_COMBINED_IMPLEMENTATION, but there are still some left. For > v8, all the "public" API is tagged with "default" visibility. > For the STL template instantiations, I'm seeing those too, and I don't > know how to get rid of them. > > Antoine > Maybe the V8 team would accept a patch to make that tagging conditional on a preprocessor define. -Darin --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
