On 16/12/16 08:51 +0100, Jan Kratochvil wrote:
On Fri, 16 Dec 2016 02:07:07 +0100, Jonathan Wakely wrote:
On 15/12/16 22:19 +0100, Jan Kratochvil wrote:
> Just with the GDB 'compile' project (libcc1) which is planned to be used for
> all GDB expressions evalation the Xmethods will no longer work.
But then *it can just get compiled, so it will still work, right?
The only reason it doesn't work today is that the definition for
operator* might not be in the executable, but if you can compile a new
definition that doesn't matter.
Currently it cannot as the source for gcc (via libcc1) is (re)generated from
DWARF. Currently GDB does not provide original sources as a context for the
compiled expression.
Then maybe Xmethods should continue to work ;-)
The reason I'm so strongly against auto-dereferencing iterators is
that it's inconsistent, and dangerous. It only happens for *some*
iterators, the small set of containers from the C++03 std::lib that we
have printers for, and not for other iterators (such as pointers, or
iterators from C++11 containers, or user-defined iterators).
It's fundamentally wrong. An iterator is not the value it points at,
because it might not even point at anything (it could have a garbage
pointer that points to deallocated memory, or be past-the-end, which
isn't detectable in general, or perform some additional work to obtain
a value, like reverse_iterator does).
We don't do auto-deref for std::shared_ptr or std::unique_ptr, even
though we know the object they point to definitely is live and safe to
access, and that's because those types have pointer semantics not
reference semantics. Like iterators.
And if we can make 'print *it' always work then we don't need that
inconsistent auto-deref behaviour. It's up to the person driving GDB
to decide whether to try and dereference an iterator, we don't make
that decision for them.
Besides that there is a C++17 modules feature which should solve that for
LLDB as pointed out by Pedro before:
http://lists.llvm.org/pipermail/lldb-dev/2016-August/010870.html
Unaware if/when GDB 'compile' will handle C++ modules as a sources substitute
or if/when it will do the original source recompilation.
I think we're still a long way from being able to rely on that in the
GNU toolchain.
