This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug translator/19930] New: @cast headers should allow other languages
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Fri, 08 Apr 2016 20:42:07 +0000
- Subject: [Bug translator/19930] New: @cast headers should allow other languages
- Auto-submitted: auto-generated
https://sourceware.org/bugzilla/show_bug.cgi?id=19930
Bug ID: 19930
Summary: @cast headers should allow other languages
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: translator
Assignee: systemtap at sourceware dot org
Reporter: jistone at redhat dot com
Target Milestone: ---
Currently, with @cast(ptr,"type","<header>") we go into make_typequery_umod and
build it like:
gcc -shared -g -fno-eliminate-unused-debug-types -xc /dev/null \
-o name -include header
In particular, that "-xc" leads it to be interpreted as C only.
Conceptually, it ought to be fine for us to support C++ headers too. Perhaps
the cast could allow something like "c<header>" and "c++<header>", where the
latter will now map to "-xc++".
I'm not sure if any other languages could work like this, but we should remain
open to the possibility.
We may also need to let the user specify arbitrary options somehow, e.g. for
things like "-std=c++11". Dialect alone could be mapped "c++11<header>", but I
imagine many other options might be useful too. @cast lines may start to get
unwieldy, but macros can alleviate some repetition.
PS- as a workaround, it should already be possible for users to compile an
object however they need, then @cast(ptr,"type","/path/to/object")
--
You are receiving this mail because:
You are the assignee for the bug.