Tcl - Cross-compiled ARM Expect dropping spawned task

Author

Cross-compiled ARM Expect dropping spawned task

Peter Lu

2007-07-20, 7:14 pm

Hi,

I cross-compiled Expect for an ARM target on a x86 PC by
doing a pretty simple hack in ./configure to have the
cross-compiled ./conftest program(s) remotely executed
on the ARM target and have the return code sent back to
the x86 builder PC. This incrementally creates my
confdefs.h as shown below...

#define STDC_HEADERS 1
#define RETSIGTYPE void
#define TIME_WITH_SYS_TIME 1
#define HAVE_SYS_WAIT_H 1
#define STTY_BIN 1
#define HAVE_OPENPTY 1
#define HAVE_OPENPTY 1
#define HAVE_OPENPTY 1
#define HAVE_SYSMACROS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_UNISTD_H 1
#define HAVE_SYS_FCNTL_H 1
#define HAVE_SYS_SELECT_H 1
#define HAVE_SYS_TIME_H 1
#define HAVE_MEMMOVE 1
#define HAVE_SYSCONF 1
#define HAVE_STRFTIME 1
#define HAVE_STRCHR 1
#define HAVE_TIMEZONE 1
#define HAVE_SIGLONGJMP 1
#define HAVE_MEMCPY 1
#define WNOHANG_BACKUP_VALUE
#define HAVE_TCSETATTR 1
#define POSIX 1
#define HAVE_TERMIO 1
#define HAVE_TERMIOS 1
#define SETPGRP_VOID 1

My problem is that the resulting ARM Expect runs but drops
the spawned process after the first "expect" call (which
does return the initial output from the process). I've
created a really simple spawned test process do_echo.c as
follows...

#include <stdio.h>

char line[256];

main()
{
while(printf("==> "), gets(line) != NULL) {
if (strcmp(line, "quit") == 0)
break;
printf("do_echo:%s\n", line);
}
return 0;
}

If I don't do "expect" but just do "interact" then I'm
able to communicate with do_echo indefinitely. If I
use "expect" and "send" then the next "expect" gets
nothing and times out. It's possible that "send"
doesn't do the right thing and doesn't write its data
to the spawned process, unlike "interact." Or, the
first or second "expect" closes the read channel.
Or, the ARM platform may not properly support whatever
mechanism Expect uses to communicate to the spawned
process. I don't know what the flags in confdefs.h
do, and so can't tell if they are right.

Has anyonce come across this problem before? Could
anyone help me resolve the problem, so I don't have
to do laborious debugging?

Thanks for any help.
--
Keep it brief: http://www2.paypc.com/mailrules/

Peter Lu

2007-07-20, 7:14 pm

Hi,

I did a little more experimenting and it's clear that
"expect" calls subsequent to the first are not reading
the spawned process' output. The "send" path is
working properly as the spawned process is able to
read the data written by Expect.

Hope this info helps in any diagnosis. Thanks.

In article <f7qhjo$ocr$1@pcls6.std.com>, Peter Lu <swift@TheWorld.com> wrote:
>Hi,
>
>I cross-compiled Expect for an ARM target on a x86 PC by
>doing a pretty simple hack in ./configure to have the
>cross-compiled ./conftest program(s) remotely executed
>on the ARM target and have the return code sent back to
>the x86 builder PC. This incrementally creates my
>confdefs.h as shown below...
>
>#define STDC_HEADERS 1
>#define RETSIGTYPE void
>#define TIME_WITH_SYS_TIME 1
>#define HAVE_SYS_WAIT_H 1
>#define STTY_BIN 1
>#define HAVE_OPENPTY 1
>#define HAVE_OPENPTY 1
>#define HAVE_OPENPTY 1
>#define HAVE_SYSMACROS_H 1
>#define HAVE_INTTYPES_H 1
>#define HAVE_UNISTD_H 1
>#define HAVE_SYS_FCNTL_H 1
>#define HAVE_SYS_SELECT_H 1
>#define HAVE_SYS_TIME_H 1
>#define HAVE_MEMMOVE 1
>#define HAVE_SYSCONF 1
>#define HAVE_STRFTIME 1
>#define HAVE_STRCHR 1
>#define HAVE_TIMEZONE 1
>#define HAVE_SIGLONGJMP 1
>#define HAVE_MEMCPY 1
>#define WNOHANG_BACKUP_VALUE
>#define HAVE_TCSETATTR 1
>#define POSIX 1
>#define HAVE_TERMIO 1
>#define HAVE_TERMIOS 1
>#define SETPGRP_VOID 1
>
>
>My problem is that the resulting ARM Expect runs but drops
>the spawned process after the first "expect" call (which
>does return the initial output from the process). I've
>created a really simple spawned test process do_echo.c as
>follows...
>
>#include <stdio.h>
>
>char line[256];
>
>main()
>{
> while(printf("==> "), gets(line) != NULL) {
> if (strcmp(line, "quit") == 0)
> break;
> printf("do_echo:%s\n", line);
> }
> return 0;
>}
>
>
>If I don't do "expect" but just do "interact" then I'm
>able to communicate with do_echo indefinitely. If I
>use "expect" and "send" then the next "expect" gets
>nothing and times out. It's possible that "send"
>doesn't do the right thing and doesn't write its data
>to the spawned process, unlike "interact." Or, the
>first or second "expect" closes the read channel.
>Or, the ARM platform may not properly support whatever
>mechanism Expect uses to communicate to the spawned
>process. I don't know what the flags in confdefs.h
>do, and so can't tell if they are right.
>
>Has anyonce come across this problem before? Could
>anyone help me resolve the problem, so I don't have
>to do laborious debugging?
>
>Thanks for any help.
>--
>Keep it brief: http://www2.paypc.com/mailrules/

--
Keep it brief: http://www2.paypc.com/mailrules/

Peter Lu

2007-07-20, 7:14 pm

Hi,

Never mind. Apparently, the ported cross-compiled ARM
Expect works as well as my native x86 Expect. I was entering
the "expect" commands manually to test the ARM version, which
is a no-no because the timings are all off. When I use an
Expect script, then the "expect" interactions work properly.

Thanks for wasting your time.

In article <f7ql1u$ish$1@pcls6.std.com>, Peter Lu <swift@TheWorld.com> wrote:
>Hi,
>
>I did a little more experimenting and it's clear that
>"expect" calls subsequent to the first are not reading
>the spawned process' output. The "send" path is
>working properly as the spawned process is able to
>read the data written by Expect.
>
>Hope this info helps in any diagnosis. Thanks.
>
>
>
>In article <f7qhjo$ocr$1@pcls6.std.com>, Peter Lu <swift@TheWorld.com> wrote:
>
>
>--
>Keep it brief: http://www2.paypc.com/mailrules/

--
Keep it brief: http://www2.paypc.com/mailrules/

Sponsored Links