Bug 19930 - @cast headers should allow other languages
Summary: @cast headers should allow other languages
Status: NEW
Alias: None
Product: systemtap
Classification: Unclassified
Component: translator (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-04-08 20:42 UTC by Josh Stone
Modified: 2016-04-08 20:42 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Josh Stone 2016-04-08 20:42:07 UTC
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")