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

Dave Korn dave.korn@artimi.com
Thu Apr 27 14:00:00 GMT 2006

On 26 April 2006 23:00, J.J.Garcia wrote:

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

  Yes, that's fine.  I was just referring to the danger that if you modify the compiler/toolchain in some way and rebuild it and forget to rebuild the target, you could end up doing a testrun where the target was still running the old testcases compiled with the old version of the compiler while your test host was using a new build of the compiler that was generating code that didn't match what was actually in the target; as long as you take care, there needn't be any problem.
> 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?

  That sounds even better.  Or you might just want to use the "call" command.  Use the linker script to put wrappers round exit and abort and to locate the code in a constant part of the address map, set breakpoints on __wrap_exit and __wrap_abort in gdb, and issue "call main(...)" in the gdb command line.  (Might be easier to wrap main as well so you can set a breakpoint in __wrap_main to catch the return value when the testcase completes by returning from main).

Can't think of a witty .sigline today....

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

More information about the crossgcc mailing list