Re: [PATCH v1.1 1/3] Introduce gdb::function_view

[Pedro Alves <palves@redhat.com>]

On 02/22/2017 10:11 PM, Yao Qi wrote:

> Double "a" at the end.

> 
> Double "while"s.

Thanks, fixed.

> 
>> +namespace gdb {
>> +
> 
> This is a new namespace in gdb source.  What is the rule of using this
> namespace?

I don't have a hard rule predetermined.  I originally put the C++03
unique_ptr shim under the gdb namespace to make it clear at the
call sites that that was not the std type, but gdb's replacement.
I.e., gdb::unique_ptr vs std::unique_ptr.  Since then, gdb::unique_ptr is
gone, but gdb::unique_xmalloc_ptr remains, and we've been putting
these generic library-like utilities under the namespace:

 common/function-view.h:154:namespace gdb {
 common/function-view.h:353:} /* namespace gdb */
 common/gdb_unlinker.h:23:namespace gdb
 common/gdb_unique_ptr.h:25:namespace gdb
 common/gdb_unique_ptr.h:43:} /* namespace gdb */
 common/gdb_optional.h:23:namespace gdb
 common/gdb_ref_ptr.h:25:namespace gdb

I think putting these new things in _some_ namespace is the
right thing to do.  gdb is just the no-brainer namespace name.

IMO, _all_ of GDB should be under "namespace gdb".  Then these utilities
would either be put in "namespace gdb" too, or in a "namespace gtl",
for "gdb template library" or something like that.  Or we could
put them under "gtl" already.

I have a series that put the whole of gdb under namespace gdb:
 https://github.com/palves/gdb/commits/palves/cxx-gdb-namespace

I wrote that while experimenting with ways to use
gnulib's C++ namespace mode, in order to avoid the 
"#define open rpl_open" defines gnulib does...  I nowadays
believe the put-gdb-in-a-namespace approach is the best one.

However, when we put gdb under a namespace, debugging GDB itself
becomes a bit harder, since you then have to do "b gdb::some_function"
instead of "b some_function".  This is just dogfooding pain,
of course, users run into this too...

That's what led to me to work on this branch:

 https://github.com/palves/gdb/commits/palves/cp-linespec-2

with that, "b some_function" sets breakpoints on all
functions/methods named some_function in all namespaces.

And it was testing that branch with --target_board=dwarf4-gdb-index
that led to the bug fixed by this series...  It's a never
ending story... :-)

Thanks,
Pedro Alves