RE: [HOWTO] RE: dejagnu remote testing without rsh/rcp facilities on target.

[Dave Korn]

On 25 April 2006 22:47, J.J.Garcia wrote:

> Dave Korn wrote:

>>   Ok, so you have a command line listening over a serial port?  You could
>> perhaps write a quick'n'dirty downloader using some ascii format (e.g.
>> srec) couldn't you?  Anyway, even if you can't ...  
>> 
> 
> Yes, what i finally have is a serial line (developping and user console)
> that 
> parses commands from the main application embedded in the target, but it's
>  not a shell prompt as expected (i.e. vxworks and others), i dont have the
> posibility 
> of downloading tests object files compiled b4 from the dejagnu framework and
> then run them within the target. 

  Well, you still could, couldn't you?  If you could add commands then you 
could (at least in theory) add commands to write bytes into memory and call it 
as a subroutine?

> My first approach was to translate/embedd
> all 
> of them within the main app running into the target (i think not very
> practical) 
> and then using that console (i.e. with an auxiliary command) start them and
> check the execution, i have newlib, i have the printout results with more or
> less tweaking.
> 
> I know it is not a very good approach, but it was my first.

  Seems perfectly reasonable to me, although you have to make sure the target 
application (with all the embedded testcases) gets rebuilt with the 
freshly-built compiler before you run the testsuite, otherwise the embedded 
testcases won't necessarily correspond to what the latest build of the compiler 
is actually emitting, of course!

> I've started looking at /usr/share/dejagnu/remote.exp to see which
> posibilities 
> i have to do remote execution/testing. I also saw there's a
> /usr/share/dejagnu/config/arc.exp wrapping gdb-comun.exp (with
> load_generic_config "gdb-comun") and my second approach was to use the
> gdb/jtag 
> to drive the embedded tests on target instead of starting them with a
> console 
> command and check the results manually, i think it should simplify the first
> approach having that we have a functional gdb running in the toolchain for
> that 
> target, but again i need to teach myself a lil more about dg, this is where
> your 
> howto helps me a lot!

  Yep, you should be able to make that work, and it avoids the 
stale-precompiled-testcases problem.  I haven't used a jtag debugger myself, so 
I can't offer you much advice there.



    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....