This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: add systemtap-style marker to _Unwind_DebugHook


>>>>> "Roland" == Roland McGrath <roland@redhat.com> writes:

Roland> As was mentioned, systemtap's sys/sdt.h has wrapper macros that
Roland> are source-compatible with dtrace's sys/sdt.h that you can use
Roland> without any material difference.

stap's are better because you can use them with a .d file and a new .o
file to define a semaphore variable; what I have read on the web
suggests that Solaris (but not some other DTrace ports) requires this
stuff.  This matters to GCC because it lets us avoid dealing with cross
compilation stuff.

Roland> In versions of systemtap prior to the forthcoming 1.4, the
Roland> probes produced some undesireable overhead in PIC code, in the
Roland> form of some extra dynamic relocation records in the resultant
Roland> DSO, adding to the startup cost in the dynamic linker.  This
Roland> added startup cost might be judged unacceptable for the shared
Roland> libgcc.so, since in practice it's paid by every process in the
Roland> system in its initialization.  So you might want either to make
Roland> compiling in the probe conditional on a configure option, or to
Roland> use an autoconf test that would only accept the most recent
Roland> versions of sys/sdt.h (and perhaps also accept dtrace's
Roland> versions, if you are going to support dtrace too).

I think gcc's configure has too many options already.

What if I check `_SDT_NOTE_TYPE >= 3'?
I'd rather sdt.h advertise its version than try to write a configure
check.  Testing target headers in gcc is a pain.

Tom


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]