Re: [patch] Resolve ppc64 func descriptors as .func (via .opd)

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Tue, 11 Dec 2012 10:15:47 +0100, Mark Wielaard wrote:
> On Fri, 2012-12-07 at 13:39 +0100, Jan Kratochvil wrote:
> > On Thu, 06 Dec 2012 16:35:24 +0100, Mark Wielaard wrote:
> > > Like how you would use in a backtrace (it matches the
> > > "DWARF way" of doing backtraces in gdb).
> > 
> > "DWARF way" is irrelevant here.  elfutils currently do not provide any such
> > high level functionality of decoding DWARF.  Let's keep talking about ELF.
> 
> libdwfl provides both. I was just pointing out that in this case,
> associating addresses to code names even on ppc64 are done without any
> dot prefixing.

I was asking to postpone the naming question to a second round of discussion.
I would like to leave the decision on IBM.


> So, it currently doesn't work on architectures that have st_value point
> into a indirection table, like odp on ppc64. Then dwfl_module_addrsym ()
> either doesn't match anything, or it matches something not really in the
> neighborhood of the requested address. Providing the backend an
> opportunity to match and set the st_value through indirection seems a
> good idea here.
> 
> > > > > but just return the data from the symbol table that
> > > > 
> > > > Why?  The caller wants more than just the data from the symbol table.
> > > 
> > > OK, then I am confused about your use case. Could you give an example of
> > > how you want to use this function?
> > 
> > ../src/addr2line -S -e testfile66 0x250
> > from jankratochvil/ppc64-opd .
> 
> Could you be a bit more specific?

I think we both agree now dwfl_module_addrsym should be extended like you
write above.  I do not think we need to discuss this more when there is no
longer a disagreement.


> > Existing callers of dwfl_module_addrsym want to get the address 0x250
> > resolved.  As it is not possible with in-file ELF symtab the returned ELF
> > symbol needs to be tweaked some way.
> 
> Could you give an example that you think isn't covered by giving the
> backend an opportunity to match and tweak st_value?

This will be solved by the backend having an opportunity to tweak st_value.
There is again no longer a disagreement to discuss.


> > Skipping this as off-topic for the first part of the discussion what should
> > dwfl_module_addrsym do except for the returned name.
> 
> OK, I don't want to see the name changed at all, so if we can resolve it
> without discussing the name change that is fine with me.

We cannot resolve the patch without discussing also the name.  But the name
discussion should be separate, I find the discussion is already complicated
enough even without the name decision.


> > When we are designing new API and from the current discussion it seems to me
> > we must not change saint dwfl_module_addrsym no matter what it does then the
> > new API can do anything we want, if you want it just for pure in-file ELF
> > symbols then even st_value must not be changed.
> 
> We are discussing just fixing dwfl_module_addrsym () so it works on all
> architectures don't we?

I agree with such solution.


> We aren't discussing designing new API again are we?

Neither of us proposes such solution but a new API is one of the
possibilities.

I think we can drop this new API question.


> > But then the new API becomes only a very simple (and primarily accelerated)
> > interface to dwfl_module_getsymtab and dwfl_module_getsym.  I do not think
> > anyone asks for that functionality, dwfl_module_getsymtab and
> > dwfl_module_getsym are fine on their own for the callers needing them.
> 
> Yes, I think dwfl_module_getsymtab () and dwfl_module_getsym () are fine
> as is since they don't do address matching on st_value. Sadly I don't
> think we can really help the user there.

Offtopic here: After one day gets possible implemented
ppc64-instruction-symbol-name (known as .funcname from BFD) ->
instruction-address mapping it may include artificial ELF symbols possibly
returned by dwfl_module_getsymtab () and dwfl_module_getsym ().

But we do not discuss it here, there would be probably a disagreement again.


> > OK, so I hope you agree now with the original patch post except the name it
> > returns.
> 
> If that implements the specification as I wrote above then we agree.
> Please post it again so we can finally review the implementation
> details.

I do not find the patch is meaningful before resolving the name issue first.


> > If we agree on that part we can move to the separate second phase of
> > discussion, about the name.
> 
> The name should just be as it is.

This is the disagreement, so goint to write down here a question to IBM ABI
authority, we can agree upon the question and send it.

One of the possibile answers from IBM sure can be also that it is outside of
the ABI spec scope and elfutils is free to choose whatever it wants to.


Thanks,
Jan