This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patchv4 4/4] Provide virtual symbols for ppc64 function descriptors

Hi Jan,

On Mon, 2013-12-09 at 20:20 +0100, Jan Kratochvil wrote:
> On Wed, 04 Dec 2013 20:02:33 +0100, Mark Wielaard wrote:
> > No, I suggest just NOT adding extra names, dot mangled, or not. But just
> > keep the function symbol names as is. Just resolve the values (which we
> > already adjust anyway so they map into Dwfl address space) without any
> > extra magic.
> I have found only addr2line as a common binutils<->elfutils application
> affected by such change.
> Other elfutils utilities (such as eu-readelf or eu-nm) use directly libelf.

I think you are arguing on the wrong level. If we want different output
or functionality of the utilities we can change them. They don't have to
map one-on-one to the underlying libdwfl interfaces. They are allowed to
use them creatively :)

> There is moreover the confusion that dwfl_module_getsym looks like returning
> an ELF symbol table including the first null entry but such returned data no
> longer have ELF symbol table semantics.  But that cannot be changed due to
> API/ABI compatibility.

It tries to mimic a symbol table with some of the same properties yes.
We are now stuck with it because it looks like people depend on the
current API. Which is why I changed my patch to introduce a different
API, which we can tweak a bit to be more "natural" if you like.

> binutils additionally provides also bfd_get_synthetic_symtab which contains
> the '.entry' addresses.  This was provided in my patch but it is no longer
> provided in your patch.  This way GDB can display:
> (gdb) info sym 0x0000000010000504
> .func2 in section .text
> (gdb) info sym 0x0000000010010a40
> func2 in section .opd

Again I think you are arguing on the wrong level. This isn't about how
gdb (or binutils) implements this. It is about providing an interface
for libdwl.

> But having this functionality together with your patch address "corruption"
> does not seem to be possible with the current elfutils API.  There would be
> clashing two symbol names for the same address etc.

Yes, I think this confuses symbols with their names and it confuses
symbol values with the addresses they might represent. I think the
current interface doesn't really allow us to mix those concepts (at
least it doesn't seem so because of backward compatibility concerns).

But now that we do have to provide a new API anyway, we could make a
lookup for an address match against either or both of the values or
addresses. Currently I haven't done that, but we could make
dwfl_module_addrinfo (mod, addr, off, sym) match on either the
(adjusted) st_value and on the resolved address for the symbol.

> > As I said before I don't think the ABI for object file link editor
> > really matters much in the case of the libdwfl interfaces. The don't
> > need extra real synthetic ELF symbols.
> The functionality of GDB cannot be achieved with elfutils and your patch.

But that isn't a valid argument against what I said. It cannot be
achieved with my patch alone, but that doesn't mean we cannot introduce
new functionality too. And I do think that with my new patch that
introduces new functions you can achieve it (see the dwflsym test that
has been expanded to show both).

> > If dot-prefixed symbols are
> > present as in ET_REL files just leave them alone (kernel modules are
> > special anyway). But adding lots of additional synthetic symbols to the
> > dwfl_module_*sym* calls where they didn't exist before really is not the
> > way to go. We really need something simpler.
> binutils does it and thanks to it binutils provides better functionality as it
> can resolve addr->sym both addresses, as shown by GDB.

sigh. Really, elfutils isn't binutils. We can and do use different
design principles. In this case it is we don't overload this function to
do lots of extra "synthetic stuff" just because binutils does it that

> > What we have are functions that match function symbol names and values
> > to/from the Dwfl_Module address space layout. For that we already adjust
> > the values as found in the ELF files. All we need to do is resolve any
> > function descriptor entry values. We don't need to introduce an extra
> > synthetic symbol table for that.
> By not introducing the extra synthetic symbol table you can no longer resolve
> function descriptor addresses to names.

That is true. And introducing a new function to do that is probably the
way to go.

> I still do not agree with the patch as it provides worse functionality than
> the patch of mine without any benefit.  But as it does not seem possible to
> convince you to get the better functionality than binutils has I no longer
> want to block this patch.

Of course I can be convinced. And the benefit is not having to construct
and carry around a large synthetic symbol table by using simple
filtering of the values making the code IMHO simpler.

You are not always arguing your case very well by mixing your arguments
by how other projects or tools implement something or by referring to
outside "authorities". Please don't confuse a disagreement on
implementation details, or what which function should do, with a
disagreement about functionality. Take a look at my new patch and see if
that looks better to you.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]