This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
From: "Martin v. Loewis" <martin@v.loewis.de>
> "David Abrahams" <david.abrahams@rcn.com> writes:
>
> > I think that's a mischaracterization of my position. Have you read my
other
> > postings (especially http://gcc.gnu.org/ml/gcc/2002-05/msg00869.html)?
>
> Why keep you asking whether people have read important information
> that you have shared?
Because I can't tell whether they read it, and it's hard to know where to
go in a conversation when you don't know how much of the background the
people you're talking with may have missed.
> Please just assume they did, and don't hesitate
> to repeat information in context, perhaps with different wording, to
> make you better understood, in case you feel you weren't understood
> the first time.
If I thought the post had left room for misinterpretation, I'd have done
that. Anyway, no offense was intended, and I don't mind trying to find
different ways to repeat myself until I think I'm understood.
> > > That would be equally wrong,
> >
> > Wrongness can't be determined until the standard describes the behavior
of
> > shared libs.
>
> In absence of a well definition, people usually consider the compiler
> "wrong" if it doesn't do what they expect it to do.
Then it's going to be wrong for lots of people until we have a good
definition. And then it's still going to be wrong ;-)
> > In this case a redesign of the library which uses a non-inline function
> > fixes the problem.
>
> By redesigning the code of the library, every problem can be
> solved. Just don't throw exceptions across DSO boundaries, and this
> specific problem goes away.
Point taken, but still the cases are very different. One looks like an
implementation detail to a library's users; the other one doesn't.
> > I wouldn't know where to start with that one. Is there an explicit way
to
> > mark a symbol "weak"?
>
> On the assember level, with the .weak directive. On C level, either
> with a __asm__ statement, or (I believe) with an
> __attribute__((weak)).
If I understand correctly, weak symbols were introduced to allow things
like users replacing malloc, free, operator new, etc. AFAIK, there are
specific symbols which are meant to work this way: the user's definition
gets priority over that in any of his dependencies. AFAICT, this model is
part of the reason for the current behavior we're seeing with C++. However,
I think the same case could be made by putting malloc/free replacements in
each of two extension modules which are linked to a common shared lib,
right? Then memory allocated by ext2 couldn't be freed by the common lib,
and vice-versa. Can you think of a more-minimal or more-compelling test
case?
-Dave