I am aware of the ability to modify the handler for the "pure virtual function called" error message via something like: namespace __cxxabiv1 { extern "C" void __cxa_pure_virtual(void) { // Print a backtrace, etc... std::terminate(); } } It is a great shame that the default, gcc-supplied function declaration does not take an argument of the function pointer that was called, then the RTTI information could be output. Note that the error message comes from a pure virtual base class on which a pure virtual function has been called. Therefore one would suppose that the was guaranteed to be RTTI information regarding that function call, if not the enclosing pure virtual base class. So the default implementation of __cxa_pure_virtual() would be able to call "typeid(ptr_to_mem_fn).name()" to provide actual type information regarding the class and the function that was attempted to be called. I realise that the declaration could be difficult, because the new argument to __cxa_pure_virtual(...) would need to be able to cope with both void and non-void return types, cv-qualifiers, and arbitrary arguments. i.e. it would need some form of declaration "magic". But the code is within the compiler! At the call site where the canary is being placed, the type of the member function is explicitly known, so the specific declaration (in particular the ptr-to-mem-fn argument) of __cxa_pure_virtual() can be generated for that call site, and therefore typeid(of the ptr-to-mem-fn arg) could be correctly generated. If I knew how g++ worked internally, I'd do this change. But I don't, I'm sorry. The issue I face is that I have a multi-threaded program that has a race condition that causes the "pure virtual function call" error very rarely. The code-base is very large, so it is very hard (I have tried) to track down where the bug is. It does not appear in debug builds (-O0) and using my own implementation of __cxa_pure_virtual() and calling set_terminate with my own functions that generate backtraces has not created the backtrace I'd hope for. I know also that the code I am referring to above is buggy, therefore I should "just not write it". True. But surely improving the quality of the error message with the class name and function name in the "pure virtual method called" message would be og much help to the C++ community at large?
The function signature is defined by the ABI so we can't change it. http://mentorembedded.github.io/cxx-abi/abi.html#pure-virtual
(With due sense of dread:) I note that the __cxxabiv1 seems to have a v1 in it. Why not define a v2 with a better signature? Although I realise that this is a quality-of-implementation issue, why should an apparently mis-declared function signature be considered acceptable? I do not agree that this enhancement should be marked as resolved invalid: I think that is a cop-out frankly.
But this isn't the place to propose changes to the ABI, because it's used by several different compilers and if G++ started emitting a call to a different version of __cxa_pure_virtual that would break compatibility with other compilers using the same ABI. So this is not something that can be added to GCC unless it is first added to the ABI.
Once the existence of the restricted ABI was pointed out to me I did not propose to change it. I proposed creating a new version of the ABI that would have an improved signature. That signature would be dependent upon what the compiler could emit. It is not unreasonable to assume that there is an interplay between what the compiler can emit which should drive the specification of the ABI. I have edited the status to "closed/wontfix" as clearly there is no inclination to implement this enhancement.
Hang on: what has the ABI got to do with this? This discussion has got side tracked onto a red herring. The code emitted by gcc apparently *eventually* calls __cxa_pure_virtual, as we know. The signature of __cxa_pure_virtual could be irrelevant: what is relevant is the *code path* that calls this function. The code path could be enhanced to provide the extra information to the user. The ABI function can then be left as is. So I've re-opened the enhancement request.
Note now adays most calls to __cxa_pure_virtual are replaced with __builtin_unreachable so you won't even get the call to __cxa_pure_virtual any more so closing this as invalid.