Matthias Klose <d...@debian.org> writes: [...] > If you really are too lazy to have architecture specific build > dependencies, then consider shipping an empty package for the > unsupported architectures.
Um, that was actually meant as a convenience for *you* (and anyone else who works on a package that wants to provide SDT probes) more than for me: since <sys/sdt.h> really is meant to work *EVERYWHERE* [1], the proper way to handle architectures where systemtap's <sys/sdt.h> currently fails because of oddities in their assembly syntax is to conditionalize the definitions of the macros that use the problematic syntax, adding variants that *do* work with their assembly syntax. [1]: https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation If you're incredulous at the idea that this one header is supposed to support probes on EVERY architecture, consider that a probe consists of * probe PC address (address size) * link-time sh_addr of .stapsdt.base section (address size) * link-time address of the semaphore variable (address size). This is zero if the probe does not have an associated semaphore; in this case no .stapsdt.base adjustment should be done * provider name (null-terminated string) * probe name (null-terminated string) * argument format (null-terminated string) There's already one conditional for __powerpc__ & __powerpc64__ to deal with the fact that register numbers there look exactly like constants, and another for ISAs where nop takes an argument (namely, __ia64__, __s390__, & __s390x__); it doesn't seem likely that it will be particularly difficult to deal with any other oddities. If worst came to worst, we could simply gut the whole thing on architectures with really strange assembly syntax, so that it doesn't emit so much as a NOP.
However, all of this depends on knowing which architectures don't work, so for the Nth time: which architectures is <sys/sdt.h> buggy on?
-- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
