Re: [go-nuts] Unexpected behaviour with LD_PRELOAD and fopen and cgo

Ah ok. So I managed to get something to compile (ended up having to cast the 'const char' arguments to fopen64 to char before passing them to my go_fopen64 function but I still get: fatal: morestack on g0 zsh: trace trap LD_PRELOAD=./preload python test.py foo I'm clearly out of my depth here

Re: [go-nuts] Unexpected behaviour with LD_PRELOAD and fopen and cgo

Thanks Ian. I assume I'd include it like this: // #include myfopen.h And also a myfopen.c with the actual function But how do I ensure the fopen64 in myfopen.h is exported to override the default? On Monday, January 15, 2018 at 3:05:32 PM UTC-5, Ian Lance Taylor wrote: > > The simplist

Re: [go-nuts] Unexpected behaviour with LD_PRELOAD and fopen and cgo

Thanks Ian. This did the trick and now I'm faced with the problem of function signatures that include 'const'. On my system, fopen is declared thus: extern FILE *fopen (char *p0, char *modes) __wur But fopen64 is: extern FILE *fopen64 (const char *__restrict __filename, const char *__restrict

Re: [go-nuts] How to determine the correct method signature to override fopen

In that case - do you know how I can inspect the comparison it's doing? Since I'm already doing this for the open system call, I know that it's possible to write a function with the same definition. It seems in this case that I'm not matching the representation that cgo is expecting. I would

Re: [go-nuts] How to determine the correct method signature to override fopen

This is without the include: $ go build -buildmode=c-shared # github.com/walkert ./main.go:6:41: could not determine kind of name for C.FILE ./main.go:7:8: could not determine kind of name for C.fopen -- You received this message because you are subscribed to the Google Groups "golang-nuts"

Re: [go-nuts] How to determine the correct method signature to override fopen

Thanks Ian. I had included that because it seems required in order for me to refer to the return type (C.FILE) and so I can access the underlying C.fopen function. This is the approach I have with open but perhaps this is different. If I'm not supposed to use the include, can you advise how I

[go-nuts] How to determine the correct method signature to override fopen

Hi, I've been writing a shared-object which I'll use via LD_PRELOAD to override the open syscall. This is currently working OK but now I want to move on to fopen. I've defined it (as far as I can tell) in-line with the stdio header see here . However, when

[go-nuts] Re: Creating shared-libraries which override existing system functions?

Excellent - thanks Donovan. Alas I've since discovered that since the program I want to preload is compiled using Go - it doesn't use libc and LD_PRELOAD won't work with it. But - a useful lesson either way. Cheers. -- You received this message because you are subscribed to the Google Groups

[go-nuts] Re: Creating shared-libraries which override existing system functions?

Looks like the first link didn't work. Should link to here . -- You received this message because you are subscribed to the Google Groups "golang-nuts"

[go-nuts] Creating shared-libraries which override existing system functions?

Hi All, I'd like to experiment writing a shared library that will override system functions via LD_LIBRARY_PATH. I'd like to achieve something like the basic functionality demonstrated here <: