You might want to run LD_DEBUG=bindings to be extra sure the libc is finding your implementation of write instead of its own.
Could be a bug in how you setup things as well.

Breno G.

On Tue, Mar 14, 2023 at 10:48 AM Frederick Virchanza Gotham via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Tue, Mar 14, 2023 at 1:31 PM Breno Guimarães <brenorg@gmail.com> wrote:
>
> >  You actually get an x86 instructions for a 'syscall':
>
> I can't reproduce that: https://godbolt.org/z/55hvM4xKx
> How do you get it to inline printf?


Sorry you're right, I was mistaken (even when building with -fno-builtin).

What's actually happening is that 'printf' is invoked from glibc,
however the implementation of 'printf' inside glibc does not invoke
the overridden version of 'write' that I've provided.

Perhaps the code inside glibc works something like as follows:

    ssize_t write_implementation(int fd, const void *buf, size_t
count) { /* do stuff */ }

    ssize_t write(int fd, const void *buf, size_t count) { return
write_implementation(fd,buf,count); }

    int puts(char const *arg) { return write_implementation(1, arg,
strlen(arg)); }  // NOTE: It doesn't call 'write'

I could go on the Github for glibc to confirm this, but every time I
do, I end up jumping back and forth from file to file and meandering
around macroes -- it's a bit of maze in there.

Or......... maybe printf really does invoke write, but it doesn't get
the address of 'write' from the PLT/GOT, but instead has the address
hardcoded (which means I can't override it at runtime). Maybe.

Either way, the bottom line on it is that even if I provide my own
implementation of 'write', it does not capture the output from puts
and printf (so I have to use fopencookie and change the values of
stout and stderr).
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals