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

"David Abrahams" <> writes:

> Yes, thanks, I understand the reasons. However, there's a small difference
> if I understand things correctly: in these C++ cases, typically /all/ of
> the definitions are weak, right?

Right. There is the additional feature of "weak undefined references"
also, which the linker resolves to 0 if no definition is found at
run-time.  This is used to wrap thread libraries etc, so that the
application will link fine if no thread library is used; if the thread
library is linked, it will also be used to link the weak undefined

g++ uses that to implement thread-safe exception handling, without
requiring two versions of the runtime library.

> Yes, it's minimal, but when you don't attach some connotation of
> real-world semantics to these functions it's easy to miss the
> reasons that it should work differently.

I've been processing g++ bug reports for a while, and I usually
requested that people had their report in the following form:

- what is the code being executed
- what is the behaviour you observe
- what is the behaviour you expect

Optionally, there is a fourth item

- why do you think this behaviour is desirable.

This structure allows me to understand the issue quickly, without
having to understand complicated real-world architectures first, with
loads of unrelated stuff. I hated reports where people attached their
code as-is (of course, in gcc, there are specific exception to this
rule, e.g. for ICEs)


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