Bug 16874

Err.

(gdb) b '(anonymous namespace)::foo'
Breakpoint 1 at 0x4005e1: file t.C, line 1.

this can't be really the desired way to do this ...

There is a DW_TAG_imported_module of the anon namespace in the TU context
so at least there referencing 'foo' needs to work.

And funnily

(gdb) b '(anonymous namespace)::pass_expand::<tab>

auto-"completes" to '(anonymous namespace)::

how useful.  All auto-completion seems to strip everything up to the
first ::.  Bah.

FWIW I've written a custom breakpoint-setting command using gdb's Python interface to try to workaround this from the gcc side:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg02011.html

Renaming.  It *is* possible to set a breakpoint on a function in an anonymous namespace, it's just way too tricky to do it right now, given that
(A) you have to type the full qualified name, and
(B) tab-completion is broken

and these make it sufficiently difficult that it's effectively not possible for a non-expert user.

So please can (A) and (B) be fixed.

You can do

gdb> break *foo

or if foo is inside an anonymous namespace of another TU, you can do

gdb> break *'foo.c'::foo

Is this functionality sufficient for your use case?

(In reply to patrick from comment #5)
> You can do
> 
> gdb> break *foo
No symbol "foo" in current context.

markus@x4 ~ % gdb -v
GNU gdb (GDB) 7.8.50.20140729-cvs

(In reply to Markus Trippelsdorf from comment #6)
> (In reply to patrick from comment #5)
> > You can do
> > 
> > gdb> break *foo
> No symbol "foo" in current context.
> 
> markus@x4 ~ % gdb -v
> GNU gdb (GDB) 7.8.50.20140729-cvs

The program has to be running for "break *" to work, it seems.

Try:

gdb> break main
gdb> run
gdb> break *foo

The workaround works to some extent, but tab-completion is still broken
and for

t1.C
-----
namespace { int foo (void) { return 0; } }
int bar(void);
int main() { return foo () + bar (); }

t2.C
-----
namespace { int foo2 (void) { return 1; } }
int bar () { return foo2 (); }

it doesn't allow me to set a breakpoint on t2.C::foo2 until I enter bar().
That is, using 'b *<name>' seems to do symbol lookup from the current
scope only.

For the GCC case the workaround doesn't work in practice for this reason.

b '(anonymous namespace)::foo2'

works from any context (but is quite awkward due to tab-completion being broken).

Created attachment 7974 [details]
Candidate patch

Here is a candidate patch that fixes this issue by allowing the user to omit the "(anonymous namespace)::" prefix when referencing symbols that are defined inside an anonymous namespace.  Tab completion is fixed accordingly, e.g. by allowing one to tab-complete "pass_exp" into "pass_expand" even though pass_expand is actually (anonymous namespace)::pass_expand.  This should work in breakpoint and expression context.

So the patch enables you to do

(gdb) break pass_exp<TAB>::execu<TAB>

to break on (anonymous namespace)::pass_expand::execute.

Created attachment 8515 [details]
updated patch

I've updated Patrick's patch for gdb trunk.

It works fine:
Example from comment0:

 % gdb ./a.out
Reading symbols from ./a.out...done.
(gdb) b fo<tab> 
Breakpoint 1 at 0x40058a: file anon_namesp.cpp, line 1.
(gdb) run
Starting program: /home/markus/a.out 
Breakpoint 1, (anonymous namespace)::foo () at anon_namesp.cpp:1

Example from comment8:

Reading symbols from ./a.out...done.
(gdb) b fo<tab><tab>
foo()   foo2()  
(gdb) b foo2() 
Breakpoint 1 at 0x4005b3: file t2.cpp, line 1.
(gdb) run
Starting program: /home/markus/a.out 
Breakpoint 1, (anonymous namespace)::foo2 () at t2.cpp:1
1       namespace { int foo2 (void) { return 1; } }

Any chance to move this issue forward?

I will try to.

I just ran into this today too while trying debug a new pass I was writing for GCC which uses anonymous namespaces :).

...and so did I.

This series will help with this:

 [PATCH 00/40] C++ debugging improvements: breakpoints, TAB completion, more
 https://sourceware.org/ml/gdb-patches/2017-06/msg00012.html

You can find it in the users/palves/cxx-breakpoint-improvements branch meanwhile, if you want to give it a try.

The series above is finally all merged to master.  These are the related improvements that you'll find there:

* Completion improvements

  ** GDB can now complete function parameters in linespecs and
     explicit locations without quoting.  When setting breakpoints,
     quoting around functions names to help with TAB-completion is
     generally no longer necessary.  For example, this now completes
     correctly:

      (gdb) b function(in[TAB]
      (gdb) b function(int)

     Related, GDB is no longer confused with completing functions in
     C++ anonymous namespaces:

      (gdb) b (anon[TAB]
      (gdb) b (anonymous namespace)::[TAB][TAB]
      (anonymous namespace)::a_function()
      (anonymous namespace)::b_function()

  ** GDB now has much improved linespec and explicit locations TAB
     completion support, that better understands what you're
     completing and offers better suggestions.  For example, GDB no
     longer offers data symbols as possible completions when you're
     setting a breakpoint.

  ** GDB now TAB-completes label symbol names.

  ** The "complete" command now mimics TAB completion accurately.

* Breakpoints on C++ functions are now set on all scopes by default

  By default, breakpoints on functions/methods are now interpreted as
  specifying all functions with the given name ignoring missing
  leading scopes (namespaces and classes).

  For example, assuming a C++ program with symbols named:

    A::B::func()
    B::func()

  both commands "break func()" and "break B::func()" set a breakpoint
  on both symbols.

  You can use the new flag "-qualified" to override this.  This makes
  GDB interpret the specified function name as a complete
  fully-qualified name instead.  For example, using the same C++
  program, the "break -q B::func" command sets a breakpoint on
  "B::func", only.

* Breakpoints on functions marked with C++ ABI tags

  GDB can now set breakpoints on functions marked with C++ ABI tags
  (e.g., [abi:cxx11]).  See here for a description of ABI tags:
  https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/

  Functions with a C++11 abi tag are demangled/displayed like this:

    function[abi:cxx11](int)
            ^^^^^^^^^^^

  You can now set a breakpoint on such functions simply as if they had
  no tag, like:

    (gdb) b function(int)

  Or if you need to disambiguate between tags, like:

    (gdb) b function[abi:other_tag](int)

  Tab completion was adjusted accordingly as well.

(In reply to Pedro Alves from comment #15)
> The series above is finally all merged to master.  These are the related
> improvements that you'll find there:

[...]

Thanks for the improvements!

> * Breakpoints on C++ functions are now set on all scopes by default
> 
>   By default, breakpoints on functions/methods are now interpreted as
>   specifying all functions with the given name ignoring missing
>   leading scopes (namespaces and classes).
> 
>   For example, assuming a C++ program with symbols named:
> 
>     A::B::func()
>     B::func()
> 
>   both commands "break func()" and "break B::func()" set a breakpoint
>   on both symbols.

To clarify, if there is a symbol:

      (anonymous namespace)::func()

will "break func" set a breakpoint on it?  (without me having to type or tab-complete the "(anonymous namespace)" part?)

[...]

(In reply to Dave Malcolm from comment #16)
> (In reply to Pedro Alves from comment #15)
> > The series above is finally all merged to master.  These are the related
> > improvements that you'll find there:
> 
> [...]
> 
> Thanks for the improvements!

My pleasure!  Making things better for GCC folks was one of my
sekrit driving forces.  :-)

> To clarify, if there is a symbol:
> 
>       (anonymous namespace)::func()
> 
> will "break func" set a breakpoint on it?  (without me having to type or
> tab-complete the "(anonymous namespace)" part?)
> 
> [...]

Yes.

I believe that since that series I mentioned is merged for a while and we haven't heard related negative pushback since, we can close this bug.  Please reopen if you believe otherwise.