public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug translator/6704] New: need dwarf searching to resolve extern "struct foo;" types
@ 2008-06-27 20:50 fche at redhat dot com
  2008-06-27 22:47 ` [Bug translator/6704] " fche at redhat dot com
  0 siblings, 1 reply; 2+ messages in thread
From: fche at redhat dot com @ 2008-06-27 20:50 UTC (permalink / raw)
  To: systemtap

In probe context, sometimes $context vars are typed with only
declared struct types, without a definition available in the
same CU.  We need to heuristically search other CUs for a
definition, so we can follow pointers etc.

See http://sourceware.org/ml/systemtap/2008-q2/msg00751.html
for a partial implementation.

See also bug #3016.

-- 
           Summary: need dwarf searching to resolve extern "struct foo;"
                    types
           Product: systemtap
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: translator
        AssignedTo: systemtap at sources dot redhat dot com
        ReportedBy: fche at redhat dot com


http://sourceware.org/bugzilla/show_bug.cgi?id=6704

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug translator/6704] need dwarf searching to resolve extern "struct foo;" types
  2008-06-27 20:50 [Bug translator/6704] New: need dwarf searching to resolve extern "struct foo;" types fche at redhat dot com
@ 2008-06-27 22:47 ` fche at redhat dot com
  0 siblings, 0 replies; 2+ messages in thread
From: fche at redhat dot com @ 2008-06-27 22:47 UTC (permalink / raw)
  To: systemtap


------- Additional Comments From fche at redhat dot com  2008-06-27 20:51 -------
Further discussion with James Bottomley suggests that we will
need more general facilities than mere neighbouring-CU dwarf
searches, since some separately compiled modules may handle
pointers that they don't carry any definitions for.

So, we might as well solve the general problem of explicit casting
of context variables to types defined in some arbitrary other module.
Some debuggers use a notation like 
     #module#variable
though of course we already use # (in two different ways, natch).

So the syntax could end up looking like ...
     @cast(expr, "type") -> field -> ...
and  @cast2(expr, "type", "module") -> field -> ...

incidentally making -> a first-class binary expression node.
For the case of the original bug report:

     @cast2($qc, "struct scsi_device", "kernel") -> /* ... */


*** This bug has been marked as a duplicate of 5634 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


http://sourceware.org/bugzilla/show_bug.cgi?id=6704

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-06-27 20:52 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-06-27 20:50 [Bug translator/6704] New: need dwarf searching to resolve extern "struct foo;" types fche at redhat dot com
2008-06-27 22:47 ` [Bug translator/6704] " fche at redhat dot com

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