This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v4 1/3] systemtap/tapsets.cxx: Fix dwarfless probes on multiple static functions
- From: Mark Wielaard <mjw at redhat dot com>
- To: Hemant Kumar <hemant at linux dot vnet dot ibm dot com>
- Cc: systemtap at sourceware dot org, naveen dot n dot rao at linux dot vnet dot ibm dot com, ulrich dot weigand at de dot ibm dot com, uweigand at gcc dot gnu dot org, anton at samba dot org, fche at redhat dot com
- Date: Wed, 22 Apr 2015 15:40:17 +0200
- Subject: Re: [PATCH v4 1/3] systemtap/tapsets.cxx: Fix dwarfless probes on multiple static functions
- Authentication-results: sourceware.org; auth=none
- References: <1429525764-23471-1-git-send-email-hemant at linux dot vnet dot ibm dot com>
Hi Hemant,
On Mon, 2015-04-20 at 15:59 +0530, Hemant Kumar wrote:
> With multiple static functions with same names in an ELF and in absence
> of dwarf, if we probe on one of the functions, then systemtap places
> probe only on one static function ignoring the rest. This is because the
> mapping between the symbol names and their func_info is a simple map
> which doesn't allow insertion of another symbol with the same name.
>
> This patch fixes this issue by changing this map to a multimap which
> allows duplicate entries for the same symbol name. lookup_symbol code
> will return a set of func_info * instead of a single descriptor for a
> function name.
>
> We also need to fix other areas in the code where lookup_symbol() and
> lookup_symbol_address() are being called so as to look for a set of
> func_info's and a list of Dwarf_Addr's respectively, instead of a single
> descriptor.
Looks good. I pushed this with one tiny change:
@@ -8242,6 +8242,8 @@ symbol_table::purge_syscall_stubs()
if (!addrs || addrs->empty())
return;
/* Highly unlikely that multiple symbols named "sys_ni_syscall" may exist */
+ if (addrs->size() > 1)
+ cerr << _("Multiple 'sys_ni_syscall' symbols found.");
Dwarf_Addr stub_addr = addrs->front();
Just so that if this highly unlikely scenario does occur we get a
warning something is fishy.
Thanks,
Mark