Re: which elf symbol?

[Andrew Cagney <cagney@redhat.com>]

Roland McGrath wrote:
> I reduced your report to an isolated test case of trivial assembly.  I've
> slightly modified addr2line so I'm using it as a test program with -e on
> the .o file to just print out the results of dwfl_module_addrsym.
> Please help me adjust this test case to match (or also include) cases
> equivalent to what you are seeing.
>   

What about a case like:

symbol:
nop
unsized_symbol:
nop
.size symbol, .-symbol
1: <should not have a symbol?>

the closest symbol is unsized_symbol, but that is probably not the intent.

>   
>>     local_st_size_0: // this symbol has no size
>>
>>     global_outer:
>>         nop
>>         local_in_global:
>>           nop
>>           .size local_in_global, .-local_in_global
>>        nop
>>        <<you-are-here>>
>>        .size global_outer, .-global_outer
>>
>> that is global_outer contains a nested symbol but the "pc" is beyond 
>> that back in the outer/global symbol.
>>
>> I'm guessing that "global_outer" should be returned.  Currently 
>> local_st_size_0 is returned :-(
>>     
>
> Arguably the answer should be no symbol, since the address is past the end
> of the nearest symbol's size.
>   
the xample was unclear <<you-are-here>> is ment to be within 
global_outer; your test did that.
> This is t1 in my test case, looking at pc=0x2.  I get t1_global_outer+0x2
> from addrsym here, so my case must differ from what you tried here.
> Can you figure out how they differ?
>
>   

I'm looking.

>> This is the no-symbol case, there is a hole in the memory where there is 
>> no valid symbol vis:
>>
>>     local_st_size_0: // this symbol has no size
>>
>>     global_symbol:
>>        nop
>>        nop
>>        .size global_symbol, .-global_symbol
>>
>>     << you are here >>
>>
>> I'm guessing it should not get a symbol at all (the [unknown]).  It 
>> currently gets the nearest unsized symbol.
>>     
>
> This is t2 in my test case, looking at pc=0x6a.  
> I get t2_local_st_size_0+0x2 here.  Go figure.
>
> You wrote your marker in a different place, but there is no address
> difference between the context before the .size directive in the assembly
> source and the context after it.  So unless I'm misunderstanding what cases
> you intended to describe, this should be the same case as t1.  (It doesn't
> really matter that there is a local symbol nearby, since the PC of interest
> is unambiguous outside that symbol's address range.)
>
> I'll look into why they come out differently, which might relate to some
> other symptom.  I also agree that the right answer is no symbol.
>
>   
ok.

>> These are cases where there is a nested symbol within a sized symbol vis:
>>
>>     global_after_0:
>>        nop
>>        local_0_in_global:
>>           << you are here >>
>>        nop
>>        .size global_after_0, .-global_after_0
>>
>> here, since the PC is exactly at the unsized local symbol I'm guessing 
>> that it should return that.  It currently gets the containing sized symbol.
>>     
>
> This is my t3.  I get t3_global_after_0+0x1 as you say.  This is the
> intended behavior, not a bug.  We can discuss what the behavior should be.  
>
> 	  /* Handwritten assembly symbols sometimes have no st_size.
> 	     If no symbol with proper size includes the address, we'll
> 	     use the closest one that is in the same section as ADDR.   */
>
>   
Yes, agreed.  The sized symbol should trump the unsized one.

> Usually size-0 symbols are local assembler labels, and sized symbols are
> the entry points.  For things like backtraces, people usually want to see
> the symbol names for the entry points (plus offsets) rather than the local
> labels that often have unhelpful names.  That's what I had in mind when I
> wrote that.  addrsym started out as addrname, which does not pass back an
> offset and only used for "what function is this in?" kinds of queries.  For
> that, it clearly makes more sense to prefer the containing sized symbol.
>
> However, for things like disassembly, people probably would like to see the
> local label names, or perhaps both names.  
>
>   
That's an interesting option; it would better reflect exactly what is in 
the file.

Andrew

> Thanks,
> Roland
>