From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9898 invoked by alias); 19 Oct 2010 22:10:57 -0000 Received: (qmail 9831 invoked by uid 9586); 19 Oct 2010 22:10:56 -0000 Date: Tue, 19 Oct 2010 22:10:00 -0000 Message-ID: <20101019221056.9820.qmail@sourceware.org> From: jistone@sourceware.org To: systemtap-cvs@sourceware.org Subject: [SCM] systemtap: system-wide probe/trace tool branch, master, updated. release-1.3-209-ga44a7cb X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: fcf90fdda6288808a189ff9be219cc995e2de2d8 X-Git-Newrev: a44a7cb5534b2f7db818629d3d485b67ad5f33af Mailing-List: contact systemtap-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-cvs-owner@sourceware.org List-Archive: Reply-To: systemtap@sourceware.org X-SW-Source: 2010-q4/txt/msg00028.txt.bz2 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "systemtap: system-wide probe/trace tool". The branch, master has been updated via a44a7cb5534b2f7db818629d3d485b67ad5f33af (commit) from fcf90fdda6288808a189ff9be219cc995e2de2d8 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit a44a7cb5534b2f7db818629d3d485b67ad5f33af Author: Josh Stone Date: Tue Oct 19 12:20:24 2010 -0700 PR12121: distinguish struct/typedef homonyms For example: typedef struct foo foo; foo x; This kind of "repeated" typedef used to cause bad things for us if the struct definition is not in the current CU. When resolving $x->bar, we start at the typedef-foo and dereference to the struct-foo. That's just a declaration, so we use declaration_resolve to look for the struct definition. But since we were looking by the name "foo" only, we would find the typedef again, getting us nowhere. The fixed code does declaration_resolve on "struct foo" in the global cache, so in this case we won't find anything locally, and thus we continue looking in other CUs. If the definition isn't found elsewhere, we're stuck anyway. * dwflpp.cxx (dwflpp::global_alias_caching_callback): Cache type names with a relevant prefix: struct, union, etc. Classes are normalized to be "struct" too, as that's a very blurry line. (dwflpp::declaration_resolve(die)): New variant to resolve a specific die -- used so we know what exact prefix we should look for. * parse.cxx (parser::parse_target_symbol): Don't strip the prefix from @cast types anymore, so the user can be precise about what they want. * tapsets.cxx (dwarf_cast_query::handle_query_module): Normalize "class" to "struct". If the user provides a bare name that fails to resolve, then try it again with the various prefixes. * testsuite/systemtap.base/unresolved-struct-typedef.*: New test. ----------------------------------------------------------------------- Summary of changes: dwflpp.cxx | 46 ++++++++++++++----- dwflpp.h | 5 +- parse.cxx | 6 --- tapsets.cxx | 30 ++++++++++++- .../systemtap.base/unresolved-struct-typedef.c | 26 +++++++++++ .../systemtap.base/unresolved-struct-typedef.exp | 26 +++++++++++ 6 files changed, 117 insertions(+), 22 deletions(-) create mode 100644 testsuite/systemtap.base/unresolved-struct-typedef.c create mode 100644 testsuite/systemtap.base/unresolved-struct-typedef.exp hooks/post-receive -- systemtap: system-wide probe/trace tool