On Friday, 1 May 2026 02:33:54 Pacific Daylight Time David Brown via Std-
Proposals wrote:
> I can't see any justification for thinking this is appropriate for the
> C++ programming language. What you are doing is hacking binaries. C++
> is for writing programs, and C++ compilers are for compiling C++ code.
> What you are looking for here is something totally different - you want
> tools like debuggers, disassemblers, tracers, monitors, etc. Trying to
> put this kind of hack into C++ will not improve the language or the
> ability of people to write good C++ code, any more than trying to add
> features to let C++ be an editor or a file manager.

Right, if I just wanted to trace cross-shared library calls, I'd use
ltrace(1). There's no need to hack *anything*. It'll make a best effort to show
arguments to functions it doesn't know, but you can teach it once you get more
information (usually you'd do that in the debugger).

$ ltrace ls -d /
strrchr("ls", '/') = nil
setlocale(LC_ALL, "") =
"LC_CTYPE=pt_BR.UTF-8;LC_NUMERIC="...
bindtextdomain("coreutils", "/usr/share/locale") = "/usr/share/locale"
textdomain("coreutils") = "coreutils"
__cxa_atexit(0x557a69921d70, 0, 0x557a69937008, 0) = 0
getopt_long(3, 0x7ffd61042bf8, "abcdfghiklmnopqrstuvw:xABCDFGHI:"...,
0x557a699360e0, -1) = 100
getopt_long(3, 0x7ffd61042bf8, "abcdfghiklmnopqrstuvw:xABCDFGHI:"...,
0x557a699360e0, -1) = -1
isatty(1) = 1
ioctl(1, 21523, 0x7ffd61042a30) = 0
getenv("TZ") = nil
__errno_location() = 2
__ctype_get_mb_cur_max() = 6
strlen("/") = 1
statx(0xffffff9c, 0x7ffd6104417e, 2304, 2) = 0
strlen("/") = 1
__memcpy_chk(0x557a7972f940, 0x7ffd6104417e, 2, 2) = 0x557a7972f940
...

See the __cxa_atexit, statx and __memcpy_chk calls it doesn't know how to
print arguments for.

Because we *ARE* talking about cross-DLL/shared library calls. Intra-library
ones can't be intercepted because they may have resolved using PC-relative
addressing and wouldn't go through an interceptable point (the PLT or GOT).

Even if you could find all the call instructions, you can't replace them
because the instructions themselves may not have a wide-enough immediate to
displace the call to where the interceptor lives in memory. You can't patch
the function itself because in a generic setting you don't know how important
the first few bytes of the function are, and just copying them elsewhere is not
a good idea either.

Moreover, intra-library calls may have been inlined, either inside the same TU
or via LTO, and you cannot intercept the inlined content because it's not
marked in any way. Constant propagation into the inlined function may have
made it completely different.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.