Hi,

Consider the following lambda (from the test case):

     int ret = fudge ([this] () {
         return a_;   /* break here */
       });

Breaking at "break here" and printing "a_" will cause gdb to crash with 
clang++ (3.3).

This happens because lookup_symbol_file tries trying to locate a member 
variable with the name "a_":

       /* A simple lookup failed.  Check if the symbol was defined in
          a base class.  */

       cleanup = make_cleanup (null_cleanup, NULL);

       /* Find the name of the class and the name of the method,
          variable, etc.  */
       prefix_len = cp_entire_prefix_len (name);

       /* If no prefix was found, search "this".  */
       if (prefix_len == 0)
         {
           struct type *type;
           struct symbol *this;

           this = lookup_language_this (language_def (language_cplus), 
block);
           if (this == NULL)
             {
               do_cleanups (cleanup);
               return NULL;
             }

           type = check_typedef (TYPE_TARGET_TYPE (SYMBOL_TYPE (this)));
           klass = xstrdup (TYPE_NAME (type));
           nested = xstrdup (name);
         }

TYPE_NAME (type) is NULL, so xstrdup (NULL) and boom!

This occurs because of the DWARF that clang++ outputs. IMO, the output, 
while valid DWARF, is nonsensical from a C++ perspective:

  <2><135>: Abbrev Number: 20 (DW_TAG_subprogram)
     <136>   DW_AT_specification: <0x8a>
     <13a>   DW_AT_low_pc      : 0x400640
     <142>   DW_AT_high_pc     : 0x400653
     <14a>   DW_AT_frame_base  : 1 byte block: 56        (DW_OP_reg6 (rbp))
     <14c>   DW_AT_object_pointer: <0x150>
  <3><150>: Abbrev Number: 21 (DW_TAG_formal_parameter)
     <151>   DW_AT_name        : (indirect string, offset: 0x60): this
     <155>   DW_AT_decl_file   : 1
     <156>   DW_AT_decl_line   : 6
     <157>   DW_AT_type        : <0x211>
     <15b>   DW_AT_artificial  : 1
     <15b>   DW_AT_location    : 2 byte block: 91 78     (DW_OP_fbreg: -8)
  <2><15f>: Abbrev Number: 21 (DW_TAG_formal_parameter)
     <160>   DW_AT_name        : (indirect string, offset: 0x60): this
     <164>   DW_AT_decl_file   : 1
     <165>   DW_AT_decl_line   : 5
     <166>   DW_AT_type        : <0x5e>
     <16a>   DW_AT_artificial  : 1
     <16a>   DW_AT_location    : 2 byte block: 91 78     (DW_OP_fbreg: -8)

The nonsensical part of this is the output of two variables named 
`this', one artificial and one concrete.

In any case, the type of `this' (the artificial one) is given by DIE 0x211:
  <1><63>: Abbrev Number: 6 (DW_TAG_const_type)
     <64>   DW_AT_type        : <0x77>
[snip]
  <1><77>: Abbrev Number: 8 (DW_TAG_class_type)
     <78>   DW_AT_byte_size   : 8
     <79>   DW_AT_decl_file   : 1
     <7a>   DW_AT_decl_line   : 6
  <2><7b>: Abbrev Number: 9 (DW_TAG_member)
     <7c>   DW_AT_name        : (indirect string, offset: 0x60): this
     <80>   DW_AT_type        : <0x5e>
     <84>   DW_AT_decl_file   : 1
     <85>   DW_AT_decl_line   : 6
     <86>   DW_AT_data_member_location: 2 byte block: 23 0 
(DW_OP_plus_uconst: 0)
     <89>   DW_AT_accessibility: 3       (private)
[snip]
  <1><211>: Abbrev Number: 5 (DW_TAG_pointer_type)
     <212>   DW_AT_type        : <0x63>

As you can see, the compiler did not output DW_AT_name for this class.

The simple patch, of course, is to check for TYPE_NAME == NULL before 
continuing with lookup_symbol_file.

That was the easy part. The not-so-easy/questionable part is the test 
case, which uses the (assembler) output of the compiler to run against. 
Writing by hand is very time-consuming and tricky, because we must be 
stopped inside the lambda function in order to trigger the bug.

In any case, I thought I would submit this and see if anyone had any 
better ideas.

Keith
ChangeLog
2014-03-20  Keith Seitz  <keiths@redhat.com>

	PR c++/16597
	* cp-namespace.c (lookup_symbol_file): If the type name of
	`this' is NULL, return immediately.

testsuite/ChangeLog
2014-03-20  Keith Seitz  <keiths@redhat.com>

	PR c++/16597
	* gdb.cp/namelessclass.exp: New file.
	* gdb.cp/namelessclass.S: New file.