mudflap: main objects are inited too late for a shared library constructor

[Eyal Lebedinsky]

I have a system that uses some shared libraries. I find that
when a library constructor runs the __wrap_main() did not
yet execute and as a results I get many violations on the
objects that it registers.

The attached program demonstrates 'stderr' (simple to do)
but my main problem is 'environ' which I interrogate at
that time.

What is the correct way of handling this?

-- 
Eyal Lebedinsky ([EMAIL PROTECTED]) 


zz40.sh
Description: application/shellscript

mudflap: compiler flags changed?

[Eyal Lebedinsky]

I was avoiding using mudflap for a while due to the high volume
of violations that I could not explain. Recently, they all
disappeared which made me happy and I started using mf. I got
zero violations since.

When I had time to think about it I figured this just cannot
be true.

I have now confirmed that using -fmudflapth causes most of the
checks to not happen. -fmudflap seems to have all checks done.

In the past -fmudflapth did the job. Something changed.

The help suggests that the two options have a function but it
is not clear (to me) what it is. Attached is a sample that
demonstrates how a simple violation is missed when -fmudflapth
is used (the program does not use threads).

-- 
Eyal Lebedinsky ([EMAIL PROTECTED]) 


zz39.sh
Description: application/shellscript

strange error on gcc 4.1.0

[Jack Howarth]

   I am trying to build xplor-nih on MacOS X 10.4 using gcc 4.1.0
branch's gcc and g++ instead of Apple's and am running into a really
strange error. I find the following linkage fails...

g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o 
libswigpy-xplor.dylib -o _xplorWrap.so 
-L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ -lcommon -lnmrPot 
-lintVar -lvmd -lpy  -lswigpy-xplor \
 -lcrypto -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/
g++-4: couldn't run 'undle-gcc-4.1.0': No such file or directory

I can't find any evidence of a undle-gcc-4.1.0 file in my build directory
for the current gcc main trunk cvs from which I built the installed
gcc 4.1.0 compiler. Shouldn't the stock gcc 4.1.0 support the -bundle
flag? Any idea why this flag isn't working?
 Jack

Re: mudflap: main objects are inited too late for a shared library constructor [patch]

[Eyal Lebedinsky]

Eyal Lebedinsky wrote:
> I have a system that uses some shared libraries. I find that
> when a library constructor runs the __wrap_main() did not
> yet execute and as a results I get many violations on the
> objects that it registers.

The attached patch seems to work for me, is it proper?

It registers the standard data items at init time. I allowed it
to register in wrap_main too, but maybe all we need is to register
it at init time rather than in wrap_main.

-- 
Eyal Lebedinsky ([EMAIL PROTECTED]) 
attach .zip as .dat
--- gcc/libmudflap/mf-runtime.c.old	2005-07-30 18:53:17.0 +1000
+++ gcc/libmudflap/mf-runtime.c	2005-07-30 17:18:20.0 +1000
@@ -681,6 +681,38 @@
   return trees[type];
 }
 
+static void
+__mf_register_std_data (void)
+{
+  static int been_here = 0;
+  unsigned i;
+
+  if (!__mf_opts.heur_std_data || been_here)
+	  return;
+
+  been_here = 1;
+
+  for (i=0; ; i++)
+{
+  char *e = environ[i];
+  unsigned j;
+  if (e == NULL) break;
+  j = strlen (environ[i]);
+  __mf_register (environ[i], j+1, __MF_TYPE_STATIC, "environ element");
+}
+  __mf_register (environ, sizeof(char *)*(i+1), __MF_TYPE_STATIC, "environ[]");
+
+  __mf_register (& errno, sizeof (errno), __MF_TYPE_STATIC, "errno area");
+
+  __mf_register (stdin,  sizeof (*stdin),  __MF_TYPE_STATIC, "stdin");
+  __mf_register (stdout, sizeof (*stdout), __MF_TYPE_STATIC, "stdout");
+  __mf_register (stderr, sizeof (*stderr), __MF_TYPE_STATIC, "stderr");
+
+  /* Make some effort to register ctype.h static arrays.  */
+  /* XXX: e.g., on Solaris, may need to register __ctype, _ctype, __ctype_mask, __toupper, etc. */
+  /* On modern Linux GLIBC, these are thread-specific and changeable, and are dealt
+ with in mf-hooks2.c.  */
+}
 
 /* not static */void
 __mf_init ()
@@ -724,6 +756,8 @@
   /* Prevent access to *NULL. */
   __mf_register (MINPTR, 1, __MF_TYPE_NOACCESS, "NULL");
   __mf_lookup_cache[0].low = (uintptr_t) -1;
+
+  __mf_register_std_data ();
 }
 
 
@@ -740,6 +774,8 @@
 {
   unsigned i;
 
+  __mf_register_std_data ();
+
   been_here = 1;
   __mf_register (argv, sizeof(char *)*(argc+1), __MF_TYPE_STATIC, "argv[]");
   for (i=0; i

Re: strange error on gcc 4.1.0

[Andreas Schwab]

[EMAIL PROTECTED] (Jack Howarth) writes:

>I am trying to build xplor-nih on MacOS X 10.4 using gcc 4.1.0
> branch's gcc and g++ instead of Apple's and am running into a really
> strange error. I find the following linkage fails...
>
> g++-4 -bundle -flat_namespace -undefined suppress _xplorWrap.o 
> libswigpy-xplor.dylib -o _xplorWrap.so 
> -L/Users/howarth/Desktop/xplor-nih-2.11.2.1/bin.Darwin_8/ -lcommon -lnmrPot 
> -lintVar -lvmd -lpy  -lswigpy-xplor \

$ info gcc 'Target Options'
[...]
`-b MACHINE'
 The argument MACHINE specifies the target machine for compilation.
[...]
 The `-V' and `-b' options work by running the
`-gcc-' executable, so there's no real reason to use
them if you can just run that directly.

> Shouldn't the stock gcc 4.1.0 support the -bundle flag?

It's an Apple-specific flag.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

mudflap - missed violation

[Eyal Lebedinsky]

I am investigating unusual results from mudflap tests. I added a some
test lines to my program to provoke violations and found that auto
variables are not checked correctly inside threads.

Attached is a test program that demonstrates the problem. It runs the
same code in main (and gets the two expected violations) and then in
a thread (the static is reported, the auto is not).

--
Eyal Lebedinsky ([EMAIL PROTECTED]) 


zz41.sh
Description: application/shellscript

Re: Large, modular C++ application performance ...

[Nix]

On 29 Jul 2005, Florian Weimer announced authoritatively:
> * michael meeks:
> 
>>  I've been doing a little thinking about how to improve OO.o startup
>> performance recently; and - well, relocation processing happens to be
>> the single, biggest thing that most tools flag.
> 
> Have you tried prelinking?

Prelinking is mentioned near the start of the paper and was actually
implemented with OOo (and KDE) in mind.

Alas, it's ineffective for dlopen()ed objects, and OOo dlopen()s nearly
everything. (To my mind the solution is `don't do that then; DT_NEEDED
has a purpose dammit'... certainly this is less disruptive than a change
to the C++ ABI, requiring cooperation with other vendors and a rebuild
of the entire known C++ universe yet again! But I am but an egg in these
waters.)

-- 
`Tor employs several thousand editors who they keep in dank
 subterranean editing facilities not unlike Moria' -- James Nicoll 

Re: Large, modular C++ application performance ...

[Giovanni Bajo]

michael meeks <[EMAIL PROTECTED]> wrote:

> I've been doing a little thinking about how to improve OO.o startup
> performance recently; and - well, relocation processing happens to be
> the single, biggest thing that most tools flag.
>
> Anyhow - so I wrote up the problem, and a couple of potential
> solutions / extensions / workarounds, and - being of a generally
> clueless nature, was hoping to solicit instruction from those of a more
> enlightened disposition.
>
> All input much appreciated; no doubt my terminology is irritatingly up
> the creek, hopefully the sentiment will win through.
>
> http://go-oo.org/~michael/OOoStartup.pdf
>
> Two solutions are proposed - there are almost certainly more that I'm
> not thinking of. I'm interested in people's views as to which approach
> is best. So far the constructor hook approach seems to be the path of
> least resistance.


I'm slow, but I can't understand why a careful design of the interfaces of
the dynamic libraries, together with the new -fvisibility flags, should not
be sufficient. It worked well in other scenarios
(http://gcc.gnu.org/wiki/Visibility).

IMHO, it's unreasonable to break the C++ ABI for 1 second of warm time
startup.
-- 
Giovanni Bajo

Re: strange error on gcc 4.1.0

[Jack Howarth]

Andreas,
 Are you sure gnu gcc shouldn't support this? I see -bundle under the
Machine Dependent Options under Darwin options which are not marked as
APPLE-ONLY. I understood that to mean that it should be present in the
gnu gcc compiler (like -all_load which is in the same list and is 
supported). Fortunately MacOS X 10.4 now supports a more linux-like dyload
that can use standard dynamic libraries .so files instead of just bundles
for shared library modules.
  Jack

Re: strange error on gcc 4.1.0

[Andrew Pinski]

> 
> Andreas,
>  Are you sure gnu gcc shouldn't support this? I see -bundle under the
> Machine Dependent Options under Darwin options which are not marked as
> APPLE-ONLY. I understood that to mean that it should be present in the
> gnu gcc compiler (like -all_load which is in the same list and is 
> supported). Fortunately MacOS X 10.4 now supports a more linux-like dyload
> that can use standard dynamic libraries .so files instead of just bundles
> for shared library modules.

It is a bug in the driver,  see PR 21366: .
There was a patch posted about this too but I cannot find it.

Thanks,
Andrew Pinski

re: Large, modular C++ application performance ...

[dank]

MM wrote in http://go-oo.org/~michael/OOoStartup.pdf:
"... not one slot was overridden by an implementation
method external to the implementing library."

Hmm.  For some reason that reminds me of the 'final'
keyword which is periodically proposed
(e.g. http://gcc.gnu.org/ml/gcc/2004-02/msg01483.html).
Is this a situation where 'final' would have a benefit?

Re: strange error on gcc 4.1.0

[Jack Howarth]

   I can't find a patch either using google but I did find the following
posting which describes the problem and a workaround...

http://www.mail-archive.com/fink-devel@lists.sourceforge.net/msg10604.html

Jack

Re: strange error on gcc 4.1.0

[Andrew Pinski]

On Jul 30, 2005, at 11:52 AM, Jack Howarth wrote:

   I can't find a patch either using google but I did find the  
following

posting which describes the problem and a workaround...

http://www.mail-archive.com/fink-devel@lists.sourceforge.net/ 
msg10604.html


I finally found the patch:
http://gcc.gnu.org/ml/gcc-patches/2002-12/msg00655.html
http://gcc.gnu.org/ml/gcc-patches/2002-10/msg01961.html

But I don't know what happened to it or came up from the discussion.

-- Pinski

Re: strange error on gcc 4.1.0

[Jack Howarth]

Here is another posting which describes the problem a little clearer...

http://lists.apple.com/archives/darwin-development/2003/Jun/msg0.html

So gcc needs to be fixed to not misparse -bundle, when it is the first
argument to gcc, as being the "-b Machine" target option.
 Shouldn't the fix be fairly simple? Just requiring that the
code that recognizes the -b flag require a trailing space after
the -b flag...otherwise it passes over it so that -bundle could be
recognized?
  Jack

Re: strange error on gcc 4.1.0

[Jack Howarth]

Thanks. It applies with offsets to the current 4.0 branch. Hopefully we can get
it in both branches soon. Currently everyone on Darwin is just hacking their
Makefiles around the problem.
  Jack

gcov weirdness: local lable being declared

[Kean Johnston]

Hi everyone,

I am getting weird warning messages from my assembler when
gcov is being used. I have tracked what I think is the
problem down but I don't really know how to fix it. The
bit of assembler that causes the warning is:

.type .LPBX0, @object
.size .LPBX0, 52
.LPBX0:
... whole bunch of initialization stuff

The assembler warns that the .type/.size directive is useless.
This is causing many testsuite failures. The assembler is
right. Why is a local lable being declared as if it was a
global symbol? .LPBX0 comes from ASM_GENERATE_INTERNAL_LABEL.

The problem seems to start in coverage.c:create_coverage().
Fairly close to the top of that is a call to assemble_variable().
assemble_variable(), ends up calling ASM_DECLARE_OBJECT_NAME.
This is what is emitting the .type and .size directives.

Is there some way that the tree can be marked as an internal
construct, and if that is set, not have the bit of code in
assemble_variable() call ASM_DECLARE_OBJECT_NAME? Or perhaps
I can train A_D_O_N to not emit anything if its a local?

I see that the tree in question is declared static. Would it
be the right thing to have something like this at the end of
assemble_variable:

   if (!TREE_STATIC (decl)) {
#ifdef ASM_DECLARE_OBJECT_NAME
 last_assemble_variable_decl = decl;
 ASM_DECLARE_OBJECT_NAME (asm_out_file, name, decl);
#else
 /* Standard thing is just output label for the object.  */
 ASM_OUTPUT_LABEL (asm_out_file, name);
#endif
   }

I am not sure if "if (TREE_STATIC (decl))" is the correct test.
Is there a better test that I can check for an internal lable?

Thanks in advance for any insight.

Kean

Re: Large, modular C++ application performance ...

[Andrew Haley]

Giovanni Bajo writes:
 > michael meeks <[EMAIL PROTECTED]> wrote:
 > 
 > > I've been doing a little thinking about how to improve OO.o startup
 > > performance recently; and - well, relocation processing happens to be
 > > the single, biggest thing that most tools flag.
 > >
 > > Anyhow - so I wrote up the problem, and a couple of potential
 > > solutions / extensions / workarounds, and - being of a generally
 > > clueless nature, was hoping to solicit instruction from those of a more
 > > enlightened disposition.
 > >
 > > All input much appreciated; no doubt my terminology is irritatingly up
 > > the creek, hopefully the sentiment will win through.
 > >
 > > http://go-oo.org/~michael/OOoStartup.pdf

One thing I don't understand is the formula where you write linking
time is proprortional to the log of the total number of symbols.  Does
this come from drepper's paper, or somewhere else?

Andrew.

gcc-4.1-20050730 is now available

[gccadmin]

Snapshot gcc-4.1-20050730 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050730/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.1 CVS branch
with the following options:  -D2005-07-30 17:43 UTC

You'll find:

gcc-4.1-20050730.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20050730.tar.bz2 C front end and core compiler

gcc-ada-4.1-20050730.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20050730.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20050730.tar.bz2  C++ front end and runtime

gcc-java-4.1-20050730.tar.bz2 Java front end and runtime

gcc-objc-4.1-20050730.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20050730.tar.bz2The GCC testsuite

Diffs from 4.1-20050723 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: -fprofile-generate and -fprofile-use

[Jan Hubicka]

> Jan,
Hi,
> That's going to be rather difficult given that the app
> has over 1000 files. Is there a way I can turn off the
> "default" options one at a time ?

This is unforutnately not possible :(  The optimizations used either
profile feedback or profile guessed by GCC itself.  It looks like for
your case the profile guessed by GCC (even if departed from reality)
causes GCC to produce better code than the real profile (or that the
real profile got missread, but there are some sanity checks for this so
this is quite unlikely).

It seems to me that only way to proceed from here is some profiling.
The way I usually look into such problems is to produce oprofile of both
versions of code and then compare the times spent in individual
functions then it is sometimes possible to identify the offending code
more easilly

Honza

> Thx
> -girish
> 
> --- Jan Hubicka <[EMAIL PROTECTED]> wrote:
> 
> > > I have done quite a few experiments with this to
> > > narrow down the problem. The performance numbers
> > are 
> > > slower compared to *No Feedback optimization with
> > just
> > > -O3* Here are some of them. All the experiments
> > were
> > > done on a new build-area in order to eliminate
> > effects
> > > of old feedback files.
> > > 
> > > 1. I built the app using -O3 and
> > -fprofile-generate to
> > > generate the feedback data. I then ran the
> > workload
> > > and then recompiled the app using -O3 and
> > > -fprofile-use [app was 20% slower]
> > > 
> > > 2. I built the app using -O3 and
> > -fprofile-generate to
> > > generate the feedback data. I then ran the
> > workload
> > > and then recompiled the app using -O3 and
> > > -fprofile-use -fno-vpt -fno-unroll-loops
> > > -fno-peel-loops -fno-tracer (Which is turn off all
> > the
> > > flags used by -fprofile-use) [App was still 20%
> > > slower]
> > > 
> > > 3. I have tried selectively turning of some of the
> > > other flags in the above list as well, but the
> > > performance regression persists.
> > > 
> > > 4. I tried with the older flags namely
> > -fprofile-arcs
> > > and -fbranch-probabilities still no help.
> > 
> > So it looks like the slowdown is caused by one of
> > the profile based
> > optimizations that are enabled by default (basic
> > block reordering or
> > register allocation).  If you are getting such a
> > noticable slodown, it
> > probably means that your app has pretty small inner
> > loop.  Can you just
> > look into assembly generated for it with and without
> > profiling and try
> > to spot what is gong wrong?
> > 
> > Thanks,
> > Honza
> > > 
> > > Can someone help me out on how to proceed with
> > this.
> > > 
> > > Thanks
> > > -girish
> > > 
> > > 
> > > --- Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > > 
> > > > > I started with a clean slate in my build
> > > > environment
> > > > > and did not have any residual files hanging
> > > > around.
> > > > > Are the steps I have indicated in my earlier
> > email
> > > > > correct. Is there a way I can break down the
> > > > problem
> > > > > into a smaller sub-set of flags and eliminate
> > the
> > > > flag
> > > > > causing the performance problem. What I mean
> > is
> > > > since
> > > > > -fprofile-generate and -fprofile-use enable a
> > > > bunch of
> > > > > flags, would it make sense to avoid profiling
> > and
> > > > try
> > > > > out some of the individual flags on a trial
> > and
> > > > error
> > > > > basis. If so what would be the flags to start
> > the
> > > > It would be probably better to just turn off the
> > > > individual
> > > > optimizations with -fprofile-use (for
> > optimizations
> > > > that are implied by
> > > > this flag there should be no need to re-profile
> > each
> > > > time).
> > > > If you can find particular optimization that
> > gets
> > > > out of control, it
> > > > would be lot easier to fix it...
> > > > 
> > > > Honza
> > > > > trials with.
> > > > > 
> > > > > -girish 
> > > > > 
> > > > > --- Jan Hubicka <[EMAIL PROTECTED]> wrote:
> > > > > 
> > > > > > > On Wed, Jul 20, 2005 at 10:45:01AM -0700,
> > > > girish
> > > > > > vaitheeswaran wrote:
> > > > > > > > > --- Steven Bosscher <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > > > > > 
> > > > > > > > > > On Wednesday 20 July 2005 18:53,
> > girish
> > > > > > vaitheeswaran wrote:
> > > > > > > > > > > I am seeing a 20% slowdown with
> > > > feedback
> > > > > > optimization.
> > > > > > > > > > > Does anyone have any thoughts on
> > this.
> > > > > > > > > > 
> > > > > > > > > > My first thought is that you should
> > > > probably
> > > > > > first
> > > > > > > > > > tell what compiler
> > > > > > > > > > you are using.
> > > > > > > >
> > > > > > > > I am using gcc 3.4.3
> > > > > > > > -girish
> > > > > > > 
> > > > > > > Which platform?  I've seen slower code for
> > > > > > profile-directed optimizations
> > > > > > > on powerpc64-linux with GCC 4.0 and
> > mainline. 
> > > > > > It's a bug, but I haven't
> > > > > > > looked into it enough to provide a small
> > test
> > > > case
> 

Re: gcov weirdness: local lable being declared

[Ian Lance Taylor]

Kean Johnston <[EMAIL PROTECTED]> writes:

> I am getting weird warning messages from my assembler when
> gcov is being used. I have tracked what I think is the
> problem down but I don't really know how to fix it. The
> bit of assembler that causes the warning is:
> 
>  .type .LPBX0, @object
>  .size .LPBX0, 52
> .LPBX0:
>  ... whole bunch of initialization stuff
> 
> The assembler warns that the .type/.size directive is useless.
> This is causing many testsuite failures. The assembler is
> right. Why is a local lable being declared as if it was a
> global symbol? .LPBX0 comes from ASM_GENERATE_INTERNAL_LABEL.

I don't understand why the .type and .size information is useless.
The information is recorded in the object file.  I've seen various
scripts which use that information to do things like associate address
space with variables.  I think the assembler should just be recording
the information, not warning about it.

If you do need a patch for it, I think it should be SCO specific, and
only #if !USE_GAS.

Ian

Re: gcov weirdness: local lable being declared

[Kean Johnston]

I don't understand why the .type and .size information is useless.

Becuase its for a local lable only, not anything thats intended
to wind up in the symbol table? I'm not sure what meaning a
type and size has for a local lable like that?

Kean

Re: gcov weirdness: local lable being declared

[Kean Johnston]

I don't understand why the .type and .size information is useless.

Just some further information ... gas thinks it's useless too.


The information is recorded in the object file.  I've seen various

No, it's not. At least not with gas 2.15.90.0.3. Just is just
silent about it. The SCO assembler is producing a warning because
if you have .type and .size for a sybol or lable for which
those things have no meaning, it warns you in case you meant
to do something else with the symbol. I believe the warning
message is valid.

In my original post, I asked if checking TREE_STATIC would be
the right thing. While it does shut the warning up, I don't think
it is. What we'd really need is some way to mark a tree as
internal. Then in coverage.c, mark the contructed variable
that way. For example, TREE_INTERNAL (gcov_info) = 1. The
only problem is that in order to do this, we would need to invent
a new bit in tree_common. Although there is an unused bit
available, I am not sure this has wide enough utility to
justify using it. But maybe it does. I leave it up to the
experts to decide.

An second solution would be to have create_coverage()
use a symbol name that isn't an internal lable. For example,
prefixing it with __gcov_. That also solves the problem.

A third alternatie would be to make A_D_O_N smarter,
and check to see if the first character of the name is
a period, and not eject the .size and .type if it is.

Anyone care to advise what the best course of action
would be? I'm leaning towards the second solution.

Kean

Symbol versions for inlined symbols

[Mike Hearn]

Hi,

One problem with the parallel C++ ABI versioning (which makes it not so
useful) is that symbols in the libstdc++ namespaces are put into the
generated binary if you use the STL. Those generated symbols are *not*
symbol versioned so conflicts can still occur.

This is registered in bugzilla and has been for a while, with no sign of a
fix. So I thought I'd look at it.

Would an acceptable solution be to have a new attribute that set the
symbol version for inlined functions. That way, the STL headers could be
annotated like so:

class XXX
{
int STD_VERSION std::whatever() { return 4; }
}

An alternative approach would be to have the linker assigned inlined
symbols the same version tag as whatever the same symbol in libstdc++ has,
but I'm not sure how I'd implement this.

Does anybody have insight?

thanks -mike

Re: gcov weirdness: local lable being declared

[Ian Lance Taylor]

Kean Johnston <[EMAIL PROTECTED]> writes:

> > I don't understand why the .type and .size information is useless.
> Becuase its for a local lable only, not anything thats intended
> to wind up in the symbol table? I'm not sure what meaning a
> type and size has for a local lable like that?

Oh, I see what you mean.  Sorry.  What if you use the -L assembler
option, though?

I was misled a bit by TREE_STATIC, which is not the property you are
looking for.

> An second solution would be to have create_coverage()
> use a symbol name that isn't an internal lable. For example,
> prefixing it with __gcov_. That also solves the problem.

That sounds like a reasonable approach to me.  I don't see why it is
useful to hide these symbols entirely in any case.  It seems more
useful to have them visible to the debugger, etc.

Ian

Re: strange error on gcc 4.1.0

[Mike Stump]

On Saturday, July 30, 2005, at 09:09 AM, Andrew Pinski wrote:

But I don't know what happened to it or came up from the discussion.


Looks like no response to Geoff's last comment.  If someone wants to 
address his stated concerns and resubmit it...  otherwise, -Wl,-bundle 
should do the trick.

Re: Symbol versions for inlined symbols

[Daniel Jacobowitz]

On Sat, Jul 30, 2005 at 09:33:45PM +0100, Mike Hearn wrote:
> Hi,
> 
> One problem with the parallel C++ ABI versioning (which makes it not so
> useful) is that symbols in the libstdc++ namespaces are put into the
> generated binary if you use the STL. Those generated symbols are *not*
> symbol versioned so conflicts can still occur.

You may wish to read the proceedings from this year's GCC summit, where
another solution was presented by some gentlemen from Intel.  For
various reasons, symbol versioning is not a useful solution to this
problem.

No one objected to their solution in principle, AFAICT, although there
was some discussion afterwards about whether the use of strong
namespace using was really necessary.  I'm afraid I don't understand
C++ well enough to explain the rest of that conversation.

May just need someone to do the work.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Symbol versions for inlined symbols

[dank]

> You may wish to read the proceedings from this year's GCC summit, where
> another solution was presented by some gentlemen from Intel.  For
> various reasons, symbol versioning is not a useful solution to this
> problem.
>
> No one objected to their solution in principle, AFAICT, although there
> was some discussion afterwards about whether the use of strong
> namespace using was really necessary

FWIW, I tried to capture some of the discussion at
http://kegel.com/gcc/diary.txt