This is the mail archive of the
mailing list for the systemtap project.
Re: [PATCH v3 1/2] systemtap/tapsets.cxx: Adjusted for multiple static functions
- From: Hemant Kumar <hemant at linux dot vnet dot ibm dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>, Mark Wielaard <mjw at redhat dot com>
- Cc: Josh Stone <jistone at redhat dot com>, 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
- Date: Thu, 09 Apr 2015 21:49:18 +0530
- Subject: Re: [PATCH v3 1/2] systemtap/tapsets.cxx: Adjusted for multiple static functions
- Authentication-results: sourceware.org; auth=none
- References: <1427463736-4258-1-git-send-email-hemant at linux dot vnet dot ibm dot com> <1428500598 dot 5539 dot 88 dot camel at bordewijk dot wildebeest dot org> <y0megnud3h5 dot fsf at fche dot csb>
On 04/08/2015 09:19 PM, Frank Ch. Eigler wrote:
// TODO: Use a multimap in case there are multiple static
// functions with the same name?
But map_by_addr is already a multimap as introduced in commit 1c6b77
PR10327: resolve symbol aliases to dwarf functions by Josh. [...]
Since map_by_addr is using a multimap I was wondering if map_by_name
should also be a multimap instead of a map to a list? Do you happen to
know the advantages/disadvantages of the two datastructures?
Indeed, the new structure should be a multimap too. That means it'd
be apprx. a binary tree of (key,value) pairs (with duplication
allowed. It would be a bit more canonical, and has advantages in
cases where the list needs to be modified or traversed without
But, when I tried that this with multimap, the problem I faced is we can
insert two or more entries with same key and value, for e.g., if a
multimap already has <a,b> as an entry, we can insert multiple <a,b>
entries after that because they don't have duplication check which is
not the case with simple maps.
But yeah, this can be done with multimap with a duplication check before
+ list<func_info*> *fis = new list<func_info*>;
+ fis = sym_table->lookup_symbol(function_str_val);
Don't we need to delete the fis somewhere?
lookup_symbol should just return the list by value and let C++ handle
the memory management. (The objects pointed to by the embedded
func_info* pointers are a separate matter.)