This is the mail archive of the mailing list for the systemtap 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 v3 1/2] systemtap/tapsets.cxx: Adjusted for multiple static functions

On 04/08/2015 09:19 PM, Frank Ch. Eigler wrote:
mjw wrote:

    // TODO: Use a multimap in case there are multiple static
    // functions with the same name?
    map_by_addr.insert(make_pair(addr, fi));
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 insertion.

+          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.)

- FChE

Hemant Kumar

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