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_at_[hidden]> wrote:

> On Tue, Mar 14, 2023 at 1:31 PM Breno Guimarães <brenorg_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>