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.30r2=1.31f=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
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
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/machine/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
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 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.30r2=1.31f=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
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 runcbl CALL
Acu Cobol 6.0 for Linux
[apparently the first message didn't get through; this is a repost] 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]
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]
Acu Cobol 6.0 for Linux
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 recent 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]
