[ECOS] printf does not work in user mode on Arm E7T

[ECOS] printf does not work in user mode on Arm E7T

[Pierre Habraken]

Hello,

For demonstration purpose, I have inserted printf calls in a program
running on an Arm Evaluator 7T (controlled by gdb as a remote target).
The program is linked against newlib libc but and it uses redboot
syscalls (redboot.specs).
Some parts of the program runs in svc mode (cpsr = 0x13), other parts
run in usr mode (cpsr = 0x10), each mode using its own stack.
When printf is called with the processor being in svc mode, the
corresponding output is displayed in the gdb console and the program
continues then with its execution.
When printf is called with the processor being in usr mode, nothing is
displayed in the gdb console and the program hangs or raises a BUS
ERROR.
Could someone explain me what printf would not work in user mode ?

Thanks in advance for any help.

Pierre
-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Andrew Lunn]

This is not an area of eCos i know, so this is more of a guess.

How is your MMU setup? Maybe in user mode the MMU is stopping access
to the memory where the serial port is, or some other critical region
of memory. What is it trying to do when you get a BUS error? That may
give you a clue.

     Andrew

On Wed, Mar 26, 2003 at 09:19:51AM +0100, Pierre Habraken wrote:
> Hello,
> 
> For demonstration purpose, I have inserted printf calls in a program
> running on an Arm Evaluator 7T (controlled by gdb as a remote target).
> The program is linked against newlib libc but and it uses redboot
> syscalls (redboot.specs).
> Some parts of the program runs in svc mode (cpsr = 0x13), other parts
> run in usr mode (cpsr = 0x10), each mode using its own stack.
> When printf is called with the processor being in svc mode, the
> corresponding output is displayed in the gdb console and the program
> continues then with its execution.
> When printf is called with the processor being in usr mode, nothing is
> displayed in the gdb console and the program hangs or raises a BUS
> ERROR.
> Could someone explain me what printf would not work in user mode ?
> 
> Thanks in advance for any help.
> 
> Pierre
> -- 
> ________________________________________________________________________
> Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
> Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
> IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
> ________________________________________________________________________
> 
> -- 
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> 

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Thomas BINDER]

Hi!

My guess is that you have thread safety (option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS) enabled, in which case printf, sprintf, fprintf use a Cyg_Mutex object for synchronization (via Cyg_StdioStream, c.f. http://sources.redhat.com/ml/ecos-discuss/2003-03/msg00194.html).  Have you set up your MMU such that access to kernel objects is not allowed in user mode?

best regards,
Tom


Andrew Lunn wrote:
> 
> This is not an area of eCos i know, so this is more of a guess.
> 
> How is your MMU setup? Maybe in user mode the MMU is stopping access
> to the memory where the serial port is, or some other critical region
> of memory. What is it trying to do when you get a BUS error? That may
> give you a clue.
> 
>      Andrew
> 
> On Wed, Mar 26, 2003 at 09:19:51AM +0100, Pierre Habraken wrote:
> > Hello,
> >
> > For demonstration purpose, I have inserted printf calls in a program
> > running on an Arm Evaluator 7T (controlled by gdb as a remote target).
> > The program is linked against newlib libc but and it uses redboot
> > syscalls (redboot.specs).
> > Some parts of the program runs in svc mode (cpsr = 0x13), other parts
> > run in usr mode (cpsr = 0x10), each mode using its own stack.
> > When printf is called with the processor being in svc mode, the
> > corresponding output is displayed in the gdb console and the program
> > continues then with its execution.
> > When printf is called with the processor being in usr mode, nothing is
> > displayed in the gdb console and the program hangs or raises a BUS
> > ERROR.
> > Could someone explain me what printf would not work in user mode ?
> >
> > Thanks in advance for any help.
> >
> > Pierre
> > --
> > ________________________________________________________________________

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Pierre Habraken]

Andrew Lunn wrote:
> 
> This is not an area of eCos i know, so this is more of a guess.
> 
> How is your MMU setup? Maybe in user mode the MMU is stopping access
> to the memory where the serial port is, or some other critical region
> of memory.

The Samsung processor on Evaluator 7T board does not have a MMU.


> What is it trying to do when you get a BUS error? That may
> give you a clue.

What is strange is that I can't step into the printf subroutine: gdb
hangs as soon as I have typed the command stepi.
Actually, it seems that it is the 'branch to subroutine' (Arm BL)
instruction which hangs when executed in user mode: I wrote a small C
program the main function of which merely switches to usr mode and then
call a dummy subprogram, and could observe the same behavior, ie the BL
instruction hangs.
I fear that the problem is related neither to printf nor to newlib or
redboot but to the Arm (Samsung implementation) processor...

Pierre
> On Wed, Mar 26, 2003 at 09:19:51AM +0100, Pierre Habraken wrote:
> > Hello,
> >
> > For demonstration purpose, I have inserted printf calls in a program
> > running on an Arm Evaluator 7T (controlled by gdb as a remote target).
> > The program is linked against newlib libc but and it uses redboot
> > syscalls (redboot.specs).
> > Some parts of the program runs in svc mode (cpsr = 0x13), other parts
> > run in usr mode (cpsr = 0x10), each mode using its own stack.
> > When printf is called with the processor being in svc mode, the
> > corresponding output is displayed in the gdb console and the program
> > continues then with its execution.
> > When printf is called with the processor being in usr mode, nothing is
> > displayed in the gdb console and the program hangs or raises a BUS
> > ERROR.
> > Could someone explain me what printf would not work in user mode ?
> >
> > Thanks in advance for any help.
> >
> > Pierre
> > --
> > ________________________________________________________________________
> > Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
> > Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
> > IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
> > ________________________________________________________________________
> >
> > --
> > Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> > and search the list archive: http://sources.redhat.com/ml/ecos-discuss
> >

-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Jonathan Larmour]

Thomas BINDER wrote:
> Hi!
> 
> My guess is that you have thread safety (option CYGSEM_LIBC_STDIO_THREAD_SAFE_STREAMS) enabled, in which case printf, sprintf, fprintf use a Cyg_Mutex object for synchronization (via Cyg_StdioStream, c.f. http://sources.redhat.com/ml/ecos-discuss/2003-03/msg00194.html).  Have you set up your MMU such that access to kernel objects is not allowed in user mode?

He said he was using newlib libc, not eCos libc. This isn't an eCos 
application - the relevant bit is the use of RedBoot only.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Jonathan Larmour]

Pierre Habraken wrote:

> What is strange is that I can't step into the printf subroutine: gdb
> hangs as soon as I have typed the command stepi.

It's not the first time I've had GDB problems with functions with variadic 
arguments. Try and set a breakpoint _inside_ printf by hand before you've 
stepped into it (e.g. set a breakpoint on some function that printf calls).

> Actually, it seems that it is the 'branch to subroutine' (Arm BL)
> instruction which hangs when executed in user mode: I wrote a small C
> program the main function of which merely switches to usr mode and then
> call a dummy subprogram, and could observe the same behavior, ie the BL
> instruction hangs.
> I fear that the problem is related neither to printf nor to newlib or
> redboot but to the Arm (Samsung implementation) processor...

Theoretically it could be RedBoot since it's up to RedBoot to set the next 
breakpoint to implement the single stepping, although that functionality 
itself is known to work fine elsewhere. It could also be some problem with 
RedBoot's ability to restore state back to user mode, although it's not 
clear why it would work for other instructions, but not prior to a BL. 
What age is this RedBoot? There were some significant patches from Mark 
Salter in this area a while back - April 2002.

A hardware problem is always possible, but seems improbable really.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Pierre Habraken]

Jonathan Larmour wrote:
> [...]
> > Actually, it seems that it is the 'branch to subroutine' (Arm BL)
> > instruction which hangs when executed in user mode: I wrote a
> > small C program the main function of which merely switches to
> > usr mode and then call a dummy subprogram, and could observe the
> > same behavior, ie the BL instruction hangs.
> > I fear that the problem is related neither to printf nor to newlib
> > or redboot but to the Arm (Samsung implementation) processor...
> 
> Theoretically it could be RedBoot since it's up to RedBoot to set the
> next breakpoint to implement the single stepping, although that
> functionality itself is known to work fine elsewhere. It could also be
> some problem with RedBoot's ability to restore state back to user
> mode, although it's not clear why it would work for other
> instructions, but not prior to a BL. What age is this RedBoot?
> There were some significant patches from Mark Salter in this area
> a while back - April 2002.

I re-built Redboot from CVS sources on last March 3rd.
I attach below the test program I mentioned in my previous message.


> A hardware problem is always possible, but seems improbable really.

I agree. BTW, both programs (the one with printf's and the test program)
work fine and behave as expected when compiled/linked without Redboot
support and run on target sim...

Pierre

============================================================
// tryusermode.c

#include <stdio.h>

extern void toUsr();

int dummy() { return 0x1234; }

int main()
{
   int i, j;

   toUsr();     // go to user mode

   j = dummy(); // dummy() never entered if Redboot active

   for (i = 0; i < 10; i++) printf("%d\n", i);
}
============================================================
// tousr.S
         .global  toUsr
toUsr:
         mov      r0, sp
         stmfd    sp!, {r0, lr} // make sp_usr = sp_svc
         ldmfd    sp, {sp, lr}^ // and  lr_usr = lr_svc
         mov      r0, #0x10
         msr      cpsr, r0      // go to usr mode
         mov      pc, lr
============================================================
-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Pierre Habraken]

I just compiled and ran the test program (sources below) on the E7T
board, using this time Angel and RDI instead of Redboot: the Arm BL
instructions (and thus the call to printf) executes perfectly when the
processor is in user mode. As BL fails to execute when the program is
run against Redboot, I understand that something in the latter goes
wrong as regards user mode execution.
Can someone tell me where I could look in Redboot code in order to
understand the problem ???

Pierre


Pierre Habraken wrote:
> 
> Jonathan Larmour wrote:
> > [...]
> > > Actually, it seems that it is the 'branch to subroutine' (Arm BL)
> > > instruction which hangs when executed in user mode: I wrote a
> > > small C program the main function of which merely switches to
> > > usr mode and then call a dummy subprogram, and could observe the
> > > same behavior, ie the BL instruction hangs.
> > > I fear that the problem is related neither to printf nor to newlib
> > > or redboot but to the Arm (Samsung implementation) processor...
> >
> > Theoretically it could be RedBoot since it's up to RedBoot to set
> > the next breakpoint to implement the single stepping, although that
> > functionality itself is known to work fine elsewhere. It could also
> > be some problem with RedBoot's ability to restore state back to user
> > mode, although it's not clear why it would work for other
> > instructions, but not prior to a BL. What age is this RedBoot?
> > There were some significant patches from Mark Salter in this area
> > a while back - April 2002.
> 
> I re-built Redboot from CVS sources on last March 3rd.
> I attach below the test program I mentioned in my previous message.
> 
> > A hardware problem is always possible, but seems improbable really.
> 
> I agree. BTW, both programs (the one with printf's and the test
> program) work fine and behave as expected when compiled/linked without
> Redboot support and run on target sim...
> 
> Pierre
> 
> ============================================================
> // tryusermode.c
> 
> #include <stdio.h>
> 
> extern void toUsr();
> 
> int dummy() { return 0x1234; }
> 
> int main()
> {
>    int i, j;
> 
>    toUsr();     // go to user mode
> 
>    j = dummy(); // dummy() never entered if Redboot active
> 
>    for (i = 0; i < 10; i++) printf("%d\n", i);
> }
> ============================================================
> // tousr.S
>          .global  toUsr
> toUsr:
>          mov      r0, sp
>          stmfd    sp!, {r0, lr} // make sp_usr = sp_svc
>          ldmfd    sp, {sp, lr}^ // and  lr_usr = lr_svc
>          mov      r0, #0x10
>          msr      cpsr, r0      // go to usr mode
>          mov      pc, lr
> ============================================================
> --
> ________________________________________________________________________
> Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
> Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
> IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
> ________________________________________________________________________

-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Jonathan Larmour]

Pierre Habraken wrote:
> I just compiled and ran the test program (sources below) on the E7T
> board, using this time Angel and RDI instead of Redboot: the Arm BL
> instructions (and thus the call to printf) executes perfectly when the
> processor is in user mode. As BL fails to execute when the program is
> run against Redboot, I understand that something in the latter goes
> wrong as regards user mode execution.
> Can someone tell me where I could look in Redboot code in order to
> understand the problem ???

Use "set debug remote 1" in GDB and try and find out if anything is not 
right in the traffic there. After that you should look in hal/common's 
generic-stub.c which is where the GDB packets get read and mostly acted on.

Finally, there's arm/arch's arm_stub.c which contains code to determine 
the next PC on a single step. That's definitely worth a look given your 
problem, although the odd thing is how this works for others, but maybe 
something changed a while back and no-one's noticed yet! I don't have an 
arm target here to test I'm afraid.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Re: [ECOS] printf does not work in user mode on Arm E7T

[Pierre Habraken]

Jonathan Larmour wrote:
> [...]
> Use "set debug remote 1" in GDB and try and find out if anything is
> not right in the traffic there.

I attach below a trace of a gdb session.
At some place, gdb says:
"Packet Z0 (software-breakpoint) is NOT supported".
Is this Ok ? I am not sure of that because the Arm processor does have a
breakpoint instruction (BKPT)...
The log confirms that the 'step' command which should enter the function
dummy() gets no reply from the target.


> Finally, there's arm/arch's arm_stub.c which contains code to
> determine the next PC on a single step. That's definitely worth
> a look given your problem, although the odd thing is how this works
> for others, but maybe something changed a while back and no-one's
> noticed yet! I don't have an arm target here to test I'm afraid.

I had a (very) quick look yesterday to arm_stub.c and saw nothing weird
concerning either computing of next PC for the BL instruction or special
processing related to the processor mode (user or supervisor). BTW, no
constant value is defined in hal_arch.h for the user mode...

Pierre

===============================================================
$ arm-elf-gdb
GNU gdb 5.3
...
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf".
(gdb) set remotebaud 38400
(gdb) file test-printf
Reading symbols from test-printf...done.
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x01822ccc in ?? ()
(gdb) load
Loading section .text, size 0x8d80 lma 0x10000
Loading section .init, size 0x1c lma 0x18d80
Loading section .fini, size 0x18 lma 0x18d9c
Loading section .rodata, size 0x318 lma 0x18db4
Loading section .data, size 0x7ec lma 0x191cc
Loading section .eh_frame, size 0x4 lma 0x199b8
Loading section .ctors, size 0x8 lma 0x199bc
Loading section .dtors, size 0x8 lma 0x199c4
Loading section .jcr, size 0x4 lma 0x199cc
Start address 0x10100, load size 39120
Transfer rate: 26080 bits/sec, 291 bytes/write.
(gdb) list test-printf.c:12
7       int main()
8       {
9          int i;
10
11         i = dummy();       // can step in dummy()
12         printf("%d\n", i); // printf OK
13
14         toUsr();           // switch to user mode
15
16         i = dummy() + 1;   // can NOT step in dummy()
(gdb) break 16
Breakpoint 1 at 0x1060c: file test-printf.c, line 16.
(gdb) set debug remote 1
(gdb) cont
Continuing.
Sending packet: $Z0,1060c,4#40...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m1060c,4#f7...Ack
Packet received: ecffffeb
Sending packet: $X1060c,4:þÞÿç#de...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: O343636300A
4660
Packet received: T050f:0c060100;0d:ccff0700;
Sending packet: $g#67...Ack
Packet received:
1000000001000000009a01008908000002000000500000000000000000000000e0970000fdffffff50000000dcff0700a8030100ccff07000c0601000c0601000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000
Sending packet: $m105e0,4#f8...Ack
Packet received: 0dc0a0e1
Sending packet: $m105e4,4#fc...Ack
Packet received: 00d82de9
Sending packet: $m105e8,4#00...Ack
Packet received: 04b04ce2
Sending packet: $m105ec,4#2b...Ack
Packet received: 04d04de2
Sending packet: $m105f0,4#f9...Ack
Packet received: f3ffffeb
Sending packet: $m105f4,4#fd...Ack
Packet received: 0030a0e1
Sending packet: $m105f8,4#01...Ack
Packet received: 10300be5
Sending packet: $m105fc,4#2c...Ack
Packet received: 2c009fe5
Sending packet: $m10600,4#c4...Ack
Packet received: 10101be5
Sending packet: $m10604,4#c8...Ack
Packet received: 670000eb
Sending packet: $m10608,4#cc...Ack
Packet received: e7ffffeb
Sending packet: $m1060c,4#f7...Ack
Packet received: fedeffe7
Sending packet: $m10610,4#c5...Ack
Packet received: 0030a0e1
Sending packet: $m10614,4#c9...Ack
Packet received: 013083e2
Sending packet: $m10618,4#cd...Ack
Packet received: 10300be5
Sending packet: $m1061c,4#f8...Ack
Packet received: 0c009fe5
Sending packet: $X1060c,4:ìÿÿë#f1...Ack
Packet received: OK

Breakpoint 1, main () at test-printf.c:16
16         i = dummy() + 1;   // can NOT step in dummy()
(gdb) step
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
remote_interrupt called
remote_stop called
Interrupted while waiting for the program.
Give up (and stop debugging it)? (y or n) y
(gdb)
===============================================================
-- 
________________________________________________________________________
Pierre HABRAKEN - mailto:Pierre.Habraken@imag.fr
Tél: 04 76 82 72 83 - Fax: 04 76 82 72 87
IMAG-LSR BP72 38402 SAINT MARTIN D'HERES Cedex
________________________________________________________________________

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss