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

["Dave Korn" <dave dot korn at artimi dot com>]

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....


--
For unsubscribe information see http://sourceware.org/lists.html#faq