Re: __syscall dropping 6th arg on amd64

[Tim Newsham]

>
> \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).

-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

Re: __syscall dropping 6th arg on amd64

[Ted Unangst]

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 there for the compiler to fill in the full
> 64bits.

The first two should have casts as well I think, but you get lucky because
they're passed in registers and not the stack?

Re: __syscall dropping 6th arg on amd64

[Tim Newsham]

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.
>

That did the trick.. thank you.


> Philip Guenther
>

chrisC: glad to be of assistance.

-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

Re: __syscall dropping 6th arg on amd64

[Philip Guenther]

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 before any off_t syscall argument because 1993 or whatever.

(Because that guarantees that the stack layout of registers pushed in
ABI-matching order match the structure layout of the args structure.
sparc (32bit) is an example of the problem case, where longlong args
are pushed into the next two registers, effectively giving 4 byte
alignment while the args structure has 8 byte alignment.)


> 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 there for the compiler to fill in the full
64bits.


Philip Guenther

Re: __syscall dropping 6th arg on amd64

[Tim Newsham]

>
> 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 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);

results in

  1947 a.outCALL
 
mmap(0x10,0x4000,0x7,0x1000,-1,0x7f7f)

vs straight call:

  1947 a.outCALL
 mmap(0,0x1,0x3,0x1002,-1,0)

-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com

Re: __syscall dropping 6th arg on amd64

[Ted Unangst]

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 the __syscall entry, and not when using the "normal" entry.
> Is this known/expected behavior or a bug?

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.

__syscall dropping 6th arg on amd64

[Tim Newsham]

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 when using the "normal" entry.
Is this known/expected behavior or a bug?

---
$ ktrace ./a.out
p 0x10
p 0x100528

---
$ kdump
  2631 a.outCALL
 mmap(0,0x1,0x3,0x1002,-1,0)
  2631 a.outRET   mmap 27609139748864/0x191c40f7a000

  2631 a.outCALL
 
mmap(0x10,0x4000,0x7,0x1000,-1,0x7f7c5bd8)
  2631 a.outRET   mmap 1051608/0x100bd8


#include 
#include 

int
main(int argc, char **argv)
{
void *p;
unsigned long long p2;

p = mmap((void*)0x10, 4*4096, 7, MAP_ANON, -1, 0);
printf("p %p\n", p);
munmap(p, 4*4096);

p2 = __syscall(197, 0x10, 4*4096, 7, MAP_ANON, -1, 0);
printf("p 0x%llx\n", p2);
return 0;
}


-- 
Tim Newsham | www.thenewsh.com/~newsham | @newshtwit | thenewsh.blogspot.com