Searched hist:171646 (Results 1 - 5 of 5) sorted by relevance
/freebsd-10.0-release/usr.bin/truss/ | ||
H A D | powerpc-fbsd.c | diff 171646 Sat Jul 28 21:15:04 MDT 2007 marcel Fix handling of Quad-type arguments. Previously, syscalls containing 64-bit arguments would have explicit padding. On 64-bit platforms there was no padding, so the dummy argument was not covering anything. On 32-bit platforms with weak alignment (i.e. i386) the 64-bit argument did not need to be aligned, so there too an aditional argument was introduced. On 32-bit platforms with strong alignment (i.e. PowerPC) the dummy argument in fact cover the padding. By elimininating the dummy argument, 64-bit platforms now have 1 argument less. This also applies to 32-bit platforms with weak alignment. On PowerPC this doesn't matter, because the padding is still there. We just don't "name" it. Deal with those 3 cases. Approved by: re (kensmith) |
H A D | powerpc64-fbsd.c | diff 171646 Sat Jul 28 21:15:04 MDT 2007 marcel Fix handling of Quad-type arguments. Previously, syscalls containing 64-bit arguments would have explicit padding. On 64-bit platforms there was no padding, so the dummy argument was not covering anything. On 32-bit platforms with weak alignment (i.e. i386) the 64-bit argument did not need to be aligned, so there too an aditional argument was introduced. On 32-bit platforms with strong alignment (i.e. PowerPC) the dummy argument in fact cover the padding. By elimininating the dummy argument, 64-bit platforms now have 1 argument less. This also applies to 32-bit platforms with weak alignment. On PowerPC this doesn't matter, because the padding is still there. We just don't "name" it. Deal with those 3 cases. Approved by: re (kensmith) |
H A D | amd64-fbsd32.c | diff 171646 Sat Jul 28 21:15:04 MDT 2007 marcel Fix handling of Quad-type arguments. Previously, syscalls containing 64-bit arguments would have explicit padding. On 64-bit platforms there was no padding, so the dummy argument was not covering anything. On 32-bit platforms with weak alignment (i.e. i386) the 64-bit argument did not need to be aligned, so there too an aditional argument was introduced. On 32-bit platforms with strong alignment (i.e. PowerPC) the dummy argument in fact cover the padding. By elimininating the dummy argument, 64-bit platforms now have 1 argument less. This also applies to 32-bit platforms with weak alignment. On PowerPC this doesn't matter, because the padding is still there. We just don't "name" it. Deal with those 3 cases. Approved by: re (kensmith) |
H A D | i386-fbsd.c | diff 171646 Sat Jul 28 21:15:04 MDT 2007 marcel Fix handling of Quad-type arguments. Previously, syscalls containing 64-bit arguments would have explicit padding. On 64-bit platforms there was no padding, so the dummy argument was not covering anything. On 32-bit platforms with weak alignment (i.e. i386) the 64-bit argument did not need to be aligned, so there too an aditional argument was introduced. On 32-bit platforms with strong alignment (i.e. PowerPC) the dummy argument in fact cover the padding. By elimininating the dummy argument, 64-bit platforms now have 1 argument less. This also applies to 32-bit platforms with weak alignment. On PowerPC this doesn't matter, because the padding is still there. We just don't "name" it. Deal with those 3 cases. Approved by: re (kensmith) |
H A D | syscalls.c | diff 171646 Sat Jul 28 21:15:04 MDT 2007 marcel Fix handling of Quad-type arguments. Previously, syscalls containing 64-bit arguments would have explicit padding. On 64-bit platforms there was no padding, so the dummy argument was not covering anything. On 32-bit platforms with weak alignment (i.e. i386) the 64-bit argument did not need to be aligned, so there too an aditional argument was introduced. On 32-bit platforms with strong alignment (i.e. PowerPC) the dummy argument in fact cover the padding. By elimininating the dummy argument, 64-bit platforms now have 1 argument less. This also applies to 32-bit platforms with weak alignment. On PowerPC this doesn't matter, because the padding is still there. We just don't "name" it. Deal with those 3 cases. Approved by: re (kensmith) |
Completed in 126 milliseconds