[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
fwiw, I had posted a "all" hidden discussion patch using GCC pragma visibility for v8 here: http://code.google.com/p/v8/issues/detail?id=411 --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
On Wed, Jul 29, 2009 at 2:16 PM, Antoine Labour wrote: > On Wed, Jul 29, 2009 at 10:46 AM, Evan Martin wrote: >> 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 > For the STL template instantiations, I'm seeing those too, and I don't > know how to get rid of them. >From looking a bit, it seems like there are a lot of GCC bugs around the versions we're running in this area: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32470 Someday I will build with a gcc under two years old. ;) --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
On Wed, Jul 29, 2009 at 2:16 PM, Antoine Labour wrote:
> On Wed, Jul 29, 2009 at 10:46 AM, Evan Martin wrote:
> >
> > On Tue, Jul 28, 2009 at 11:18 PM, Brian Ryner 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 0011 Base
> > std::reverse_iterator > BackingStore*> > >::base() const
> > 090104dc w DF .text 0022 Basevoid
> > std::swap(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 0013 Base
> v8::Local::Local()
> > DF *UND* Basegtk_tree_model_get_value
> > 0884d056 w DF .text 001a Base
> > v8::Local::Local(v8::String*)
> > DF *UND* Basegtk_grab_add
> > DF *UND* Basegtk_hbutton_box_new
> > DF *UND* NSS_3.4 SSL_GetChannelInfo
> > DF *UND* GLIBC_2.4 __stack_chk_fail
> > 086a6698 gDF .text 010a Baseuprv_ebcdicFromAscii_3_8
> > 0866af2e gDF .text 00d1 Baseuprv_fmin_3_8
> > DF *UND* Basegtk_widget_get_visual
> > 091ab20c gDF .text 005d Base
> > v8::ObjectTemplate::InternalFieldCount()
> > 0885e164 w DF .text 0013 Base
> > v8::Persistent::Persistent()
> > DF *UND* Base
> > gtk_file_chooser_set_preview_widget_active
> > DF *UND* Basegdk_display_get_pointer
> > 0880e3a2 gDF .text 02f4 Base
> ucol_tok_getNextArgument_3_8
> > 086e6d5c gDF .text 01a1 Baseupname_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: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
On Wed, Jul 29, 2009 at 10:46 AM, Evan Martin wrote:
>
> On Tue, Jul 28, 2009 at 11:18 PM, Brian Ryner 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 0011 Base
> std::reverse_iterator BackingStore*> > >::base() const
> 090104dc w DF .text 0022 Base void
> std::swap(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 0013 Base v8::Local::Local()
> DF *UND* Base gtk_tree_model_get_value
> 0884d056 w DF .text 001a Base
> v8::Local::Local(v8::String*)
> DF *UND* Base gtk_grab_add
> DF *UND* Base gtk_hbutton_box_new
> DF *UND* NSS_3.4 SSL_GetChannelInfo
> DF *UND* GLIBC_2.4 __stack_chk_fail
> 086a6698 g DF .text 010a Base uprv_ebcdicFromAscii_3_8
> 0866af2e g DF .text 00d1 Base uprv_fmin_3_8
> DF *UND* Base gtk_widget_get_visual
> 091ab20c g DF .text 005d Base
> v8::ObjectTemplate::InternalFieldCount()
> 0885e164 w DF .text 0013 Base
> v8::Persistent::Persistent()
> DF *UND* Base
> gtk_file_chooser_set_preview_widget_active
> DF *UND* Base gdk_display_get_pointer
> 0880e3a2 g DF .text 02f4 Base ucol_tok_getNextArgument_3_8
> 086e6d5c g DF .text 01a1 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
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
On Tue, Jul 28, 2009 at 11:18 PM, Brian Ryner 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 0011 Base
std::reverse_iterator > >::base() const
090104dc w DF .text 0022 Basevoid
std::swap(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 0013 Basev8::Local::Local()
DF *UND* Basegtk_tree_model_get_value
0884d056 w DF .text 001a Base
v8::Local::Local(v8::String*)
DF *UND* Basegtk_grab_add
DF *UND* Basegtk_hbutton_box_new
DF *UND* NSS_3.4 SSL_GetChannelInfo
DF *UND* GLIBC_2.4 __stack_chk_fail
086a6698 gDF .text 010a Baseuprv_ebcdicFromAscii_3_8
0866af2e gDF .text 00d1 Baseuprv_fmin_3_8
DF *UND* Basegtk_widget_get_visual
091ab20c gDF .text 005d Base
v8::ObjectTemplate::InternalFieldCount()
0885e164 w DF .text 0013 Base
v8::Persistent::Persistent()
DF *UND* Base
gtk_file_chooser_set_preview_widget_active
DF *UND* Basegdk_display_get_pointer
0880e3a2 gDF .text 02f4 Baseucol_tok_getNextArgument_3_8
086e6d5c gDF .text 01a1 Baseupname_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',
],
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
+bryner for good old times sake, and because he knows about this stuff ;-) -Darin On Tue, Jul 28, 2009 at 8:18 PM, Mark Mentovai wrote: > > Evan Martin wrote: > > When we load a plugin any symbols we export come before its symbols. > > This doesn't happen on the Mac unless you go out of your way to > arrange for it to happen. > > Even so, we do use -fvisiblility=hidden for all Mac builds, because I > like for these things to be well-trimmed anyway. > > > 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 > > - in release builds, objdump -T doesn't show us exporting symbols, > > regardless of the flags I pass to gcc > > > > The resulting release binaries are within 1kb of each other. > > > > I don't really know what I'm doing, so my guess is that some other > > compilation flags we're using already produce the intended effect. > > Clearly this flag does *something* as the resulting binaries have > > slightly different sizes, but maybe it's not intended to apply to > > binaries or maybe it doesn't in my gcc (4.2.4). > > In order for any of this to apply to executables (as opposed to static > libraries), you need to be linking with ld -E. Otherwise, global > symbols that wind up in the executable don't get exported via the > dynamic symbol table. I don't know how you guys are linking, but this > can be significant here. > > This -E business applies to Linux/ELF. On the Mac, things work a > little differently: there's only one symbol table, symbols wind up in > it pretty much identically whether you're linking an executable or a > library, and as I mentioned above, the runtime loader does a better > job of resolving undefined symbols to the same libraries that provided > them at link time. > > Mark > > > > --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [linux, maybe mac] gcc -fvisibility=hidden
Evan Martin wrote: > When we load a plugin any symbols we export come before its symbols. This doesn't happen on the Mac unless you go out of your way to arrange for it to happen. Even so, we do use -fvisiblility=hidden for all Mac builds, because I like for these things to be well-trimmed anyway. > 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 > - in release builds, objdump -T doesn't show us exporting symbols, > regardless of the flags I pass to gcc > > The resulting release binaries are within 1kb of each other. > > I don't really know what I'm doing, so my guess is that some other > compilation flags we're using already produce the intended effect. > Clearly this flag does *something* as the resulting binaries have > slightly different sizes, but maybe it's not intended to apply to > binaries or maybe it doesn't in my gcc (4.2.4). In order for any of this to apply to executables (as opposed to static libraries), you need to be linking with ld -E. Otherwise, global symbols that wind up in the executable don't get exported via the dynamic symbol table. I don't know how you guys are linking, but this can be significant here. This -E business applies to Linux/ELF. On the Mac, things work a little differently: there's only one symbol table, symbols wind up in it pretty much identically whether you're linking an executable or a library, and as I mentioned above, the runtime loader does a better job of resolving undefined symbols to the same libraries that provided them at link time. Mark --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
