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

[J.J.Garcia]

Hi Dave!

Dave Korn wrote:
> 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.

Sorry, i dont understand very well the concept "stale-precompiled-testcases" you
described the note above, i was thinking in: 1st build the toolchain, then,
build the target with this toolchain and include the same testcases embedded in
target and finally, avoid downloading them (already in target) but just drive
them using gdb.

Better even, dont know if im paranoid, not to embedd the testcases in target
source, just make a new .lds linker map, compile them using dg, download (patch
the current running target) them using gdb:

gdb <ejecutable-980605-1>
(gdb) load
(gdb) "set pc and cont"

Check results from dg

Is that correct?

TIA

Jose.




> 
> 
> 
>     cheers,
>       DaveK


-- 
sparkbox.stigmatedbrain.net 2.6.9-34.ELsmp i686 GNU/Linux
23:55:01 up 19 days, 16:50, 49 users, load average: 0.22, 0.27, 0.33
---------------------------------------------------------
Standing on the defensive indicates insufficient strength; attacking, a
superabundance of strength. --The Art of War by Sun Tzu Chapter IV:Tactical
Dispositions