arm-elf-run and ANSI escape sequences

arm-elf-run and ANSI escape sequences

[Shaun Jackman]

First off, let me just say how impressed I am with the ARM simulator!
It astounds me that I can run a binary intended for my embedded
platform with no modification on my development machine.

I'm running an ARM binary using arm-elf-run that makes use of ANSI
escape sequences to control the terminal emulator (konsole in my
case). Clear screen, "\33[2J", works fine. But the combination of save
cursor, "\33[s", and restore cursor, "\33[u" does not. If the answer
is "That does not work." that'd be fine. I'm just a little curious
where it's gone wrong. I figured the escape sequences would be passed
right on through to the terminal emulator, and no-one would ever know
the binary's being run by an ARM simulator. If I compile the
application natively (using gcc instead of arm-elf-gcc) and run it,
save cursor and restore cursor work as expected.

I no very little (ok, nothing) about the internals of gdb, but if gdb
sets up a pseudo-teletype for the child process, perhaps the
save-cursor function does not work with this pseudo-teletype?

Thanks,
Shaun

arm-elf-run 6.3
newlib 1.13.0
arm-elf-gcc 3.4.3
konsole 1.4.2
KDE 3.3.2
Linux 2.6.11

Re: arm-elf-run and ANSI escape sequences

[Daniel Jacobowitz]

On Fri, May 27, 2005 at 12:02:30PM -0700, Shaun Jackman wrote:
> First off, let me just say how impressed I am with the ARM simulator!
> It astounds me that I can run a binary intended for my embedded
> platform with no modification on my development machine.
> 
> I'm running an ARM binary using arm-elf-run that makes use of ANSI
> escape sequences to control the terminal emulator (konsole in my
> case). Clear screen, "\33[2J", works fine. But the combination of save
> cursor, "\33[s", and restore cursor, "\33[u" does not. If the answer
> is "That does not work." that'd be fine. I'm just a little curious
> where it's gone wrong. I figured the escape sequences would be passed
> right on through to the terminal emulator, and no-one would ever know
> the binary's being run by an ARM simulator. If I compile the
> application natively (using gcc instead of arm-elf-gcc) and run it,
> save cursor and restore cursor work as expected.
> 
> I no very little (ok, nothing) about the internals of gdb, but if gdb
> sets up a pseudo-teletype for the child process, perhaps the
> save-cursor function does not work with this pseudo-teletype?

GDB doesn't use ptys.  You'll need to find out what is actually being
written to the screen.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: arm-elf-run and ANSI escape sequences

[Shaun Jackman]

On 5/27/05, Daniel Jacobowitz <drow@false.org> wrote:
> GDB doesn't use ptys.  You'll need to find out what is actually being
> written to the screen.

Thanks for the quick reply, Daniel. It seems that my trouble is due to
the output from the simulator being line buffered. I've checked that
this line buffering is not being done by the ARM binary being
executed. It appears to be done by GDB (arm-elf-run) or its terminal,
or...

My quick test is...
	fputs("Hello, ", stdout);
	getchar();
	puts("world!");

The getchar() flushes stdout, but nothing is displayed. Upon pushing
Enter, "Hello, world!" is displayed.

Do you have an idea as to which component in the output stream is
doing the buffering?

Thanks,
Shaun

Re: arm-elf-run and ANSI escape sequences

[Daniel Jacobowitz]

On Fri, May 27, 2005 at 04:35:32PM -0700, Shaun Jackman wrote:
> On 5/27/05, Daniel Jacobowitz <drow@false.org> wrote:
> > GDB doesn't use ptys.  You'll need to find out what is actually being
> > written to the screen.
> 
> Thanks for the quick reply, Daniel. It seems that my trouble is due to
> the output from the simulator being line buffered. I've checked that
> this line buffering is not being done by the ARM binary being
> executed. It appears to be done by GDB (arm-elf-run) or its terminal,
> or...
> 
> My quick test is...
> 	fputs("Hello, ", stdout);
> 	getchar();
> 	puts("world!");
> 
> The getchar() flushes stdout, but nothing is displayed. Upon pushing
> Enter, "Hello, world!" is displayed.
> 
> Do you have an idea as to which component in the output stream is
> doing the buffering?

Not a clue.  This may be defined by the ARM simulator interface, or it
may be an accident.

-- 
Daniel Jacobowitz
CodeSourcery, LLC