public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
From: Alexandre Oliva <oliva@lsd.ic.unicamp.br>
To: "Gui\,Jian" <guij@cn.ibm.com>, jakub@redhat.com
Cc: Roland McGrath <roland@redhat.com>,
	systemtap@sources.redhat.com,
	        "Frank Ch. Eigler" <fche@redhat.com>
Subject: Re: "no match" semantic error for some existing probe points
Date: Tue, 07 Nov 2006 07:52:00 -0000	[thread overview]
Message-ID: <or7iy7zrv1.fsf@lsd.ic.unicamp.br> (raw)
In-Reply-To: <45486C15.907@cn.ltcfwd.linux.ibm.com> (Jian Gui's message of "Wed\, 01 Nov 2006 17\:42\:45 +0800")

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

On Nov  1, 2006, "Gui,Jian" <guij@cn.ibm.com> wrote:

> Alexandre Oliva wrote:
>> Indeed, but this is an inlined call of ptrace_disabled.  What we're
>> missing is info about the clear_single_step() inlined call.  However,
>> in my kernel source tree, clear_single_step is a macro, not a
>> function, so you won't get debug info for it without -g3 and, even
>> then, you may not get any line numbers whatsoever for the function
>> that does nothing but call a macro.
> In 2.6.18.1, clear_single_step is defined as an inlined call in
> arch/powerpc/kernel/ptrace.c (ppc64) or
> arch/powerpc/kernel/ptrace.c (ppc32). Although it is also defined
> as macro in arch/powerpc/kernel/traps.c, I think ptrace_disable is
> using its inlined call definition.

> Thanks. I've opened bug 3441 for this and attached some data.
> http://sourceware.org/bugzilla/show_bug.cgi?id=3441

> Please let me know if more info is needed.

Thanks, I've located the problem.  I missed a hunk when backporting
the patch that was meant to add this debug info; one of the hunks in
the original patch translated to two identical changes elsewhere, and
the second hunk in the same file had to be applied to a completely
different piece of code that I didn't recognize back then.  As a
result, we ended up without the desired info in many cases.  The patch
below is a fix, that brings in the last hunk in the patch to
tree-inline.c in the GCC trunk that generated revision 102379.

Jakub, do you want a patch for the patch file, or is this good enough?
I guess we need a bug report in Red Hat's bugzilla to get a fix into
some RHEL 4 update, right?

Gui,Jian, do you want to file the bug report at
bugzilla.redhat.com/bugzilla yourself, to keep track of it, or would
you like us to take care of it?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gcc34-dwarf2-inline-details-fix.patch --]
[-- Type: text/x-patch, Size: 1229 bytes --]

This patch fixes a change that went missing in the
gcc34-dwarf2-inline-details.patch backport.

for gcc/ChangeLog
2006-11-07  Alexandre Oliva  <aoliva@redhat.com>

	* tree-inline.c (expand_call_inline): Set BLOCK_SOURCE_LOCATION.

Index: gcc/tree-inline.c
===================================================================
--- gcc/tree-inline.c.orig	2006-10-13 04:31:24.000000000 -0300
+++ gcc/tree-inline.c	2006-11-07 04:06:10.000000000 -0200
@@ -1253,6 +1253,7 @@ expand_call_inline (tree *tp, int *walk_
   tree args;
   tree return_slot_addr;
   const char *reason;
+  location_t incoming_loc = input_location;
 
   /* See what we've got.  */
   id = (inline_data *) data;
@@ -1464,7 +1465,10 @@ expand_call_inline (tree *tp, int *walk_
   /* Tell the debugging backends that this block represents the
      outermost scope of the inlined function.  */
   if (SCOPE_STMT_BLOCK (scope_stmt))
-    BLOCK_ABSTRACT_ORIGIN (SCOPE_STMT_BLOCK (scope_stmt)) = DECL_ORIGIN (fn);
+    {
+      BLOCK_ABSTRACT_ORIGIN (SCOPE_STMT_BLOCK (scope_stmt)) = DECL_ORIGIN (fn);
+      BLOCK_SOURCE_LOCATION (SCOPE_STMT_BLOCK (scope_stmt)) = incoming_loc;
+    }
 
   /* Declare the return variable for the function.  */
   COMPOUND_BODY (stmt)

[-- Attachment #3: Type: text/plain, Size: 249 bytes --]


-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

  reply	other threads:[~2006-11-07  6:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-17 10:17 Gui,Jian
2006-10-17 20:55 ` Frank Ch. Eigler
2006-10-18  4:00   ` Gui,Jian
2006-10-19  7:40     ` Gui,Jian
2006-10-24 17:58       ` Roland McGrath
2006-10-30  6:12         ` Gui,Jian
2006-10-30 22:07           ` Roland McGrath
2006-11-01  7:03             ` Alexandre Oliva
2006-11-01 12:32               ` Gui,Jian
2006-11-07  7:52                 ` Alexandre Oliva [this message]
2006-11-07 14:34                   ` Gui,Jian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=or7iy7zrv1.fsf@lsd.ic.unicamp.br \
    --to=oliva@lsd.ic.unicamp.br \
    --cc=fche@redhat.com \
    --cc=guij@cn.ibm.com \
    --cc=jakub@redhat.com \
    --cc=roland@redhat.com \
    --cc=systemtap@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).