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

2018-01-15 Thread tonywalker . uk
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 but thanks for your help!

On Monday, January 15, 2018 at 3:43:40 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Jan 15, 2018 at 12:36 PM,   
> wrote: 
> > 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? 
>
> The fopen64 function written in myfopen.c will follow ordinary C 
> rules.  If you don't make it static, it will be exported. 
>
> Ian 
>
> > On Monday, January 15, 2018 at 3:05:32 PM UTC-5, Ian Lance Taylor wrote: 
> >> 
> >> The simplist workaround is to export go_fopen64, and write a tiny 
> >> fopen64 in a different C file, with the right signature, that calls 
> >> go_fopen64. 
> >> 
> >> Ian 
> >> 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-15 Thread tonywalker . uk
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 workaround is to export go_fopen64, and write a tiny 
> fopen64 in a different C file, with the right signature, that calls 
> go_fopen64. 
>
> Ian 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-01-15 Thread tonywalker . uk
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 __modes) __wur

So, now my override function conflicts:

In file included from _cgo_export.c:3:0:
cgo-gcc-export-header-prolog:44:14: error: conflicting types for ‘fopen64’
In file included from ./main.go:5:0,
 from _cgo_export.c:3:
/usr/include/stdio.h:298:14: note: previous declaration of ‘fopen64’ was 
here
 extern FILE *fopen64 (const char *__restrict __filename,
  ^~~
_cgo_export.c:37:7: error: conflicting types for ‘fopen64’
 FILE* fopen64(char* p0, char* p1) 
   ^~~

I'm guessing there's not much I can do about the limitation of dealing with 
'const' declarations in C?

On Monday, January 15, 2018 at 2:35:19 PM UTC-5, Ian Lance Taylor wrote:
>
> You neglected to say which system you are running on.  If it's 
> GNU/Linux, note that fopen64 is not declared by default.  It's only 
> declared if define the C preprocessor macro _LARGEFILE64_SOURCE while 
> compiling the file.  You may need a #cgo CFLAGS: line to add a -D 
> option. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-11-06 Thread tonywalker . uk
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 therefore like to see what cgo thing it looks like so I can attempt 
to get a perfect match. Would that be possible?

On Friday, November 3, 2017 at 11:50:36 PM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Nov 3, 2017 at 5:44 PM,   
> wrote: 
> > 
> > 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 should 
> refer to 
> > the type/function from the header? 
>
> I'm sorry, nothing comes to mind.  In C you would just write the 
> declaration the way the header file expects, but cgo doesn't provide a 
> way to do that. 
>
> Ian 
>
>
> > On Friday, November 3, 2017 at 8:28:38 PM UTC-4, Ian Lance Taylor wrote: 
> >> 
> >> On Fri, Nov 3, 2017 at 2:24 PM,   wrote: 
> >> > 
> >> > 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 I try and build: 
> >> > 
> >> > $ go build -buildmode=c-shared 
> >> > # github.com/walkert/loader 
> >> > In file included from 
> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:0: 
> >> > ./main.go:56:14: error: conflicting types for ‘fopen’ 
> >> > In file included from ./main.go:5:0, 
> >> >  from 
> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3: 
> >> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ 
> was 
> >> > here 
> >> >  extern FILE *fopen (const char *__restrict __filename, 
> >> >   ^ 
> >> > 
> >> > /tmp/go-build775342366/
> github.com/walkert/loader/_obj/_cgo_export.c:17:7: 
> >> > error: conflicting types for ‘fopen’ 
> >> >  FILE* fopen(char* p0, char* p1) 
> >> >^ 
> >> > In file included from ./main.go:5:0, 
> >> >  from 
> >> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3: 
> >> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ 
> was 
> >> > here 
> >> >  extern FILE *fopen (const char *__restrict __filename, 
> >> >   ^ 
> >> > 
> >> > I've seen this before when I was trying to return an int instead of 
> >> > C.int so 
> >> > I have a feeling I'm missing something simple here. Any pointers 
> would 
> >> > be 
> >> > much appreciated. 
> >> 
> >> It looks like the same file is doing #include  and `//export 
> >> fopen`.  That won't work, because, as you can see, the definition of 
> >> the Go function fopen will conflict with the declaration in stdio.h. 
> >> 
> >> Ian 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-11-03 Thread tonywalker . uk
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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-11-03 Thread tonywalker . uk
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 should refer 
to the type/function from the header?

Tony

On Friday, November 3, 2017 at 8:28:38 PM UTC-4, Ian Lance Taylor wrote:
>
> On Fri, Nov 3, 2017 at 2:24 PM,   
> wrote: 
> > 
> > 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 I try and build: 
> > 
> > $ go build -buildmode=c-shared 
> > # github.com/walkert/loader 
> > In file included from 
> > $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:0: 
> > ./main.go:56:14: error: conflicting types for ‘fopen’ 
> > In file included from ./main.go:5:0, 
> >  from $WORK/
> github.com/walkert/loader/_obj/_cgo_export.c:3: 
> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was 
> here 
> >  extern FILE *fopen (const char *__restrict __filename, 
> >   ^ 
> > /tmp/go-build775342366/github.com/walkert/loader/_obj/_cgo_export.c:17:7: 
>
> > error: conflicting types for ‘fopen’ 
> >  FILE* fopen(char* p0, char* p1) 
> >^ 
> > In file included from ./main.go:5:0, 
> >  from $WORK/
> github.com/walkert/loader/_obj/_cgo_export.c:3: 
> > /usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was 
> here 
> >  extern FILE *fopen (const char *__restrict __filename, 
> >   ^ 
> > 
> > I've seen this before when I was trying to return an int instead of 
> C.int so 
> > I have a feeling I'm missing something simple here. Any pointers would 
> be 
> > much appreciated. 
>
> It looks like the same file is doing #include  and `//export 
> fopen`.  That won't work, because, as you can see, the definition of 
> the Go function fopen will conflict with the declaration in stdio.h. 
>
> Ian 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-11-03 Thread tonywalker . uk
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 I try and 
build:

$ go build -buildmode=c-shared
# github.com/walkert/loader
In file included from 
$WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:0:
./main.go:56:14: error: conflicting types for ‘fopen’
In file included from ./main.go:5:0,
 from $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:
/usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was here
 extern FILE *fopen (const char *__restrict __filename,
  ^
/tmp/go-build775342366/github.com/walkert/loader/_obj/_cgo_export.c:17:7: 
error: conflicting types for ‘fopen’
 FILE* fopen(char* p0, char* p1)
   ^
In file included from ./main.go:5:0,
 from $WORK/github.com/walkert/loader/_obj/_cgo_export.c:3:
/usr/include/stdio.h:275:14: note: previous declaration of ‘fopen’ was here
 extern FILE *fopen (const char *__restrict __filename,
  ^

I've seen this before when I was trying to return an int instead of C.int 
so I have a feeling I'm missing something simple here. Any pointers would 
be much appreciated.

Thanks in advance!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-05-10 Thread tonywalker . uk
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 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-05-09 Thread tonywalker . uk
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" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-05-08 Thread tonywalker . uk
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 <: 
https://rafalcieslak.wordpress.com/2013/04/02/dynamic-linker-tricks-using-ld_preload-to-cheat-inject-features-and-investigate-programs/>
 where 
rand() is overridden.

If I write a simple function to overwrite it (see here 
) I get the following error when 
trying to compile with go build -o rand.so -buildmode=c-shared test.go (Go 
1.7.4 - same with 1.8 but a slightly different error):

# command-line-arguments
In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:3:0:
/tmp/go-build613177413/command-line-arguments/_obj/_cgo_export.h:55:14: 
error: conflicting types for ‘rand’
 extern GoInt rand();
  ^~~~
In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:2:0:
/usr/include/stdlib.h:335:12: note: previous declaration of ‘rand’ was here
 extern int rand (void) __THROW;
^~~~
/tmp/go-build613177413/command-line-arguments/_obj/_cgo_export.c:17:7: 
error: conflicting types for ‘rand’
 GoInt rand()
   ^~~~
In file included from $WORK/command-line-arguments/_obj/_cgo_export.c:2:0:
/usr/include/stdlib.h:335:12: note: previous declaration of ‘rand’ was here
 extern int rand (void) __THROW;
^~~~
I'm not clear whether I simply need to find a way to declare an equivalent 
signature which matches the stdlib, or whether creating a function which is 
already defined is just not allowed.

Can anyone help here?

Thanks,

Tony

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.