V850E simulator, assembler single-step never returns?!?

V850E simulator, assembler single-step never returns?!?

[Torsten Mohr]

Hi,

i use insight 6.4 built for target v850-unknown-elf.

My host is a x86 linux PC.

While debugging a program in the simulator i found that
at one point in the program flow the simulator never
returns.

This is reproducible.  In the program flow the PC is 0x0C66.
When i hit "Step Asm Inst (S)" i never get the chance again
to get control over "insight".

0xc62	<_malloc_r+104>:	jmp	[lp]
0xc64	<_malloc_r+106>:	mov	r25, r6
0xc66	<_malloc_r+108>:	jarl	0x11f4 <__malloc_lock>, lp
0xc6a	<_malloc_r+112>:	movea	503, r0, r10
0xc6e	<_malloc_r+116>:	cmp	r10, r28


000011f4 <___malloc_lock>:
    11f4:	7f 00       	jmp	[lp]

To my understanding this should never happen, right?

Is there anything i could have done wrong?

I can provide every further information you need, Sources, Setup,
ELF file, ...

I have set up insight for target V850, the tool chain produces code
for V850E (E at the end), but i got a hint (from either this list
or the "insight"-list) to use the target V850.


Can anybody give me a hint on this one?


Best regards,
Torsten.

V850E simulator, assembler single-step never returns?!?

[Torsten Mohr]

Hi,

i use insight 6.4 built for target v850-unknown-elf.

My host is a x86 linux PC.

While debugging a program in the simulator i found that
at one point in the program flow the simulator never
returns.

This is reproducible.  In the program flow the PC is 0x0C66.
When i hit "Step Asm Inst (S)" i never get the chance again
to get control over "insight".

0xc62	<_malloc_r+104>:	jmp	[lp]
0xc64	<_malloc_r+106>:	mov	r25, r6
0xc66	<_malloc_r+108>:	jarl	0x11f4 <__malloc_lock>, lp
0xc6a	<_malloc_r+112>:	movea	503, r0, r10
0xc6e	<_malloc_r+116>:	cmp	r10, r28


000011f4 <___malloc_lock>:
    11f4:	7f 00       	jmp	[lp]

To my understanding this should never happen, right?

Is there anything i could have done wrong?

I can provide every further information you need, Sources, Setup,
ELF file, ...

I have set up insight for target V850, the tool chain produces code
for V850E (E at the end), but i got a hint (from either this list
or the "insight"-list) to use the target V850.


Can anybody give me a hint on this one?


Best regards,
Torsten.

Re: V850E simulator, assembler single-step never returns?!?

[Daniel Jacobowitz]

Sending the message twice doesn't make it any more likely you'll get
an answer :-)

On Mon, Jun 05, 2006 at 09:45:25PM +0200, Torsten Mohr wrote:
> Hi,
> 
> i use insight 6.4 built for target v850-unknown-elf.

Have you considered reporting problems with Insight to the Insight
list?

Other than that I have no experience with the v850; I don't know if
there's anyone reading the list who does.  You may need to debug it
yourself.

-- 
Daniel Jacobowitz
CodeSourcery

Re: V850E simulator, assembler single-step never returns?!?

[Keith Seitz]

Daniel Jacobowitz wrote:

> Have you considered reporting problems with Insight to the Insight
> list?

Better yet, try opening a console and stepping manually (or use 
v850-elf-gdb). At least then you'll know that it is or is not a problem 
with insight vs gdb.

Keith

Re: V850E simulator, assembler single-step never returns?!?

[Daniel Jacobowitz]

On Mon, Jun 05, 2006 at 01:44:44PM -0700, Keith Seitz wrote:
> Daniel Jacobowitz wrote:
> 
> >Have you considered reporting problems with Insight to the Insight
> >list?
> 
> Better yet, try opening a console and stepping manually (or use 
> v850-elf-gdb). At least then you'll know that it is or is not a problem 
> with insight vs gdb.

Yes, that works too :-)

(In this particular case, I don't know exactly what the Insight button
used corresponds to - whether it is e.g. stepi or nexti.  I'd guess
stepi?)

-- 
Daniel Jacobowitz
CodeSourcery

Re: V850E simulator, assembler single-step never returns?!?

[Keith Seitz]

Daniel Jacobowitz wrote:

> Yes, that works too :-)

I say this because insight is really stupid. It really doesn't know much 
  about targets, other than the semantics of "target FOO BAR".

Okay, that's not true. There is one place that I recall where Insight 
knows more about the target than gdb. That is (oddly enough) with the 
V850 and the ICE that NEC has. But fortunately, the simulator is being 
used here.

> (In this particular case, I don't know exactly what the Insight button
> used corresponds to - whether it is e.g. stepi or nexti.  I'd guess
> stepi?)

Yeah, the insight execution buttons (run, step, stepi, next, nexti, 
finish, continue) map one-to-one with gdb commands. We do change run a 
little bit, but it eventually either maps to run or continue, depending 
on the target configuration database built into insight.

Keith

Re: V850E simulator, assembler single-step never returns?!?

[Torsten Mohr]

Hi,

i just single-stepped in the console (si).  It shows the same result
plus:
The last line in the console i see is:
[not visible]../../../../newlib-1.14.0/newlib/libc/stdlib/mlock.c:51
I attached the part from mlock.c below with line 51 marked.
Though i don't think it can be related to that, as in the assembler
this line just results to "jmp [lp]", also when i look at it in
gdb console with "l *0x11f4".

I made a screenshot of the whole thing (128k).  Is it of any help if i
send it to anybody?

Please note that i'm not sure if code generation for the target
is perfect.  But i'm sure that i did not apply any changes to
insight.  I configured in a bash script:

function do_gdb ( ) {
    mkdir -p gdb
    cd gdb
    rm -rf *
    ../../insight-6.4/configure \
    --target=v850-unknown-elf \
    --prefix=/opt/v850e \
    --with-newlib \
    --enable-sim \
    --disable-nls
#    make all-sim
#    make install    
    cd ..
}

regarding the combination of "make" i'm not really sure, i only
compiled and installed the simulator.

I directly posted to the gdb list because i think this is
related to the underlying gdb/simulator.

Would it be of any help if i supply the ELF file to anybody?


Best regards,
Torsten.

FILE mlock.c
void
__malloc_lock (ptr)
     struct _reent *ptr;
{
#ifndef __SINGLE_THREAD__
  __lock_acquire_recursive (__malloc_lock_object); // line 51
#endif
}



> Daniel Jacobowitz wrote:
> > Have you considered reporting problems with Insight to the Insight
> > list?
>
> Better yet, try opening a console and stepping manually (or use
> v850-elf-gdb). At least then you'll know that it is or is not a problem
> with insight vs gdb.
>
> Keith

Re: V850E simulator, assembler single-step never returns?!?

[Daniel Jacobowitz]

On Tue, Jun 06, 2006 at 12:36:08AM +0200, Torsten Mohr wrote:
> Hi,
> 
> i just single-stepped in the console (si).  It shows the same result
> plus:
> The last line in the console i see is:
> [not visible]../../../../newlib-1.14.0/newlib/libc/stdlib/mlock.c:51
> I attached the part from mlock.c below with line 51 marked.
> Though i don't think it can be related to that, as in the assembler
> this line just results to "jmp [lp]", also when i look at it in
> gdb console with "l *0x11f4".

In this case, it is probably a bug in the simulator.

-- 
Daniel Jacobowitz
CodeSourcery

Re: V850E simulator, assembler single-step never returns?!?

[Torsten Mohr]

Hi,

> > i just single-stepped in the console (si).  It shows the same result
> > plus:
> > The last line in the console i see is:
> > [not visible]../../../../newlib-1.14.0/newlib/libc/stdlib/mlock.c:51
> > I attached the part from mlock.c below with line 51 marked.
> > Though i don't think it can be related to that, as in the assembler
> > this line just results to "jmp [lp]", also when i look at it in
> > gdb console with "l *0x11f4".
>
> In this case, it is probably a bug in the simulator.

so how to proceed from here?

Do i need to report that somewhere?

Should somebody else try to reproduce that behaviour?

Can i give some more information or make some more tests?


Best regards,
Torsten.

Re: V850E simulator, assembler single-step never returns?!?

[Torsten Mohr]

Hi,

> > > i just single-stepped in the console (si).  It shows the same result
> > > plus:
> > > The last line in the console i see is:
> > > [not visible]../../../../newlib-1.14.0/newlib/libc/stdlib/mlock.c:51
> > > I attached the part from mlock.c below with line 51 marked.
> > > Though i don't think it can be related to that, as in the assembler
> > > this line just results to "jmp [lp]", also when i look at it in
> > > gdb console with "l *0x11f4".
> >
> > In this case, it is probably a bug in the simulator.

i just tried the latest insight-weekly, the same failure.

I also tried to add some printf() in v850.igen for "jarl".
I can see the output whenever i go over a jarl in the code,
but it looks to me that the problem is somewhere else hidden.

When i hit "next assembler instruction", not "step asm instruction",
i can hit the stop button and see that i obviously stepped over the
problematic code.
So i guess the problem may be related to displaying the code/output?

Can anybody please give me a hint on how to coninue from here?

Is there some special support for debugging gdb?


Best regards,
Torsten.

Re: V850E simulator, assembler single-step never returns?!?

[Daniel Jacobowitz]

On Thu, Jun 08, 2006 at 12:53:58AM +0200, Torsten Mohr wrote:
> Is there some special support for debugging gdb?

No.  You need to run it inside another debugger session using a native
GDB.

-- 
Daniel Jacobowitz
CodeSourcery

Re: V850E simulator, assembler single-step never returns?!?

[Torsten Mohr]

Hi,

> > Is there some special support for debugging gdb?
>
> No.  You need to run it inside another debugger session using a native
> GDB.

to create a version of v850-unknown-elf-insight with debug information,
do i just configure as before and then do "make CFLAGS+=-g"?

Or are there more things to consider?


Best regards,
Torsten.

Re: V850E simulator, assembler single-step never returns?!?

[Torsten Mohr]

Hi,

> No.  You need to run it inside another debugger session using a native
> GDB.

Ok, i recompiled v850-unknown-elf-insight with CFLAGS=-g set.

When i now start this one in a normal PCs insight and provoke the
error i observe the following:

The stack trace shows quite many functions at startup and then we go
to a loop:
...
...
catch_errors
wrapped_call
gdb_stack
GDB_get_prev_frame
call_wrapped_function
catch_errors
wrap_get_prev_frame
get_prev_frame
get_prev_frame_1
get_frame_id
v850_frame_this_id
v850_frame_cache
frame_unwind_register_unsigned
frame_unwind_register
frame_register_unwind
v850_frame_prev_register
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
trad_frame_get_prev_register
frame_unwind_register
frame_register_unwind
... goes on quite long and does not seem to stop ...


Is this of any help for anybody?  How should it look like?


Is it possible that this behaviour is provoked by bad memory
layout in the target (the debugged program in the simulator)?


Best regards,
Torsten.