Re: __syscall dropping 6th arg on amd64

> > \The first two should have casts as well I think, but you get lucky > because > they're passed in registers and not the stack? > it "worked", but I switched to providing a prototype declaring all args to __syscall as 64bit and now everything is happy (with the extra padding arg added). --

Re: __syscall dropping 6th arg on amd64

Philip Guenther wrote: > > thank you. I didnt know about that. > > I added an extra pad arg and I'm still getting weirdness: > > > > p2 = __syscall(197, 0x10, 4*4096, 7, MAP_ANON, -1, 0, 0); > > varargs are so fun. That last argument is a 64bit type, not an int, > so you have to use 0LL

Re: __syscall dropping 6th arg on amd64

On Thu, Jul 7, 2016 at 1:43 PM, Philip Guenther wrote: > > p2 = __syscall(197, 0x10, 4*4096, 7, MAP_ANON, -1, 0, 0); > > varargs are so fun. That last argument is a 64bit type, not an int, > so you have to use 0LL there for the compiler to fill in the full > 64bits.

Re: __syscall dropping 6th arg on amd64

On Thu, Jul 7, 2016 at 4:11 PM, Tim Newsham wrote: >> >> If you look at sys/kern/syscalls.master: >> 197 STD { void *sys_mmap(void *addr, size_t len, int prot, >> \ >> int flags, int fd, long pad, off_t pos); } >> >> There's a pad

Re: __syscall dropping 6th arg on amd64

> > If you look at sys/kern/syscalls.master: > 197 STD { void *sys_mmap(void *addr, size_t len, int prot, > \ > int flags, int fd, long pad, off_t pos); } > > There's a pad before any off_t syscall argument because 1993 or whatever. > thank you. I

Re: __syscall dropping 6th arg on amd64

Tim Newsham wrote: > I just noticed that the __syscall call is dropping the 6th argument > (providing garbage) when I use it on amd64. The attached program > makes an mmap call "normally" and with __syscall. Running the > program in ktrace reveals that the last argument is garbage when > using

__syscall dropping 6th arg on amd64

I just noticed that the __syscall call is dropping the 6th argument (providing garbage) when I use it on amd64. The attached program makes an mmap call "normally" and with __syscall. Running the program in ktrace reveals that the last argument is garbage when using the __syscall entry, and not