On 04/22/2016 12:56 AM, Adrian Hunter wrote:
The call_paths table already has symbol_id which belongs uniquely to a DSO,If the symbol_id is 0 because the IP could not be resolved to a symbol, this is not necessarily a valid assumption. Without a dso_id in the call_paths table, it is not possible to resolve the dso when symbol information is missing. the db_export api currently does not have enough information to match a DSO with an IP.
so why do we need dso_id as well?
It is often useful to still have the call path associated with a DSO even if there is no symbol, which i why i recommend keeping the dso_id in the call_paths table.Why do you need a callback? Seems like the only thing you need fromMy original intent was to reuse existing code with minimal changes and conform the existing design patterns they used. Thread-stack.c, for example, currently uses a callback to populate the call_return table, so I used a callback as well to populate the call_path table.
thread-stack.c is the call path tree. You could move that to its own .c/.h
files and then process the call chain in db-export.c
I am open to making this change if it is believed it will result in a cleaner implementation.While i can split this into a few smaller patches there is only really justification for applying all of them all together. If this is still preferred i can resubmit this in smaller parts.
Also a list of changes like the one above heavily implies you are not
obeying the one patch == one change rule. Please try to make patches that
only do one thing and also run checkpatch.
Let me know if you have any additional comments.
If you don't mind, I'll let you respond to my comments before I comment on
any other patches.
Thanks,
Chris