On Mon, Oct 31, 2011 at 11:03:42AM -0700, Roland McGrath wrote:
I'm not entirely sure about having this as a new public
might make more sense to return the Elf_Scn of the symtab or something like
that. My inclination is to start out by only using the information
internally, and think about a public interface for it later when there is
actual demand for that.
The patch started out with just that dwfl_module_symtab_global function,
to make a more efficient version of dwfl_module_addrsym that searched
the globals first. Then I realized I should just make dwfl_module_addrsym
be more efficient itself.
I only wanted to expose the index where the globals started (if known)
since that is all you need to use it together with dwfl_module_getsymtab
and dwfl_module_getsym. The symbols don't actually have to come from an
actual Elf_Scn, they could come from the dynamic symbol table via phdrs.
I removed the public interface for now and just access the field directly
in dwfl_module_addrsym. Any preference on a public interface?
I think "symglobals" is an unnatural name for fields and
this. It looks like a count, and what it's the count of is the locals.
So something like "nlocals" or "first_global" makes more sense to me.
first_global does sound better. I changed it in the attached patch.
OK, to commit this version for now, while we discuss whether or not
and how the public interface should look?