Re: SDTs with data types and argument names

["Frank Ch. Eigler" <fche at redhat dot com>]

Hi -

> > Yeah.  I believe there was a kernel-bpf-oriented group last year, who
> > were speculating extending sdt.h in a similarly motivated way.
> 
> Good to know. Any idea who may've been involved? It'd be good to
> collaborate and not duplicate work or explore a dead-end already followed.

https://web.archive.org/web/20190528152614/http://vger.kernel.org/lpc-bpf2018.html#session-11

"enhancing user defined tracepoints"

(h/t serhei) (btw, where did vger itself go???  did it merge with
Decker and disappeared into another dimension?)


> Indeed. And the latter option is hairy for complex and portable software:
> you must get exactly the right header version, but you must also ensure you
> have any number of preprocessor macros etc set precisely the same. There
> can be header inclusion order considerations and more. I'm very reluctant
> to use the automated header processing features.

Those provisos are all valid, yet it turns out to be useful & capable
a lot of the time.  If there is a "-devel" level packaged set of
headers, they should be well enough engineered to let this work.


> [...]  I don't know of any way to ask gcc/gdb/binutils/etc to retain
> a subset of debuginfo in an executable when it's being stripped, and
> I doubt that'd be popular or accepted anyway. [...]

See "BTF" and "CTF" for two efforts to keep some wee subsets of
debuginfo on the installation medium.  And see
debuginfod.systemtap.org :-) for a distribution vehicle for full
mainstream debuginfo.


- FChE