Re: Acu Cobol 6.0 for Linux
Dan Nelson writes: > In the last episode (Feb 04), Walter C. Pelissero said: > > A side note. What is the impact of this IPC_64 flag on the FreeBSD > > code? Can we ignore it, or does it mean that the Linux emulator is > > outdated regarding this "new" flag? > > Linux IPC_64 support was added to the 5.x tree over a year ago but > never got merged back to 4.x. It looks like there are different > structures for the IPC_64 case, so just stripping the IPC_64 bit won't > work. Take a look at > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ipc.c.diff?r1=1.30&r2=1.31&f=h > - it was a mega-commit, so there's more than just the IPC_64 stuff, but > it's pretty easy to pick out the right bits (basically anything with a > 64 in it :). I've been spending the last two days upgrading to 5.2.1.-RC. Well, beside the predictable cultural impact (a few things have changed from 4.9), the first impression was that the Linux emulator worked much better, in fact it runs Acu Cobol 6.0 for Linux flawlessly! There are still some minor details that don't work as expected (ACPI-S1 and cardbus) and some that stopped working (snd_pcm). These will probably require delving in the documentation or possibly waiting for 5.3. But devfs and devd alone are worth upgrading. Congratulations guys. You've done an awesome job! -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Acu Cobol 6.0 for Linux
Dan Nelson writes: > In the last episode (Feb 04), Walter C. Pelissero said: > > A side note. What is the impact of this IPC_64 flag on the FreeBSD > > code? Can we ignore it, or does it mean that the Linux emulator is > > outdated regarding this "new" flag? > > Linux IPC_64 support was added to the 5.x tree over a year ago but > never got merged back to 4.x. Oops. Don't tell me Iv'e beeing trying to fix a bug that wasn't there. I'll try in the next days to install 5.2 at least on my laptop and see if it helps. (It's anyhow something that was already on my agenda.) -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Acu Cobol 6.0 for Linux
In the last episode (Feb 04), Walter C. Pelissero said: > A side note. What is the impact of this IPC_64 flag on the FreeBSD > code? Can we ignore it, or does it mean that the Linux emulator is > outdated regarding this "new" flag? Linux IPC_64 support was added to the 5.x tree over a year ago but never got merged back to 4.x. It looks like there are different structures for the IPC_64 case, so just stripping the IPC_64 bit won't work. Take a look at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ipc.c.diff?r1=1.30&r2=1.31&f=h - it was a mega-commit, so there's more than just the IPC_64 stuff, but it's pretty easy to pick out the right bits (basically anything with a 64 in it :). -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Acu Cobol 6.0 for Linux
Dan Nelson writes: > If you do have sysvmsg loaded, you may have to start adding printfs in > linux_msgctl() to trace which call is failing and why. Thanks. With your hints I made an interesting discovery that allowed me to improve the situation dramatically. In Linux's /usr/include/linux/ipc.h there is an interesting comment: /* * Version flags for semctl, msgctl, and shmctl commands * These are passed as bitflags or-ed with the actual command */ #define IPC_OLD 0 /* Old version (no 32-bit UID support on many architectures) */ #define IPC_64 0x0100 /* New version (support 32-bit UIDs, bigger message sizes, etc. */ In fact linux_msgctl receives a command 0x102 instead of 2. Although the following patch fixes the problem related to msgctl, I'm not quite sure it's enough to say that Acu Cobol runs perfectly on FreeBSD. Actually I've got the feeling msgrcv still doesn't work as expected, but I might be wrong. I'll probably reach a certain confidence in the following days. A side note. What is the impact of this IPC_64 flag on the FreeBSD code? Can we ignore it, or does it mean that the Linux emulator is outdated regarding this "new" flag? Cheers, -- walter pelissero http://www.pelissero.de Index: compat/linux/linux_ipc.c === RCS file: /usr/home/src.cvs/src/sys/compat/linux/linux_ipc.c,v retrieving revision 1.17.2.3 diff -w -u -r1.17.2.3 linux_ipc.c --- compat/linux/linux_ipc.c5 Nov 2001 19:08:22 - 1.17.2.3 +++ compat/linux/linux_ipc.c4 Feb 2004 00:33:56 - @@ -233,7 +233,7 @@ bsd_args.semnum = args->semnum; bsd_args.arg = unptr; - switch (args->cmd) { + switch (args->cmd & 0xff) { /* mask off the IPC_64 flag */ case LINUX_IPC_RMID: bsd_args.cmd = IPC_RMID; break; @@ -362,7 +362,7 @@ int error; bsd_args.msqid = args->msqid; -bsd_args.cmd = args->cmd; +bsd_args.cmd = args->cmd & 0xff; /* mask off the IPC_64 flag */ bsd_args.buf = (struct msqid_ds *)args->buf; error = msgctl(p, &bsd_args); return ((args->cmd == LINUX_IPC_RMID && error == EINVAL) ? 0 : error); @@ -429,7 +429,7 @@ int error; caddr_t sg = stackgap_init(); -switch (args->cmd) { +switch (args->cmd & 0xff) { /* mask off the IPC_64 flag */ case LINUX_IPC_STAT: bsd_args.shmid = args->shmid; bsd_args.cmd = IPC_STAT; ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Acu Cobol 6.0 for Linux
In the last episode (Feb 03), Walter C. Pelissero said: > I tried linux_kdump (from ports) and things seem to clarify a bit. > > I concentrated on acushare, which is the daemon that supervises > inter-process locking (locking on file access) and licence > verification. Whereas acushare seems to start properly, an attempt to > kill it through the recommended means (not with kill(1)), yields an > IPC error. On Linux strace on the daemon process shows: > > msgrcv(256, {1, "\254\1\0\0\6\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...}, 100, > 1, MSG_NOERROR) = 12 > getpid()= 376 > getuid32() = -1 ENOSYS (Function not implemented) > msgctl(256, IPC_STAT, 0xba54) = 0 > msgsnd(256, {428, "x\1\0\0\6\0\0\0\6\0\0\0"}, 12, 0) = 0 > > That is, msgrcv returns a 12 bytes long message and the daemon > answers. On FreeBSD, on the other hand: > > 75838 acushare RET linux_ipc 12/0xc > 75838 acushare CALL linux_getpid > 75838 acushare RET linux_getpid 75838/0x1283e > 75838 acushare CALL linux_ipc(0xe,0x5,0x102,0,0xbfbff444,0) > 75838 acushare RET linux_ipc -1 errno 22 Invalid argument > 75838 acushare CALL linux_time(0xbfbff49c) > 75838 acushare RET linux_time 1075830865/0x401fe051 > 75838 acushare CALL write(0,0x2806f000,0x4a) > 75838 acushare GIO fd 0 wrote 74 bytes > "acushare: 2004-02-03 18:54:25: Error replying to test message from run\ >cbl > " > > That is, linux_ipc (possibly a catch-all name for the Linux IPC > functions family), returns a 12 bytes long message, but when it is > supposed to do the msgctl it fails miserably with an errno 22. > > I couldn't make sense out of the six arguments to linux_ipc shown in > the kdump. Does anyone know how to interprete them? linux_ipc is emulated in /sys//linux/linux_machdep.c, and in linux.h: #define LINUX_MSGCTL14 so the switch() in linux_ipc ends up calling linux_msgctl in /sys/compat/linux/linux_ipc.c. Do you have SYSV message queues enabled in your kernel? Stick "options SYSVMSG" in your config file and rebuild, or "kldload sysvmsg" if you have the module. If you do have sysvmsg loaded, you may have to start adding printfs in linux_msgctl() to trace which call is failing and why. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Acu Cobol 6.0 for Linux
I tried linux_kdump (from ports) and things seem to clarify a bit. I concentrated on acushare, which is the daemon that supervises inter-process locking (locking on file access) and licence verification. Whereas acushare seems to start properly, an attempt to kill it through the recommended means (not with kill(1)), yields an IPC error. On Linux strace on the daemon process shows: msgrcv(256, {1, "\254\1\0\0\6\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...}, 100, 1, MSG_NOERROR) = 12 getpid()= 376 getuid32() = -1 ENOSYS (Function not implemented) msgctl(256, IPC_STAT, 0xba54) = 0 msgsnd(256, {428, "x\1\0\0\6\0\0\0\6\0\0\0"}, 12, 0) = 0 That is, msgrcv returns a 12 bytes long message and the daemon answers. On FreeBSD, on the other hand: 75838 acushare RET linux_ipc 12/0xc 75838 acushare CALL linux_getpid 75838 acushare RET linux_getpid 75838/0x1283e 75838 acushare CALL linux_ipc(0xe,0x5,0x102,0,0xbfbff444,0) 75838 acushare RET linux_ipc -1 errno 22 Invalid argument 75838 acushare CALL linux_time(0xbfbff49c) 75838 acushare RET linux_time 1075830865/0x401fe051 75838 acushare CALL write(0,0x2806f000,0x4a) 75838 acushare GIO fd 0 wrote 74 bytes "acushare: 2004-02-03 18:54:25: Error replying to test message from run\ cbl " That is, linux_ipc (possibly a catch-all name for the Linux IPC functions family), returns a 12 bytes long message, but when it is supposed to do the msgctl it fails miserably with an errno 22. I couldn't make sense out of the six arguments to linux_ipc shown in the kdump. Does anyone know how to interprete them? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Acu Cobol 6.0 for Linux
I realised that the ktrace log was rubbish; most of the syscalls names were not properly mapped. I tried to track down the exact spot were the Linux executable gets the SEGV signal, running strace on a Debian system and comparing the values passed to the system calls. Here is an extract: rt_sigaction(SIGTSTP, {0x8072ce0, [TSTP], SA_RESTART|0x400}, {SIG_IGN}, 8) = 0 rt_sigaction(SIGHUP, {0x8072ca0, [HUP], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGTERM, {0x8072bf0, [TERM], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGFPE, {0x804f910, [FPE], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGBUS, {0x804f940, [BUS], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSEGV, {0x804f910, [SEGV], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGILL, {0x804f910, [ILL], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGSYS, {0x804f910, [SYS], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0 rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0 brk(0x81c2000) = 0x81c2000 ^^--- SEGV on FreeBSD! brk(0x81c3000) = 0x81c3000 brk(0x81c4000) = 0x81c4000 brk(0x81c5000) = 0x81c5000 brk(0x81c6000) = 0x81c6000 So it was rt_sigaction() and not pwrite(); brk() and not ktrace(). Does this shed a new light? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Acu Cobol 6.0 for Linux
Jerry McAllister writes: > > [apparently the first message didn't get through; this is a repost] > > Your previous post got through. > Probably the presumed answer is that no-one who saw it has > tried this or feels competent to respond. Sorry for the duplicate. It wasn't the lack of answer but the missing entry in the mailing list archive which made me suspect the message didn't get through. I didn't realise the archives were updated on a weekly basis. > You might some response if you could find a way to break the > problem down a little more and give a little more detail. How about a ktrace? 459 ktrace RET ktrace 0 459 ktrace CALL execve(0xbfbff85f,0xbfbff740,0xbfbff74c) 459 ktrace NAMI "/usr/local/acucobol60/bin/runcbl" 459 ktrace NAMI "/compat/linux/lib/ld-linux.so.2" 459 runcbl RET execve 0 459 runcbl CALL settimeofday(0xbfbff30c) 459 runcbl RET settimeofday 0 459 runcbl CALL ktrace(0) 459 runcbl RET ktrace 136044544/0x81be000 459 runcbl CALL open(0x2819d4fe,0,0x6c2f6c61) 459 runcbl NAMI "/compat/linux/etc/ld.so.preload" 459 runcbl NAMI "/etc/ld.so.preload" 459 runcbl RET open JUSTRETURN 459 runcbl CALL open(0xbfbfea1c,0,0) 459 runcbl NAMI "/compat/linux/usr/local/linux-jdk1.3.0/lib/i386/libm.so.6" 459 runcbl NAMI "/usr/local/linux-jdk1.3.0/lib/i386/libm.so.6" 459 runcbl RET open JUSTRETURN 459 runcbl CALL setrlimit(0xbfbfea1c,0xbfbfeae4,0x281a03e0) 459 runcbl NAMI "/compat/linux/usr/local/linux-jdk1.3.0/lib/i386" 459 runcbl NAMI "/usr/local/linux-jdk1.3.0/lib/i386" 459 runcbl RET setrlimit JUSTRETURN 459 runcbl CALL open(0xbfbfea1c,0,0x) 459 runcbl NAMI "libm.so.6" 459 runcbl RET open JUSTRETURN 459 runcbl CALL open(0x2819e493,0,0x1) 459 runcbl NAMI "/compat/linux/etc/ld.so.cache" 459 runcbl NAMI "/compat/linux" 459 runcbl NAMI "/compat/linux/etc/ld.so.cache" 459 runcbl RET open 3 459 runcbl CALL mmap(0x3,0xbfbfea94,0x281a03e0) 459 runcbl RET mmap 0 459 runcbl CALL dup2(0xbfbfea4c) 459 runcbl RET dup2 672796672/0x281a1000 459 runcbl CALL close(0x3) 459 runcbl RET close 0 459 runcbl CALL open(0x281a8f5e,0,0xbfbfeb64) 459 runcbl NAMI "/compat/linux/lib/libm.so.6" 459 runcbl NAMI "/compat/linux" 459 runcbl NAMI "/compat/linux/lib/libm.so.6" 459 runcbl RET open 3 459 runcbl CALL read(0x3,0xbfbfebb4,0x400) 459 runcbl GIO fd 3 read 1024 bytes "[EMAIL PROTECTED] \M-p\M-w\^A\0\0\0\0\0004\0 \0\^F\0(\0\^[\0\^Z\0\^F\0\0\0004\0\0\0004\0\ [EMAIL PROTECTED]@\0\0\0\^E\0\0\0\^D\0\0\0\^C\0\0\0 \M-t\^A\0\ \M-t\^A\0 \M-t\^A\0\^S\0\0\0\^S\0\0\0\^D\0\0\0\^A\0\0\0\^A\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0003\M-t\^A\0003\M-t\^A\0\^E\0\0\0\0\^P\0\0\^A\0\0\ [EMAIL PROTECTED]@[EMAIL PROTECTED] \0\0\0\M^D\M-t\^A\0\M^D\^D\^B\0\M^D\^D\^B\0\M-X\0\0\0\M-X\0\0\0\^F\0\0\ \0\^D\0\0\0\^D\0\0\0\M-t\0\0\0\M-t\0\0\0\M-t\0\0\0 \0\0\0 \0\0\0\^D\0\ \0\0\^D\0\0\0\^D\0\0\0\^P\0\0\0\^A\0\0\0GNU\0\0\0\0\0\^B\0\0\0\0\0\0\0\ \^^\0\0\0\M-!\^B\0\0v\^A\0\0H\^A\0\0\0\0\0\0\0\0\0\0\M^Z\0\0\0\M-O\0\0\ \0\M-e\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M-<\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\08\0\0\0\0\0\0\ \0\0\0\0\0\M^U\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M->\0\0\0\0\0\0\09\0\0\0e\ \^A\0\0\M-1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Y\^A\0\0B\^A\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M^Y\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\M-u\0\0\0X\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\M-&[EMAIL PROTECTED] \0\0\0\0\\^A\0\0\0\0\0\0\M-g\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\M-2\0\0\0\0\0\0\0006\0\0\0\M-i\0\0\0 \^A\0\0\M-=\0\0\0\M-v\0\ \0\0\^Q\^A\0\0\M-'\0\0\0\0\0\0\0n\0\0\0\M-U\0\0\0\M-X\0\0\0{\0\0\0\M-8\ \0\0\0\^Y\^A\0\0\M-:\0\0\0\0\0\0\0j\^A\0\0\\\0\0\0>\^A\0\0\M-$\0\0\0M\ \^A\0\0\0\0\0\0\M-b\0\0\0\0\0\0\0002\0\0\0\0\0\0\0\0\0\0\0N\^A\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\M^D\0\0\0R\^A\0\0007\^A\0\0[\0\0\0\0\0\0\0K\^A\0\ \0\M^_\0\0\0\M-G\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\^A\0\0#\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0h\^A\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0A\^A\0\0\0\0\0\0\M^V\0\0\0\0\0\0\0\ \0\0\0\0\0\0\0\0\0\0\0\0B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M-o\0\ \0\0\M-Z\0\0\0\0\0\0\0\0\0\0\0\M^P\0\0\0\0\0\0\0_\^A\0\0\M-.\0\0\0\0\0\ \0\0\0\0\0\0Z\^A\0\0\0\0\0\0!\0\0\0b\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\ \0\0\0\M-n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M-D\0\0\0\0\0\ \0\0=\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^R\^A\0\0" 459 runcbl RET read 1024/0x400 459 r
Re: Acu Cobol 6.0 for Linux
> > [apparently the first message didn't get through; this is a repost] Your previous post got through. Probably the presumed answer is that no-one who saw it has tried this or feels competent to respond. You might some response if you could find a way to break the problem down a little more and give a little more detail. But, there probably are not many Cobol users on this list, so you need to give information that clearly establishes it as a problem with system libraries or whatever so people will feel in familiar territory. Someone might know another place (list) to ask as well. jerry > > Did enybody try to run AcuCobol 6.0 for Linux on FreeBSD's linulator? > I tried a couple of times (with old Debian libraries and more recently > Gentoo libraries) but runcbl keeps on getting a SIGSEGV right away. > > ccbl (the compiler) seems to work, though. > > Any clue? > > -- > walter pelissero > http://www.pelissero.de > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"