On Tue, 06 Nov 2012 18:50:27 +0100, Mark Wielaard wrote:
On Tue, Nov 06, 2012 at 03:32:11PM +0100, Martin Milata wrote:
How standardized is this? Is it just for Fedora or do other distros
also use it? Is the support in GDB and RPM upstream or only in the
Fedora packages? Can it be seen as a standard GNU extension?
Not yet in GDB upstream, Tom Tromey AFAIK plans to upstream it.
Do you have this implemented this way already? If so could you
I am aware of:
If there is no symtab/strtab available I guess this could be used
as fallback for dwfl_module_getsymtab()/dwfl_module_getsym(). It would
probably be a good idea if there was some way to find out if the
data comes from a real symtab or from this minisymtab, since if it
comes from the minisymtab it will be incomplete.
This is the problem. elfutils is used to report just one symtab, it is OK now
as if .symtab exists it supersedes .dynsym. But .gnu_debugdata does not,
it needs to be combined together with .dynsym to get the "complete" symtab.
It seems to be as the same problem I was solving with the additional ppc64
symbols resolved from .opd (ppc64 function descriptors):
As the .opd symbols are IMO mostly needed just for an addr->symname mapping
I have just patched dwfl_module_addrsym. I find this .gnu_debugdata use case
to be exactly the same, most use cases are fine just with patched
dwfl_module_addrsym, which is easy to do with its existing API.
Roland apparently does not agree with it as my .opd has not yet been approved.