This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Minimal GCC/Linux shared lib + EH bug example

From: "Martin v. Loewis" <>

> "David Abrahams" <> writes:
> > I think that's a mischaracterization of my position. Have you read my
> > postings (especially
> 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
> > 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
> > 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]