Fix DWARF handling of inlined functions in namespaces

Fix DWARF handling of inlined functions in namespaces

Currently an inlined function in a namespace in DWARF will
be given a name comprised of just `namespace::`. This is due
to a logic error in ComputeQualifiedName, where it doesn't
handle an empty `unqualified_name` properly.

We apparently have a fair number of these in our Mac builds,
an example of the DWARF that's being mishandled looks like:
0x117eda40:     TAG_namespace [5] *
                 AT_name( "js" )
                 AT_decl_file( "../../dist/include/js/Utility.h" )
                 AT_decl_line( 35 )

0x11808500:         TAG_subprogram [251] *
                     AT_low_pc( 0x0000000002f12110 )
                     AT_high_pc( 0x0000000002f1216b )
                     AT_APPLE_omit_frame_ptr( 0x01 )
                     AT_frame_base( rsp )
                     AT_abstract_origin( {0x0000000011800a4f}"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
                      AT_MIPS_linkage_name( "_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
                      AT_name( "TraceManuallyBarrieredGenericPointerEdge" )
                      AT_decl_file( "/builds/slave/rel-m-rel-m64_bld-000000000000/build/js/src/gc/Marking.cpp" )
                      AT_decl_line( 547 )
                      AT_external( 0x01 )
                      AT_APPLE_optimized( 0x01 )
                      AT_inline( DW_INL_inlined )

This turned a few instances of this in the file I was testing on into
`<name omitted>`, which seems to just be a symptom of the
"DW_AT_abstract_origin comes later in the file" issue. (Which is probably
also worth fixing given that it occurs some 29k times when dumping
symbols from Firefox's XUL binary, but it's a separate issue.)

R=mark@chromium.org
BUG=

Committed: https://chromium.googlesource.com/breakpad/breakpad/+/2e266396ee14f3c00252863704716b0e4b0fc3f0

[Mark Mentovai, 2016-04-14 14:28:00]

LGTM

[Ted Mielczarek, 2016-04-14 14:32:23]

Description was changed from

==========
Fix DWARF handling of inlined functions in namespaces

Currently an inlined function in a namespace in DWARF will
be given a name comprised of just `namespace::`. This is due
to a logic error in ComputeQualifiedName, where it doesn't
handle an empty `unqualified_name` properly.

We apparently have a fair number of these in our Mac builds,
an example of the DWARF that's being mishandled looks like:
0x117eda40:     TAG_namespace [5] *
                 AT_name( "js" )
                 AT_decl_file( "../../dist/include/js/Utility.h" )
                 AT_decl_line( 35 )

0x11808500:         TAG_subprogram [251] *
                     AT_low_pc( 0x0000000002f12110 )
                     AT_high_pc( 0x0000000002f1216b )
                     AT_APPLE_omit_frame_ptr( 0x01 )
                     AT_frame_base( rsp )
                     AT_abstract_origin(
{0x0000000011800a4f}"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc"
)
                      AT_MIPS_linkage_name(
"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
                      AT_name( "TraceManuallyBarrieredGenericPointerEdge" )
                      AT_decl_file(
"/builds/slave/rel-m-rel-m64_bld-000000000000/build/js/src/gc/Marking.cpp" )
                      AT_decl_line( 547 )
                      AT_external( 0x01 )
                      AT_APPLE_optimized( 0x01 )
                      AT_inline( DW_INL_inlined )

This turned a few instances of this in the file I was testing on into
`<name omitted>`, which seems to just be a symptom of the
"DW_AT_abstract_origin comes later in the file" issue. (Which is probably
also worth fixing given that it occurs some 29k times when dumping
symbols from Firefox's XUL binary, but it's a separate issue.)

R=mark@chromium.org
BUG=
==========

to

==========
Fix DWARF handling of inlined functions in namespaces

Currently an inlined function in a namespace in DWARF will
be given a name comprised of just `namespace::`. This is due
to a logic error in ComputeQualifiedName, where it doesn't
handle an empty `unqualified_name` properly.

We apparently have a fair number of these in our Mac builds,
an example of the DWARF that's being mishandled looks like:
0x117eda40:     TAG_namespace [5] *
                 AT_name( "js" )
                 AT_decl_file( "../../dist/include/js/Utility.h" )
                 AT_decl_line( 35 )

0x11808500:         TAG_subprogram [251] *
                     AT_low_pc( 0x0000000002f12110 )
                     AT_high_pc( 0x0000000002f1216b )
                     AT_APPLE_omit_frame_ptr( 0x01 )
                     AT_frame_base( rsp )
                     AT_abstract_origin(
{0x0000000011800a4f}"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc"
)
                      AT_MIPS_linkage_name(
"_ZN2js40TraceManuallyBarrieredGenericPointerEdgeEP8JSTracerPPNS_2gc4CellEPKc" )
                      AT_name( "TraceManuallyBarrieredGenericPointerEdge" )
                      AT_decl_file(
"/builds/slave/rel-m-rel-m64_bld-000000000000/build/js/src/gc/Marking.cpp" )
                      AT_decl_line( 547 )
                      AT_external( 0x01 )
                      AT_APPLE_optimized( 0x01 )
                      AT_inline( DW_INL_inlined )

This turned a few instances of this in the file I was testing on into
`<name omitted>`, which seems to just be a symptom of the
"DW_AT_abstract_origin comes later in the file" issue. (Which is probably
also worth fixing given that it occurs some 29k times when dumping
symbols from Firefox's XUL binary, but it's a separate issue.)

R=mark@chromium.org
BUG=

Committed:
https://chromium.googlesource.com/breakpad/breakpad/+/2e266396ee14f3c00252863...
==========

[Ted Mielczarek, 2016-04-14 14:32:25]

Committed patchset #1 (id:1) manually as
2e266396ee14f3c00252863704716b0e4b0fc3f0 (presubmit successful).