Take DW_TAG_namespace's name into account when reading DW_AT_name

[bjorn3]

For example alloc::boxed::Box::new will have a DW_AT_name of new, but it is nested in several DW_TAG_namespace which are named alloc, boxed and Box respectively.

[philipc]

Finding the DW_TAG_namespace entries would be very expensive, and DW_AT_name is only a fallback. We should be using DW_AT_linkage_name instead:

< 4><0x00000039>          DW_TAG_subprogram
                            DW_AT_linkage_name          _ZN5alloc5boxed12Box$LT$T$GT$3new17h8819ec3570e2d1e8E
                            DW_AT_name                  new<u32>
                            DW_AT_decl_file             0x00000002 /rustc/4fb7144ed159f94491249e86d5bbd033b5d60550/src/liballoc/boxed.rs
                            DW_AT_decl_line             0x000000ae
                            DW_AT_type                  0x00000068<.debug_info+0x0000033a>
                            DW_AT_inline                DW_INL_inlined

[bjorn3]

The linkage name is missing the type parameters.

[philipc]

Is this issue also proposing that we use DW_AT_name instead of DW_AT_linkage_name?

[bjorn3]

I guess it could be another method.

[philipc]

Is this still of interest to you?

Rough proof of concept at https://github.com/philipc/addr2line/commit/c532758c3e294c8cce75814d901298b037bea4de This changes it to return both the linkage name and the name/namespace.

Performance comparison below. There might be room for some optimization.

 name                                        before ns/iter  after ns/iter  diff ns/iter  diff %  speedup 
 context_new_and_query_location_rc           1,576,415       1,802,732           226,317  14.36%   x 0.87 
 context_new_and_query_location_slice        607,612         610,777               3,165   0.52%   x 0.99 
 context_new_and_query_with_functions_rc     1,732,377       1,784,938            52,561   3.03%   x 0.97 
 context_new_and_query_with_functions_slice  759,694         762,421               2,727   0.36%   x 1.00 
 context_new_parse_functions_rc              9,991,413       10,133,597          142,184   1.42%   x 0.99 
 context_new_parse_functions_slice           9,150,412       9,214,042            63,630   0.70%   x 0.99 
 context_new_parse_inlined_functions_rc      33,198,829      39,720,621        6,521,792  19.64%   x 0.84 
 context_new_parse_inlined_functions_slice   28,527,872      33,520,880        4,993,008  17.50%   x 0.85 
 context_new_parse_lines_rc                  6,731,890       6,812,627            80,737   1.20%   x 0.99 
 context_new_parse_lines_slice               4,934,562       5,022,465            87,903   1.78%   x 0.98 
 context_new_rc                              1,475,518       1,465,765            -9,753  -0.66%   x 1.01 
 context_new_slice                           539,449         506,929             -32,520  -6.03%   x 1.06 
 context_query_location_rc                   1,114,929       1,115,536               607   0.05%   x 1.00 
 context_query_location_slice                1,158,963       1,178,368            19,405   1.67%   x 0.98 
 context_query_with_functions_rc             2,593,325       2,809,019           215,694   8.32%   x 0.92 
 context_query_with_functions_slice          2,486,511       2,550,311            63,800   2.57%   x 0.97 

[bjorn3]

The project I needed this for is no longer being worked on, so I don't need this anymore myself. Maybe others still have a use case for it?

The linkage name is missing the type parameters.

-Csymbol-mangling-version=v0 solves this problem by including them in the mangled symbol name.

[mstange]

I haven't gotten any reports asking for adding the argument types. I've asked a few people who use samply to profile Rust code and the sentiment was along the lines of: "Having the arguments would be nice, I suppose, but I haven't noticed their absence"