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: [patch] Resolve ppc64 func descriptors as .func (via .opd)

On Sun, 2012-11-18 at 09:31 +0100, Jan Kratochvil wrote:
> > Is there also a symbol with the name '.main' in the table?
> No.  '.main' is only synthetic in-memory symbol generated by bfd/ .
> > > Without .opd content there is no way to resolve 0x1000115c to any symbol.
> > 
> > OK, I assume there is no symbol with '.main' in the table then.
> Right.
> > In general elfutils/libdwfl just works
> > with plain ELF symbols. There is no concept of synthetic symbols.
> This has to change; as long as ppc64 is supported.

I don't think so. It might make sense for BFD to create synthetic
symbols, but I don't think it makes sense for elfutils/libdwfl to do the
same. The information you require is just not available through the
plain ELF symbol tables directly. But we can certainly provide an
alternative for getting at the information (with architecture specific
backend hooks).

> > I was thinking you would just want to return a different name and/or
> > tweak the ELF symbol value that was returned by dwfl_module_addrsym ().
> In fact it sometimes happens, you can see:
> > # 0 0x10007fa8          __vmx__sigsetjmp_ent      | # 0 0x10007fa8          .raise
> Symbol table '.symtab' contains 1794 entries:
>    Num:    Value          Size Type    Bind   Vis      Ndx Name
>    180: 0000000010007bc4     0 NOTYPE  LOCAL  DEFAULT    4 __vmx__sigsetjmp_ent
> As __vmx__sigsetjmp_ent symbols has no size elfutils used it as a fallback when
> no other better symbol was found.
> So in some cases dot-symbols aware elfutils return different symbol name while
> former elfutils returned also some (but different) symbol.

But you are not actually interested in these none-function symbols are
you? You seem to want an interface that returns function
names/addresses. dwfl_module_addrsym () returns any ELF symbol.

> > I have to think a bit more about that. It seems that means we would
> > return some "fake" symbol results. So for an example, where we have
> > a code address (x) which value does not fall inside any of the ELF
> > symbols symbols in the module (mod) table,
> You can never say "inside any of the ELF symbols", there are symbol priorities
> libdwfl/dwfl_module_addrsym.c
>               /* Return GELF_ST_BIND as higher-is-better integer.  */
>               inline int binding_value (const GElf_Sym *symp)
> where the "better" symbols override the "worse" symbols.  When the "better"
> dot symbol is missing elfutils still can use some "worse" symbol instead.

Is the specific ordering of better/worse in dwfl_module_addrsym ()
correct for your use case? For example, do you even care about
STT_OBJECT symbols?

> > what would you expect to be
> > a) The return value
> Symbol name of the function descriptor with added leading dot.

The leading dot is weird. That is just some low-level ppc64 ABI
convention that seems confusing if what you are after is the actual
function name. That name is without the dot. It makes sense if you are
constructing some synthetic symbol that matches that ABI, but I don't
think it makes sense in this use case.

> > b) The values filled in for GElf_Sym *sym
> The function descriptor symbol with patched in value to be the code entry
> address.
> > c) The value of GElf_Word *shndxp
> Appropriately adjusted with artificial looked up content for the new symbol
> value.
> > when calling dwfl_module_addrsym (mod, x, &sym, &shndxp)?
> Exactly like what this patch returns.
> My current code uses only the return value (name) so I do not mind much about
> the other content.  I find all the other content to be valid and possibly
> needed in some cases but as I said I do not mind about the other content.

Then instead of using dwfl_module_addrsym () I would suggest a new
interface for looking up function names by address. And if you include
any ELF symbol then make it the ELF symbol from which the function was
derived. So the actual function descriptor symbol in this case. I don't
see a need to generate synthetic symbols, they don't seem to add



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