[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [HOWTO] RE: dejagnu remote testing without rsh/rcp facilities on tar
Re: [HOWTO] RE: dejagnu remote testing without rsh/rcp facilities on target.
Thu, 27 Apr 2006 16:00:35 +0200
Mozilla Thunderbird 1.0.8-1.4.1.centos4 (X11/20060421)
Dave Korn wrote:
> 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.
Thanks for clarification about it, i was confused about the building process of
gcc tool. Now im thinking in the 3rd approach discused below.
>>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) "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).
Thanks for the hints about wrappers concept, really that simplify things a lot.
I'm going to make the first checks to accomodate the target app to recieve the
patch from gdb (loader and newlib facilities running when gdb dwld/starts the
test case) and after that i'll try this option to accomplish the test validation
from dg, hope to tell you it's going fine, anyway thx a lot Dave for your time,
Btw, did you finally found the old testcases for 2.95.3 release? when you have
the time, feel free to tell me how to get them from you.