Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Jun 2010 14:42:47 -0700
From:      Garrett Cooper <yanefbsd@gmail.com>
To:        "Sam Fourman Jr." <sfourman@gmail.com>
Cc:        Kostik Belousov <kostikbel@gmail.com>, freebsd-hackers@freebsd.org
Subject:   Re: kernel patch needed for wine?
Message-ID:  <AANLkTiksgnem7qiGzpJIVQp7Dxsu0dfasF10STzSwxBf@mail.gmail.com>
In-Reply-To: <AANLkTinNMaMH_5TSUL8PN1D0J-IBjIZV8K_sBTeB1H64@mail.gmail.com>
References:  <AANLkTik5Owwpk5O6eUbSKgHxpjvcEXwilGECgtX0hx5a@mail.gmail.com> <20100630105027.GJ13238@deviant.kiev.zoral.com.ua> <AANLkTikDxVGpc6LfYlqFZLo-QiJFr8lbj2MVZMUci-lI@mail.gmail.com> <AANLkTilusilVimfscZdj3QAOOFYs3Gh3pt5V6SXe3VHP@mail.gmail.com> <AANLkTinNMaMH_5TSUL8PN1D0J-IBjIZV8K_sBTeB1H64@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 30, 2010 at 2:22 PM, Sam Fourman Jr. <sfourman@gmail.com> wrote=
:
> On Wed, Jun 30, 2010 at 11:26 AM, Garrett Cooper <yanefbsd@gmail.com> wro=
te:
>> On Wed, Jun 30, 2010 at 8:43 AM, Sam Fourman Jr. <sfourman@gmail.com> wr=
ote:
>>>> Which patch ? icebp generates the SIGTRAP on latest 8-stable, verified
>>>> by the following trivival assembler program:
>>>> =A0 =A0 =A0 =A0.text
>>>> =A0 =A0 =A0 =A0.globl =A0main
>>>> main:
>>>> =A0 =A0 =A0 =A0.byte =A0 0xf1
>>>> =A0 =A0 =A0 =A0xorl =A0 =A0%edi,%edi
>>>> =A0 =A0 =A0 =A0call =A0 =A0exit
>>>>
>>>
>
> Here is the C program that the linux people used as a test case.
>
> ***************************************************************
> #include <stdio.h>
> #include <signal.h>
>
>
>
> void trap_handler(int sig)
> {
> =A0 =A0 =A0 =A0printf("trapped\n");
> }
>
>
> /*
> =A0* icebp
> =A0* ret
> =A0*/
> char icebp_func[] =3D "\xf1\xc3";
> typedef void (*icebp_call)(void);
>
> int main(int argc, char **argv)
> {
> =A0 =A0 =A0 =A0icebp_call func =3D (icebp_call)icebp_func;
>
> =A0 =A0 =A0 =A0signal(SIGTRAP, trap_handler);
>
> =A0 =A0 =A0 =A0func();
>
> =A0 =A0 =A0 =A0return 0;
> }
>
> ***************************************************************
>
> My question is why doe the above code not print trapped on amd64?
>
> FreeBSD 8.1 i386 this code prints "Trapped" as intended
> FreeBSD 8.1 amd64 this code prints "Segmentation fault: 11"
> FreeBSD 8.1 amd64 chrooted to 32bit prints "Segmentation fault"
>
> I did verify that from Linux amd64 this works and prints "Trapped"
> uname -a
> Linux workstation 2.6.32-23-generic #37-Ubuntu SMP Fri Jun 11 08:03:28
> UTC 2010 x86_64 GNU/Linux

Hmmm... I've seen similar whackiness with Linux and signals, but
that's a different thing entirely (it was rt signals vs non-rt
signals).

Here's a modified version of the testcase (wanted to make sure that
things were sane):

$ cat test_sigtrap.c
#include <err.h>
#include <signal.h>
#include <stdio.h>

int trapped =3D 0;

void trap_handler(int sig)
{
	trapped =3D 1;
}


/*
 * icebp
 * ret
 */
char icebp_func[] =3D "\xf1\xc3";
typedef void (*icebp_call)(void);

int main(int argc, char **argv)
{
	icebp_call func =3D (icebp_call)icebp_func;

	if (signal(SIGTRAP, trap_handler) =3D=3D SIG_ERR)
		err(1, "signal");

	func();

	if (trapped)
		printf("Admiral Ackbar: it's a trap!\n");

	return 0;
}

Ran it and it segfaulted on CURRENT:

$ sudo truss ./test_sigtrap
__sysctl(0x7fffffffe590,0x2,0x7fffffffe5ac,0x7fffffffe5a0,0x0,0x0) =3D 0 (0=
x0)
mmap(0x0,672,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365169664 (0x80052=
e000)
munmap(0x80052e000,672)				 =3D 0 (0x0)
__sysctl(0x7fffffffe600,0x2,0x800638848,0x7fffffffe5f8,0x0,0x0) =3D 0 (0x0)
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) =3D
34365169664 (0x80052e000)
issetugid(0x80052f015,0x8005294e4,0x800644f50,0x800644f20,0x5b31,0x0) =3D 0=
 (0x0)
open("/etc/libmap.conf",O_RDONLY,0666)		 ERR#2 'No such file or directory'
open("/var/run/ld-elf.so.hints",O_RDONLY,057)	 =3D 2 (0x2)
read(2,"Ehnt\^A\0\0\0\M^@\0\0\0}\0\0\0\0"...,128) =3D 128 (0x80)
lseek(2,0x80,SEEK_SET)				 =3D 128 (0x80)
read(2,"/lib:/usr/lib:/usr/lib/compat:/u"...,125) =3D 125 (0x7d)
close(2)					 =3D 0 (0x0)
access("/lib/libc.so.7",0)			 =3D 0 (0x0)
open("/lib/libc.so.7",O_RDONLY,030703440)	 =3D 2 (0x2)
fstat(2,{ mode=3D-r--r--r-- ,inode=3D353312,size=3D1192760,blksize=3D16384 =
}) =3D 0 (0x0)
pread(0x2,0x800637700,0x1000,0x0,0x101010101010101,0x8080808080808080)
=3D 4096 (0x1000)
mmap(0x0,2318336,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) =3D
34366312448 (0x800645000)
mmap(0x800645000,1028096,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCO=
RE,2,0x0)
=3D 34366312448 (0x800645000)
mmap(0x80083f000,135168,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,2,0xfa00=
0)
=3D 34368385024 (0x80083f000)
mprotect(0x800860000,110592,PROT_READ|PROT_WRITE) =3D 0 (0x0)
close(2)					 =3D 0 (0x0)
sysarch(0x81,0x7fffffffe680,0x800533088,0x0,0xffffffffffcea590,0x8080808080=
808080)
=3D 0 (0x0)
mmap(0x0,176,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365202432 (0x80053=
6000)
munmap(0x800536000,176)				 =3D 0 (0x0)
mmap(0x0,44064,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) =3D 34365202432 (0x800=
536000)
munmap(0x800536000,44064)			 =3D 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM=
|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXF=
SZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
=3D 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)		 =3D 0 (0x0)
__sysctl(0x7fffffffe620,0x2,0x800866d20,0x7fffffffe618,0x0,0x0) =3D 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM=
|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXF=
SZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
=3D 0 (0x0)
sigprocmask(SIG_SETMASK,0x0,0x0)		 =3D 0 (0x0)
sigaction(SIGTRAP,{ 0x4005f0 SA_RESTART ss_t },{ SIG_DFL 0x0 ss_t }) =3D 0 =
(0x0)
SIGNAL 11 (SIGSEGV)
process exit, rval =3D 0

Also, is there perhaps a sideeffect dealing with the size of a char on
FreeBSD vs Linux?

That's a pretty badass way to load assembler instructions on the stack :).

Thanks!
-Garrett



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTiksgnem7qiGzpJIVQp7Dxsu0dfasF10STzSwxBf>