which elf symbol?

which elf symbol?

[Andrew Cagney]

Hi,

I've replaced the frysk-stackframe program with an expanded 
frysk-symbols program that has more elf symbol lookup edge cases; for 
instance nested symbols.  I've also expanded frysk.rt.TestSymbol to 
exercise them.  For some of the cases though, the results are not what I 
expected.   I've noted the failures below and provided a simplified 
assembler.

1) 
testGlobalAfterNested(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: 
symbol global_outer expected:<global_outer> but was:<local_st_size_0>
   at frysk.rt.TestSymbol.symbolTest(TestRunner)
   at frysk.rt.TestSymbol.testGlobalAfterNested(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)
2) 
testLocalAfterNested(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: 
symbol local_outer expected:<...outer> but was:<...st_size_0>
   at frysk.rt.TestSymbol.symbolTest(TestRunner)
   at frysk.rt.TestSymbol.testLocalAfterNested(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)

These two are effectively the same.  The layout is:

    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 :-(


3) 
testNoSymbolAfterGlobal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: 
symbol [unknown] expected:<[unknown]> but was:<local_st_size_0>
   at frysk.rt.TestSymbol.symbolTest(TestRunner)
   at frysk.rt.TestSymbol.testNoSymbolAfterGlobal(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)
4) 
testNoSymbolAfterLocal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: 
symbol [unknown] expected:<[unknown]> but was:<local_st_size_0>
   at frysk.rt.TestSymbol.symbolTest(TestRunner)
   at frysk.rt.TestSymbol.testNoSymbolAfterLocal(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)

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.

5) 
testGlobalSize0InGlobal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: 
symbol global_0_in_global expected:<...0_in_global> but was:<...after_0>
   at frysk.rt.TestSymbol.symbolTest(TestRunner)
   at frysk.rt.TestSymbol.testGlobalSize0InGlobal(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)
6) 
testLocalSize0InGlobal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: 
symbol local_0_in_global expected:<local_0_in_global> but 
was:<global_after_0>
   at frysk.rt.TestSymbol.symbolTest(TestRunner)
   at frysk.rt.TestSymbol.testLocalSize0InGlobal(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)
7) 
testGlobalSize0InLocal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: 
symbol global_0_in_local expected:<global_0_in_local> but 
was:<local_after_0>
   at frysk.rt.TestSymbol.symbolTest(TestRunner)
   at frysk.rt.TestSymbol.testGlobalSize0InLocal(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)
8) 
testLocalSize0InLocal(frysk.rt.TestSymbol)junit.framework.ComparisonFailure: 
symbol local_0_in_local expected:<...0_in_local> but was:<...after_0>
   at frysk.rt.TestSymbol.symbolTest(TestRunner)
   at frysk.rt.TestSymbol.testLocalSize0InLocal(TestRunner)
   at frysk.junit.Runner.runCases(TestRunner)
   at frysk.junit.Runner.runArchCases(TestRunner)
   at frysk.junit.Runner.runTestCases(TestRunner)
   at TestRunner.main(TestRunner)

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.

Re: which elf symbol?

[Roland McGrath]

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.

		.globl t1_global_outer

	t1_local_st_size_0:

	t1_global_outer:
		nop
	t1_local_in_global:
		nop
	.size t1_local_in_global, .-t1_local_in_global
	1:	nop
	      .size t1_global_outer, .-t1_global_outer

	.space 100
	.balign 8

		.globl t2_global_symbol

	t2_local_st_size_0:

	t2_global_symbol:
	      nop
	      nop
	.size t2_global_symbol, .-t2_global_symbol
	2:

	.space 100
	.balign 8

		.globl t3_global_after_0

	t3_global_after_0:
		nop
	t3_local_0_in_global:
	3:
	      nop
	      .size t3_global_after_0, .-t3_global_after_0

	.data
	t1_pc_of_interest: .long 1b
	t2_pc_of_interest: .long 2b
	t3_pc_of_interest: .long 3b

as on that produces the following (readelf -rs; objdump -d).  The reloc
addends tell you the "pc_of_interest" values.  On i386 (non-rela), you'd
need to look at objdump -s -j .data instead to see them.

	Relocation section '.rela.data' at offset 0x560 contains 3 entries:
	  Offset          Info           Type           Sym. Value    Sym. Name + Addend
	000000000000  00010000000a R_X86_64_32       0000000000000000 .text + 2
	000000000004  00010000000a R_X86_64_32       0000000000000000 .text + 6a
	000000000008  00010000000a R_X86_64_32       0000000000000000 .text + d1

	Symbol table '.symtab' contains 14 entries:
	   Num:    Value          Size Type    Bind   Vis      Ndx Name
	     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
	     1: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
	     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 
	     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 
	     4: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    1 t1_local_st_size_0
	     5: 0000000000000001     1 NOTYPE  LOCAL  DEFAULT    1 t1_local_in_global
	     6: 0000000000000068     0 NOTYPE  LOCAL  DEFAULT    1 t2_local_st_size_0
	     7: 00000000000000d1     0 NOTYPE  LOCAL  DEFAULT    1 t3_local_0_in_global
	     8: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    2 t1_pc_of_interest
	     9: 0000000000000004     0 NOTYPE  LOCAL  DEFAULT    2 t2_pc_of_interest
	    10: 0000000000000008     0 NOTYPE  LOCAL  DEFAULT    2 t3_pc_of_interest
	    11: 0000000000000000     3 NOTYPE  GLOBAL DEFAULT    1 t1_global_outer
	    12: 0000000000000068     2 NOTYPE  GLOBAL DEFAULT    1 t2_global_symbol
	    13: 00000000000000d0     2 NOTYPE  GLOBAL DEFAULT    1 t3_global_after_0

	addrsym-test.o:     file format elf64-x86-64

	Disassembly of section .text:

	0000000000000000 <t1_global_outer>:
	   0:	90                   	nop    

	0000000000000001 <t1_local_in_global>:
	   1:	90                   	nop    
	   2:	90                   	nop    
		...
	  67:	90                   	nop    

	0000000000000068 <t2_global_symbol>:
	  68:	90                   	nop    
	  69:	90                   	nop    
		...
	  ce:	66 90                	xchg   %ax,%ax

	00000000000000d0 <t3_global_after_0>:
	  d0:	90                   	nop    

	00000000000000d1 <t3_local_0_in_global>:
	  d1:	90                   	nop    

It's possible the order of symbols in the table is an issue.  So let me
know if those are different in your case.  

>     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.

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?

> 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.

> 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.   */

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.  


Thanks,
Roland

Re: which elf symbol?

[Andrew Cagney]

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
>   

Re: which elf symbol?

[Roland McGrath]

> 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.

Agreed.  I think the correct answer for 1: here is no symbol.
Below, this is case t4.

> Yes, agreed.  The sized symbol should trump the unsized one.

Based on what you've said I'm now looking at the following test cases.
For me, the current code gets all of these right except t4.  I had the
impression you had other cases where the current code yields the wrong
answer.  Please send me an assembly fragment in this style (e.g. t5, t6)
on which you've verified addrsym yields the wrong answer, or let me know
if cases like t4 are in fact the only specific known bug.  I'd like to
get these test cases firmly established ASAP, and before considering
additional facilities with different behavior as for disassembly.


Thanks,
Roland



	.globl t1_global_outer

t1_local_st_size_0:

t1_global_outer:
	nop
t1_local_in_global:
	nop
.size t1_local_in_global, .-t1_local_in_global
1:	nop	# the right answer is t1_global_outer
.size t1_global_outer, .-t1_global_outer

.space 0x100
.balign 8

	.globl t2_global_symbol

t2_local_st_size_0:

t2_global_symbol:
	nop
	nop
2: # the right answer is t2_global_symbol
	nop
.size t2_global_symbol, .-t2_global_symbol

.space 0x100
.balign 8

	.globl t3_global_after_0

t3_global_after_0:
	nop
t3_local_0_in_global:
3: # the right answer is t3_global_after_0
      nop
.size t3_global_after_0, .-t3_global_after_0

.space 0x100
.balign 8

	.globl t4_global

t4_global:
	nop
t4_local_0_in_global:
	nop
.size t4_global, .-t4_global
4: 	nop	# the right answer is no answer
	nop

.data
t1_pc_of_interest: .long 1b
t2_pc_of_interest: .long 2b
t3_pc_of_interest: .long 3b
t4_pc_of_interest: .long 4b